Tag Archives: Lean

Coach as ‘Pair of Hands’

What happens if you acquiesce to being an extra ‘pair of hands’ on your coaching assignment by agreeing to do things for the coaching client.

What might it look like if you resist doing ‘staff augmentation’?

Here’s what it may look like with various scenarios plotted, passage of time horizontally and performance level (you choose the metric e.g. throughput, cycle time, quality) vertically.

Note: A J-Curve visualization is different, that represents the dip that occurs when learning something new.  This is a model on the coach’s impact on a team/organisation overall.

No apologies offered for the hand drawn nature of these drawings.

Coaches Effect on Team_Organisation Performance

Gabe Abella’s presentation on self-organizing teams is a source of inspiration as well as various sources in the Lean literature.


Right Size First, Then Split

There is a hell of a lot going on in Agile Space on Story Splitting.  On the internet and I hear it in interviews and conversations.  It’s as if the only solution to smaller batches is to split ad infinitum.

Now don’t get me wrong, big batches are not good.  They hurt feedback mechanisms, create silos and delay delivery of value.

And there is the point, delivery of value.  Getting value to the customer is important.  Story Splitting is one way.  It doesn’t need to be the starting point.  We may be losing our focus on delivery of value by thinking about a process.  Value is not defined by the splitting of stories.

Something to consider then is to understand the nature of your work.  Are there different types of work, or another way to put it, sources of demand?  Can you use that information to help?

Maybe your team is predictable in it’s delivery.  That’s great and congratulations to you on that.  That data on delivery time can be leveraged.  If you can say we can deliver product enhancements on one product within a time frame and be confident about that say 85% of the time.  There you go – you have the makings of a Service Level Agreement or SLA.  Your customer may even be happy with that!

How can that help in sizing stories?  Well Dan Vacanti describes it in his book Actionable Agile Metrics for Predictability.  It’s called Right Sizing.  In essence it shortens the sizing conversation by asking does this work which we are about to take on fit in within our SLA.  If so then pull the work.  If not have that splitting conversation.

It’s that simple.  However, if you are experiencing problems in predictability and expanding delivery times then you’ll want to deal with those.  Dan’s book describes how Little’s Law and its components gives you ample information to help discover issues in your process.

Story Splitting is an option to start with.  You can consider others like this.  I think it will help you understand work to a higher level of fidelity.  Your customer will hopefully feel the difference as you deliver to them more meaningful increments of value from the increased understanding.  Coincidentally, you’ll also be on your way to be being better Systems and Lean Thinkers which are interesting subjects that will aid you being of best service to your customers.

The Importance of Shared Purpose

My latest blog is actually one written for my employer here in the United States, Code Genesys.

You can take a look at it here and is on the importance of shared purpose.  Keep practicing that because it’s hard for first timers and anyone whose experienced for that matter.  Well worth the investment in time 🙂

I have an example of a company who go to great lengths to maintain their purpose.  An old blog article written 2 years ago.

Lean Coffee Meetup in Perth 21st May 2015

For those of you in Perth, there will be a Lean Coffee Meetup next Thursday the 21st of May 2015 starting at 5:45pm.

AgWorld are sponsoring by providing the space and some drinks and snacks. They are centrally located in Leederville and there will be parking on the street available for those driving or it is easily accessible from Leederville train station.

A Lean Coffee is a formal, yet informal, discussion where you come with your ideas and requests and start a conversation.

The meetup link gives a bit more information. You’ll find out more on the night and it promises to be an engaging evening.

Please signup via the meetup link. http://www.meetup.com/Lean-Perth/events/222450260/

There will be a limit of 15 attendees.

Hope to see some of you there.

Mary and Tom Poppendieck on the Seven Principles of Lean Software Development

“Requires a change in culture that some companies can’t achieve, those that have achieved massive performance improvements”

A summary of the principles from the Poppendieck’s momentus book Lean Software Development: An Agile Toolkit

The 7 Principles

Eliminate Waste – coding more features than required, handoffs, low or no value documents (shelfware), defering of decisions

Build Quality In – this also encompasses integrity which is wise leadership, communication, healthy discipline, relevant expertise.  This can’t be replaced by processes, procedures and measurements.  Technical practices like  Test Driven Development (TDD), Continuous Integration, Definition of Done assist.  UX design helps the customer attain a feeling of perceived integrity.  Supple architecture allows the system to gracefully grow.

Create Knowledge – also known as Amplify Learning.  This is where Lean for Software differs from Lean Manufacturing.  Development is a constant learning exercise in discovery.  There is an expectation that mistakes will be made but we learn from them and make the adjustments.  Learnings should be shared e.g. in a showcase, in a retrospective.  Feedback loops are present throughout.

Defer Commitment – also known as Last Responsible Moment in Lean Manufacturing.   Delaying decisions can be valuable because more information is available.  In Agile this means detailed story development is deferred, design and implementation should occur when it’s needed at not before hand.

Deliver Fast – To enable feedback to occur.  Also smaller batches reduces errors inherent in large batch work because of the missing feedback loop.  Compression the value stream helps here – i.e. eliminate or reduce wait time.

Respect People –  people on the coalface backed with good leadership are best placed to combine knowledge of the technical with the requirements of the customers.  It will lead to excellence and morale will go up markedly.  There is a wisdom in Crowds/Group Expertise

Optimize the Whole – the common good can suffer when people attend only to their specialization. Therefore this should not be measured at this level as it promotes sub optimization.  It will hurt the system overall.

On Lean Principles according to Womack and Jones

One of the best introductions to Lean Thinking is a the book ‘Lean Thinking‘ by Womack and Jones.

What follows is a summary of the book I used for my own purposes and hopefully is useful for you as well.  I’ve added some counter points from other authors as well.

According to Womack and Jones there are five steps:

  1. Identify the value for each product
  2. Identify the Value Stream
  3.  Create flow without interruptions
  4. Let the customer or consumer pull value from the produce
  5. Pursue Perfection

On Muda – is waste – anything that does not create value and includes waiting in queues, mistake rectification, over production and movement.

On Lean – this should be not been seen as a job destroyer.  It should create work – more valued work.

Value can only be defined by the customer.  It’s not created by engineers with complex ideas.  It needs a dialogue with the customer to supply the needs – this could be abstract – did the smart phone customer say they needed the iPhone?

Visualising the value stream will expose the MUDA.  You should be able to extend this to suppliers to flow the entire value stream from without your own organisation

When waste is removed – make the system flow!  That means work with smaller batches.  This will generate faster feedback.  (Simulations are available like paper plane making to illustrate this).  Jim Benson however suggests start with flow and eliminate the waste from there.

Furthermore to get flow, ignore traditional boundaries of jobs, careers and functions.  These are impediments to flow.  Keep the product in sight at all times (early delivery).  All workflows and tools are up for scrutiny.

Once flow is established time to complete work can come down from months to days, days to hours.  David Anderson did this with a team working for Microsoft.  The team was based in India.  There were many problems in reliability in estimates and quality of the work and delivery of that work.  He (and colleague Dragos Dumitriu) used Kanban to achieve this.

This leads to the ability to Pull.  You can do the work and make the product when the customer asks for it.  For example DELL Computer makes PCs to order.  Inventory is waste and for DELL large inventory is massive waste due to obsolescence.  Toyota is capable of making cars to order because of the value stream includes the supplier.  Toyota can build a car on order in one week.  If there is no PULL then there is still waste or MUDA.

Now with everything visible, flowing and pulling, transparency is a natural by product and therefore it’s much easier to discover other ways to create value.  When employees are involved in the entire loop, then employee satisfaction goes up – less need to financial reward systems (a dysfunction maybe)

A transition should not be costly.  Going from large batches to smaller batches for example.  If it’s expensive then you’ve yet to understand lean thinking.

And on society – Womack and Jones also say “Stagnation has also led to a frenzy of cost costing in the business world, which removes the incentive for employees to make any positive contribution to their firms and swells the unemployment ranks.”  Lean Thinking is the way to turn this mindset around.

And be aware or beware – Lean Thinking means layers of management get permanently stripped away.  However this does not preclude the idea of succession plans, rewards for experience and higher pay.  You lose the title not the experience.  You will find yourself becoming a coach.

A transformation can take years.  There are several examples in the book with Toyota and Pratt & Whitney being the most famous.

Agile, Lean and Software Book Sale

I have a number of hard copy books for sale.  They are great books and I would keep them.  However I want less clutter in my life and will switch to electronic format for ease of storage and usability (for me).

Some still want the old style and these books are still valuable.  They are in excellent condition and should expect to receive a decent second hand price.  I’ve not listed a price along side the books but you can use your own detective skills to make a decent and respectful offer. For those living in Perth, Western Australia I’m happy to drop off the book personally.  For others postage will be an extra cost.  Email me at n_zdunic AT yahoo DOT com DOT au to make an offer.

As the items are sold I will put a strike through the item.

Book List

Domain Driven Design – Eric Evans

Refactoring – Martin Fowler

Peopleware – Tom DeMarco and Tim Lister

Code Complete – Steve McConnell

Rapid Development – Steve McConnell

Test Driven Development – Kent Beck

Writing Effective Use Cases – Alistair Cockburn

Agile Software Development – Robert C. Martin

Software Architecture – Len Bass et al

Applying Domain-Driven Design and Patterns with Examples in C# and .NET – Jimmy Nilsson

Analysis Models-Reusable Object Models – Martin Fowler

Pattern-Oriented Software Architecture Vol 1 – Buschmann et al

Project Retrospectives – Norm Kerth

The Secrets of Consulting – Gerald M. Weinberg

Death March – Edward Yourdon

Agile Project Management 1st Edition – Jim Highsmith

User Stories Applied – Mike Cohn

Extreme Programming Explained 1st Edition – Kent Beck

Extreme Programming Explained 2nd Edition – Kent Beck with Cynthia Andres

The Pragmatic Programmer – Andrew Hunt & David Thomas

Coaching Agile Teams – Lyssa Adkins

Enterprise Integration Patterns – Gregor Hohpe & Bobby Woolf

Patterns of Enterprise Application Architecture – Martin Fowler

Refactoring to Patterns – Joshua Kerievsky

Scaling Software Agility – Dean Leffingwell

Writing Solid Code – Steve Maguire

Debugging the Development Process – Steve Maguire

The Mythical Man Month – 20th Anniversary Edition – Fred Brooks

Surviving Object-Oriented Projects – Alistair Cockburn

UML Distilled Second Edition – Martin Fowler

Dynamics of Software Development – Jim McCarthy

Object-Oriented Software Construction – Bertrand Meyer

Continuous Delivery – Jez Humble and David Farley