Explaining Herbie…

I have been asked by a friend to write an article explaining the concepts of Herbie from the book “The Goal” in a more accessible way. The book itself is amazing but in my opinion the language used in the 5-focusing steps has tried too hard to be scientific and precise that it makes it harder to understand. My annotations simplify the terms but likely lose some of the precision of the wording, I offer this as an introduction to the topic but encourage reading the book to get the full impact, I cannot do it justice here.

DHO_0coVwAEzcDl

Herbie is a character from the book “The Goal” he was used in the story as a metaphor for a system constraint and the impact it has on your delivery. I’d highly encourage you to read the book but hopefully it is not essential to be able to follow the explanation, the purpose of the metaphor was to make the thought processes relate-able, hopefully this helps.

TOC 5 Steps

The 5 focusing steps

  1. Identify the system constraint
  2. Exploit the constraint
    (Make the best use of what you currently have)
  3. Subordinate everything to the constraint
    (Make decisions based on the constraint, the system should run at the pace of the constraint)
  4. Elevate the constraint
    (Make improvements to the constraint)
  5. Repeat the steps

Step 1: Identify the constraint

We need to figure out which part of the system is holding us back the most – limiting our ability.  We should know that only an improvement at the constraint makes a difference.

Herbie: In the example of Herbie, he was observed as holding everyone back he was slow and the rest of the group had to regularly stop to wait for him to catch up or were racing ahead.  In the case of Herbie the constraint was evident through observation.

download2

Reality:  There are different ways to identify a system constraint sometimes observation and experience is sufficient, or metrics can help.  The simplest way is to look at your work is it piling up somewhere? Do you have a lot of stories in Dev Done, or waiting on PO approval or needing wire-frames? Piles of work are a sign of a constraint.

Another common constraint are blockers, if you are consistently waiting on another team, another person or another resource this is a sign of a constraint, we may use blocker clustering or other root-cause technique to see if there is a common theme to delays.

The third most common technique is to review cycle-time for stories, look for stories that are taking longer than others see if there is a pattern, common aspects, this could be a constraint that may be improved.

Step 2: Exploit the constraint (Optimize)

Before we consider adding capacity, we should make the best use of the capacity we already have. We ‘Exploit’ in this sense means doing everything possible to use the constraint to its fullest capacity. This is also the easiest and generally cheapest improvement you can make to your system.

Herbie: In order to maximise the performance of Herbie, the contents of his backpack were shared out so he could concentrate on the most important task of walking.  Making the others slower (less efficient) by carrying his stuff was unimportant as Herbie sets the pace for the entire group.

We could also have ensured that he got his lunch first so could start sooner, and others could have covered his chores so he was more rested – our goal is to get the best out of Herbie on his most important task – walking.

Reality: In our systems we need to identify what the most important task is, typically this is getting a story to done and the software in the hands of the user.  So when you identify your constraint look for anything they are doing that is not helping to move stories or for anything they are doing that someone else could do. Are they filling in paperwork that someone else could do? does this task really require their expertise? Could you make them a coffee so they could focus. (This is not encouragement to over-work, breaks socialising and generally a healthy working environment always takes priority).

 

WheresHerbie

Step 3: Subordinate the non-constraints

The job of all non-constraints is to subordinate their decisions to the constraint’s needs.

That sounds extreme wording but essentially it means that no mater how fast you go, if you are dependent on someone slower you are wasting your efforts, so work at the pace of the constraint, you have reserves so you can catch-up if necessary.  Use the time saved to help optimize the rest of the system.

We do this as step 3 because it is more disruptive and more costly than step 2.

Herbie: In the story Herbie was put at the front and the rest of the group were told not to overtake him. When Herbie was able to go faster there was no one in front to delay him so we got the best from him and as the others were able to go faster overall they were able to make up any delays. The goal was only achieved when everyone was done so there is no benefit in getting ahead.

Reality: Don’t let work pile up, if we limit Work in progress we focus on flow rather than utilization, put effort where it has most impact on the whole system.  In the case of dependencies on 3rd parties, could you give them advance notice so they are better prepared and can respond sooner. If you are dependent on a 3rd party could you see if there is a time/day they can respond more quickly, could you tailor your process to be more convenient for them? Tailor your process to maximise the effectiveness of the constraint, and this is the tough bit – even if that means making the process worse for others.

Tailor your process to maximise the effectiveness of the constraint,  even if that means making the process worse for others.

Step 4: Elevate the constraint

Only once we’ve completed the previous steps does it make sense to add more constraint capacity, and thereby increase system performance. Because adding capacity is tremendously expensive in terms of time and money, we do it as a last resort, not a first step.

Herbie: In the case of Herbie, we could get him doing fitness training so he is quicker, or buy him a bicycle.

Reality:  This is typically where you spend money, hire more people, get better/more equipment. Invest in training or education. Remember improvements here improve your entire system so the investment must be calculated based on system income not local costs. Maybe you ship parts by air, maybe you fly in an expensive expert, maybe you lose money on this aspect of a project so that the project as a whole makes more money. Keep the focus on the gain to the entire system and not get distracted by the cost at one stage.

Step 5: Return to step 1

The inevitable result of the first four steps, and the reason this is a “continuous” improvement method, is that the constraint will inevitably move somewhere else.

This step insists that you start back at the beginning, and don’t let inertia become the constraint.

 

choosing-a-doctor

A second example of the steps being applied…

 

Identify

Access to overworked Doctors in an emergency – constraint is a shortage of Doctors:

Exploit: Make the best use of what you currently have

  • Ensure Doctor is not doing any activity that someone else could do. All admin work is removed, prep work done by nurses or other staff.
  • Vacations/time off is deferred,
  • Doctors may work overtime so long as it doesn’t risk the patient or cause the Doctor to quit

Subordinate: Make decisions based on the constraint, the system should run at the pace of the constraint

  • Any non-urgent treatment is stopped until emergency is over.
  • Cases are prioritized so Doctors are only working on the most urgent cases.
  • Patients are only ‘prepped’ according to the capacity of the Doctors.
  • Patients are prepped in advance so that the Doctor is never waiting.
  • It may be quicker for a Doctor to move between patients rather than them coming to the Doctor.

Elevate: Make improvements to the constraint

Now we look to increase the number of Doctors or their effectiveness

  • transferring Doctors from other areas withing the organisation
  • recruiting more Doctors even at inflated rates or short term contracts,
  • any increase is an increase so we can hire someone that is semi-retired or part-time.
  • We may automate activities or buy tools to improve the efficiency and effectiveness of the doctor.
  • We could train Nurse to perform some of the Doctor’s activities

Repeat

We look and see whether the Doctors are still the constraint or whether there is a new constraint.

 

Summary:

There may be a little ambiguity with some of these improvements, e.g. A Doctor moving between patients may be considered elevating or subordinating, but it doesn’t matter it is an improvement, it is a thinking process and some changes don’t neatly fit into one category, don’t let that distract you from the thinking process itself.

 

9780815385134


The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

Isn’t it obvious?

I occasionally get asked why and how I became an Agile Coach and whether it is a fulfilling role. When I began my career I certainly had no intention or expectation to be here, I was a software developer, I loved writing code and like most developers I wanted to create something that made a difference.

What followed was 15 years of… I want to say frustration but that is unfair because I generally loved my work and got to create some great software, but I always had this belief that there was a better way, a more effective way to get the job done, I dabbled in project management and team management believing I could do better than those I had worked for in the past.  My problem and I suspect it is a very common problem is that I spent a lot of effort trying to do my job better, to be more efficient, more effective, to deliver more etc. etc. It turns out that was wrong and I was wasting a lot of effort and not getting the results I expected.

deadly-assumptions

And then quite by accident (and for all the wrong reasons) I stumbled on to Scrum. I was running a software department and we were forever fire-fighting and I saw Scrum as a tool I could use to control the workflow and manage the demands on the team. It worked, and in the breathing room it created I was inspired to look deeper, beyond Scrum to Agile, and then Lean and Systems thinking and the Theory of Constraints and then I saw it. I felt like I had discovered the meaning of the universe, and once you see it you can’t un-see it, you see it everywhere, it feels like it is staring you in the face.

There is nothing more deceptive than an obvious fact. 
― Arthur Conan Doyle

c770ba6b2c578be3db267493229de2dc

Of course I hadn’t discovered anything, I had just opened my eyes and it was right there in front of me and it was so unbelievably obvious that it almost feels stupid writing this.

And it is this simple:

All we have to do is work on the thing that adds the most value and stop working on things that don’t add value.

Work on the thing that adds the most value and stop working on things that don’t add value.

So I said it was simple but it took me 15 years to start to understand it and nearly 10 years later I am still figuring it out, because whilst it is so simple that it should have been obvious all along, it is also remarkably difficult to do.

What is Value?

The primary problem is to understand what value is. figuring out your value stream in a system is key, and to be fair most businesses do this to some extent, but most individuals do not understand how they fit into the system they are in, nor do they understand how their local system fits into the big picture.

We cannot see the value we contribute to the system and when we don’t see what is most valuable, we do what we see as most valuable in our line of sight. Crazy as that sounds it is nearly always the wrong thing, optimizing for us nearly always optimizes against the larger system. The bigger the organisation the more this happens and the more inefficient it gets.

opportunity cost

  • the loss of potential gain from other alternatives when one alternative is chosen.

Another aspect is that so much value is obfuscated, it gets lost in opportunity cost which is invisible on balance sheets and yet is likely the biggest cost you pay when developing software. Or cash flow, leverage and return on investment, these are fundamental aspects of successful business but they are generally encapsulated and decoupled from the parts of the business that can impact them most – especially IT and software product development. Many projects get given budgets and time lines, which is a horrible way to run a business and it cripples cash flow, it also significantly limits investment opportunities and increases risk significantly.  But worst of all it delays delivering value.

Two Problems

So that is actually two problems, first is that we need to figure out what is valuable and then we have to communicate that to those doing the work.

In that sentence is the heart of being an Agile Coach, my role has become one of helping organisations understand their value stream, especially how software impacts and interacts with it, helping visualise that value and prioritise it and then to help communicate that to those that will create the software and deliver that value as quickly as possible.

  • Discover what our goal is – how do we deliver value? What outcome are we trying to achieve? 
  • Communicate that to everyone so we each know how we help to get towards the goal and how we avoid getting in the way.

 

Unfortunately the majority of the time is spent dealing with people that are just like I was, they are doing their very best to be as efficient and possible in their domain, simply because they cannot trace what they are doing to the value delivered.  So I spend much of my time doing my best to help them see that often what they are doing is at best not achieving anything useful and more often is actually damaging to the bigger picture.

Example

victoriaspongecomet

Let me give an example that a friend of mine shared recently:  My friend was baking some cakes for an event and needed to bake 10 cakes, but only had one oven. Her husband offered to help out and so she asked him to measure out the ingredients for the cakes in advance so that it would be quicker to get the next cake in the oven.

When she came to get the ingredients for the cake, they were not ready, her husband had optimised for himself and not for the goal.  He concluded it would be much more efficient for him to measure out 10 batches of flour then 10 of… etc.  after all he knew they would be needed later and it was quicker and far more efficient for him to do that than to do small batches and keep switching.

The result was that whilst he was being efficient for himself, the system grinds to a halt and must wait, his efficiency came at the cost of massive losses to value delivery (cakes baked).

Perhaps if he had understood the full picture, and how his contribution impacted the value stream he would have planned his work differently? He would have prepared one cake at a time even though it was less efficient for him. Together they would have reached the true goal more quickly.

But the funniest part of this story for me was that she was so frustrated,  she thought it was obvious, and he thought he was being efficient.  Those opposing view points are so common in this line of work.

When you see it, it is obvious but until you do it remains an enigma.

Why be a coach?

doc

Now imagine that confusion on an industrial scale, a whole organisation of people conscientiously working hard in the belief they are being efficient but still struggling to deliver software, delivering software that is not what is wanted, features that are not needed, struggling with integration and so on.  Then this loony guy comes in and says that you might actually contribute more by being less efficient.  – I’m the loony guy and I love it.

Agile is a mindset for getting better at delivering software and coaching is about helping you. But my goal is not to help you improve just a part of the system, the goal is to help you improve the system, and that starts by helping you and the whole organisation see the system. and learn how to communicate where we can add value.

Obviously there is a lot more to Agile than communication and value, but in my experience if you figure those out the rest falls in to place.

—————————————

There are a handful of books that I repeatedly recommend, all of which display true Agility and yet to be contrary not one is about ‘Agile’

The Advantage by Patrick Lencioni 

This talks about being clear in your goal and how to communicate it to your organisation, it is not quite as specific as I am hinting at in the article as we must delve deeper but it is an amazing book and the emphasis is on over-communication.

The Goal by Eli Goldratt

This book uses a production plant as a metaphor for delivering value to your customers. The emphasis is on the manufacturing equivalent of delivering working software, doing it regularly, and that delivery is not about development, OR production OR deployment it is about everything – essentially encouraging Dev Ops.  It also has a lot to say about the non-sense of Dev-Done and how the only Done that matters is to have it in your customers’ hands.

Read it!  This is hands down the best book on Agility I have ever read.  There are many others by this author all of which are great but this is my favourite.

The 5-Dysfunctions of a Team by Patrick Lencioni

I wholeheartedly subscribe to the Lencioni school of thought on many things (hence two books by him in this short list). On team building this is one of the best books out there, it describes the stages of team development, and you see this time and time again. Team dynamics are such a crucial part of agility and fundamental to success, this helps teams see those stages and is a great tool for helping teams bond.

 

Goldratt User Stories

As a product owner we should be building products to deliver on the Vision and a set of  defined objectives or success criteria. But often our plan is not closely mapped to those criteria or it can be difficult to measure whether we have achieved our Vision or delivered on our objective.

Let’s change the way we write stories

So I wondered if we could expand on a desire for delivering measurable value by changing the way we both plan projects/product and write our user stories?

 

Tell me how you measure me and I’ll tell you how I will behave.

Eli Goldratt

 

The notion of this is that rather than defining our User Stories in terms of behaviour, or actions or activities –  in which we primarily focus on the ‘What’ we should change, our start point should become us defining the “needle we want to move”  Let us start with the measurement of success. Understanding how we will be measured and identifying behaviour that impacts the measurement.

photo_of_the_day_ferrari_458_italia_dashboard

E.g. our goal is to increase the number of items per basket for online sales, our measurement is therefore the average number of items sold per transaction.

Equally it could be to increase the average value of the basket per transaction, or increase the number of units sold of high profit products

Hypothesis rather than Story

Our ‘story’ then would be to ask the Product Owner and Team to identify one or more hypothesis for ways that could impact that measurement. The notion being that a hypothesis must be tested before the story could be considered done.

This could take the form or a brainstorm session to identify the more traditional stories or it could simply be left for the team (in conjunction with the PO) to determine the best way (possibly two or three alternatives) to achieve the desired outcome after the story has been pulled.

This is building on the principle:

The best architectures, requirements, and designs
emerge from self-organizing teams.

Already happening?

You could argue that this is already the role of the Product Owner and that the Product already does this, and in identifying and prioritizing stories they have already considered the impact.  In some cases I would agree with you, in a few cases I have seen products or projects with clear objectives in terms of the goal of the product and even sometimes a measure of success in terms of measurable objectives.

I have yet to see the end goals mapped even at a high level to the stories and features, in most cases success criteria are wooly or undefined and more often than not the Product Owner and team will brainstorm stories (story mapping) without reference to the goals, and even Impact Mapping often will not extend to measurable goals.

That is not to say that the Product Owner is not considering this holistically, the measurements are generally part of the consideration but many stories creep in that have no material benefit or impact on the success criteria of the product.

From-the-book-User-Story-Mapping-by-Jeff-Patton

Measurements for Goals as the basis for Story Mapping

For reference I love Story Mapping, I consider it my favourite tool for Product Ownership and have been known to rave a little too much about it on occasion.

The start point in story mapping is typically to identify themes of user activities (you could call them epics but don’t get hung up on terminology they are essentially big rocks and then we will progressively break them down in to smaller rocks arranged underneath the big rocks.

We can then prioritise the work in the context of the whole rather than being constrained by a linear backlog which makes the context difficult to visualise.

It is also a fantastic tool for explaining the product for release planning and forecasting and so on. Like I say one of my favourite tools.

But what if instead of starting with activities or big stories, what if we started with our measurable goals or success criteria.   e.g. new subscribers per month, revenue per visit, time to achieve objective using application etc.  And we then identify stories that best enable us to achieve that goal.

There may very well be some overlap so there maybe the notion of tagging a secondary objective, but imagine if this helps us weed out stories that are not taking us to our goal or have limited value in the context of our goal.

We would ask which of these stories has the potential to move the needle the most? and prioritise accordingly.

download (9)

Make it measurable

Focusing our efforts on measurable impact to the product should implicitly be the goal of any Product Owner so why not make it our explicit goal?

 

 

 

 

 

Motor City – A Kanban Game : Overview

JSY_1323

Game Overview

The game is designed to reflect a simplified operating of a delivery pipeline for a car manufacturing plant.

The player accepts orders from customers, chooses which products to make and allocates resources and manages the plant to deliver cars to customers in the most effective way possible.

JSY_1267

Kanban

Each player manages a separate board representing a factory, the board is laid out as a Kanban board and the production is tracked as it moves across the board.

JSY_1279

Wip Limits

In the core game WiP limits are optional. Players may choose to apply WiP limits to manage flow, or just use their instincts.

If played for fun the WiP limits are not explicit, but if using this in a training environment I’d encourage explicit limits and for them to be strictly enforced to enable the class to evaluate the impact of WiP limits on the game.
I’d also suggest that each player experiment with different WiP limits to compare the impact with each other and discuss the results.

JSY_1276

Accepting Orders

At the start of a shift a player may choose to review and accept an order, once accepted an order must be delivered and if the player fails to complete an order they will be penalized.

Sourcing Materials

Each shift all players may choose to source materials for their production, this is done by selecting vehicle cards from the available selection, only 4 cards are visible and players may only choose from those available – this adds some competitiveness over resources, and an element of understanding your constraints and dependencies.

JSY_1264

Production

At the start of each hour within a shift one player rolls dice to determine the available production points for all players (all players get the same to make this game about the allocation of resources rather than the luck of the dice.

Each player is allocated a quantity of Manufacturing, Assembly and Quality production points which they can allocate over the course of the hour. Unused production points are discarded. The player also has the option to trade production points of one type for another but at a 4:1 ratio to indicate the impact of repurposing machines.

The vehicle cards are pulled through the system and production points are allocated as they progress through the system.

JSY_1305

Bottlenecks

There are a number of potential bottlenecks in the system and how you manage these will heavily impact the result of the game.

Game Success

Ultimately the winner will be the one that manages the production most effectively to meet their customers’ needs. It is hoped that applying Kanban and Theory of Constraints Practices will be rewarded, although there is an element of game mechanics and chance.


Purchasing the Game

The game is for sale at $120 + postage and is available now.  Game contains 4 game boards so is suitable for 4 players (or 4 pairs).

Please email me at john.yorke@yorkesoftware.com to arrange to buy the game.

Thank you for your support and encouragement.

JSY_1308

 

New Kanban Game Available

Around two years ago I was introduced to a Kanban board game which we used as part of a training program and I really enjoyed it, it was a great learning tool but it had three major drawbacks.

  1. First it was heavily scripted and so it was only suitable for a single play through, you couldn’t replay it and get more out of it.  It was not a game in that sense, it was much more of a training tool/prop.
  2. The second issue was that the exercise was taking 3 or more hours to run and whilst Kanban is a critical aspect of the training the return on investment was not sufficient.
  3. Finally it didn’t effectively address Little’s Law or the Theory of Constraints, there were aspects of that in the game but the heavy scripting meant that the learning was masked or even lost.

motorcity_Board-1

A New Kanban Game

It got me thinking and so I created a couple of workshop games that addressed this in more detail.   One of those workshop games was such good fun that I expanded it and combined it with training. For the last year or so I have been running workshops using it and continually looking to find improvements and modifications to make it more fun or to emphasize the learning aspects.

I have now presented this at a number of Lean/Agile conferences and have had a lot of great feedback, including a lot of encouragement to publish it as a board game.

Rulebook_cover

And so Herbie* – the affectionate name for the workshop game, became Motor City a Kanban based board game.  That is first and foremost fun to play and re-play, but the game is under-pinned with an understanding of Kanban, Little’s Law and the Theory of Constraints.  You can play the game without any knowledge of those and it will still be fun, but people that instinctively apply those practices or use them as a result of understanding will fare better playing the game.

*Herbie was named after the character from the book The Goal, by Eli Goldratt.

box_bottom

Game Prototype (Early Access)

The game is now in prototype, with a small number published for evaluation and for use in training and conferences, with the intent to publish the game more widely after getting feedback from the prototype.

motorcity_logo

To purchase the game…

The game is provisionally priced at $150 but for early access to the prototype it will be charged at $120
I’d love to hear of anyone that uses this as part of a training program or just as a fun game for your team to play.

If you would like a copy of the prototype board game for evaluation and feedback, please contact me.

Similarly if you are interested in training on the Theory of Constraints or Kanban and would like to use this game as part of that training, I would be happy to offer guidance on how to incorporate the training into a workshop.

Thank you

Thank you to those that have supported and encouraged me, I can assure you that board game design is far more complicated, costly and time-consuming than I ever imagined. In particular thank you to Toby Gerber who has helped with the graphic design and turning my ideas into reality, I could not have done it without him.

boxbase sm

Identifying Waste in Your Processes

I think as agile practitioners we can learn a lot from Lean thinking and there are a number of concepts of Lean that I think apply very well to Agile Software Development.

This is the second part of a blog attempting to convey the Lean concept of waste and I have introduced some ideas for how we can help mitigate waste in an Agile environment.

The 7 deadly sins

Lean identifies 7 wastes  (recently adding an 8th Waste)*

  1. Over-Production
  2. Inventory
  3. Transportation
  4. Over-Processing
  5. Waiting
  6. Motion
  7. Defects
  8. Wasted Potential of People*

 

Over-Production

explored in more detail here.

 

Inventory / Work In Progress

In manufacturing the physical properties of inventory are obvious, piles of raw materials, stacks of part built products, warehouses of finished goods are all big and obvious, but in software, inventory is harder to see, it is intangible to the casual observer.

In software, Work in Progress takes many forms, most obviously this is in the form of code, any code not deployed to a customer is Work In Progress, that code cost time and money to create, the raw materials are developer thought and effort.

But Inventory is not just code, it is also knowledge, it is thought and problem solving, unrealized ideas and even experience and learning.  Code is the manifestation of thinking, problem solving and planning. WiP/inventory is also the consequence and ideas resulting of conversations with users, usability testing, marketing. All of these are the efforts needed to create a product. But until those efforts are turned into a product it is all potential waste: time and money that are spent but until released to a customer are not providing value.

If we can learn to manage our Inventory/Work In Progress to limit it to only what we need and only what we can benefit from in a reasonable timeframe we can cut back on excess Inventory which in business terms this can have a major beneficial impact on our cashflow. Reducing Work In Progress also has the added benefit of making it easier to see  other waste.

Effectively managing your WiP is probably the second biggest opportunity for waste reduction and the act of limiting WiP will help identify other wastes in your system.

Transportation

In manufacturing, there is deemed no value in transportation. Moving a product does not add to it’s value and may even damage it with wear or breakage. reducing the distance between workstations or distance from your raw materials or the distance to customers can reduce the cost of time or effort and reduce the risk of wear or damage.

In software transportation could be best viewed as hand-offs, handing off work to another person or team requires effort, bringing them up to speed, co-ordinating, sharing the work. All this time and effort does not add any value to the software. But worse there is consequential loss of knowledge when there is a hand-off, and each hand-off results in a greater loss as the knowledge becomes fragmented and dispersed. Vital information may not be passed on leading to poor decisions, this is equatable to a breakage during transit.

Limiting hand-offs can reduce waste, having a team that contains all the knowledge and skills necessary to complete the work can help.  Steps to improve and enhance communication so that less knowledge is held by a small number of people can mitigate the loss of knowledge during a hand-off.  E.g. have all members of the team involved in story refining meetings so everyone is apprised of the intent of a story and can ask questions.

Over-Processing

In manufacturing this is making a product to a higher standard than is required or spending longer on something than is necessary, or in using a tool that is over powered for the job at hand.

This is similar to Over Production in many respects as is it unnecessary work, but in software it is obfuscated.  A feature may be needed, but we have over engineered it, spent more time and effort on it than is necessary.  This is not an excuse to cut corners, but development and test effort should be reflective of the customer need.

TDD – Test Driven Development can help here, by writing the test first and limiting coding to passing the test can help reduce over-processing.

However, many developers engage in EDD – Ego Driven Development where they write unnecessarily complex code to solve a problem so they appear clever to their peers.  Or RDD – Resume Driven Development where they introduce a shiny new: tool, technique or gadget, because… ” it is shiny and I wanted to try it out” or “It will look good on my resume” rather than because the product needs it.

EDD – Ego Driven Development where developers write unnecessarily complex code to solve a problem so they appear clever to their peers.

There is another form of Over-Processing and that is writing software to solve a problem that could be done more easily another way.  We have a great desire to automate everything but sometimes the solution costs far more than the problem we are solving.

The waste of this seems obvious when described here but can be difficult to spot in the wild, pairing and TDD can help keep the focus on the goal and limit the opportunities for over processing.

Over-Processing – Re-Learning

Another aspect of over-processing is the act of re-learning, if you have solved a problem once you should not need to solve it a second time, or if someone else has solved a problem can you benefit from their learning.

We can reduce this waste with knowledge sharing within the team or having the whole team in discussions about design or story refining so that opportunities to avoid re-learning are increased.

Avoid long delays between first looking at a product and then coming back to it later where you need to remind yourself of context better to only start work on something when you are ready to see it through.

Waiting

Waiting is any time that the product is not being actively worked on, this could be a story that is blocked waiting on someone or some event.  I think most people see that as waiting time, but any card that is not being actively worked at any time is ‘waiting‘.

Any state such as ‘dev done’, or ‘QA done’, or ‘ready for test’ or ‘ready to deploy’ or even stories written but waiting in the backlog are ‘waiting‘. Most stories will spend far more time waiting than they will being worked.

This is often a symptom of having too much work in progress, but items waiting may be a sign of a bottleneck or potential areas for improvement in your workflow. Kanban focuses on flow – minimizing the waiting time, so identifying any area where there is excessive time waiting is a candidate for improvement in the workflow.

Keeping track of repeat blockers, or being aware of areas of your system where stories regularly spend time waiting can help reduce this waste. Challenge any story that is not actively being worked and ask why.

One technique for this is for team members to each have only one avatar and have them place it on the card/story they are currently working on.  Any card without an avatar is waiting.  Only allow one avatar per person.

Motion

Similar to transport in many ways but refers to the operator or the operation rather than the transport of the product, could the workstation be operated more effectively.

In software this is sometimes interpreted as Context Switching which unnecessarily slows down the team, this is certainly a major part of it, but I prefer a broader interpretation, anything that hinders the team from getting the job done effectively, this could be having the right tools, the right environment, the team working effectively together, communication barriers.  But I can understand the desire to focus on context switching such as: support calls, emails, even distractions in the office space are forms of task switching that impair the effectiveness of the team to get the job done.

Identifying ways to improve the work environment and limit the interruptions could cut huge amounts of wasted time from your workflow.

Defects

Defects are another waste that gets compounded as a defect is exposed to all of the other wastes as it goes through the system which magnifies a problem that is already serious.

Defects are waste that grows the longer they go undetected, the problem itself is magnified by time and use, the more time the more frequently the defect occurs and the more users it impacts the more it costs you. That is until reported it is a hidden cost.

The waste is a hidden waste until much later so it can give us a false sense of security until the product reaches end of life and we have a full picture of the total lifetime cost we will not know the true extent of the cost of defects.

Another factor is that the cost goes beyond the impact of the defect itself the longer it goes undetected the less recent knowledge the development team has of the subject and so the learning time goes up.  How often have you been asked t fix code of someone that left the company years ago and have no clue what they were writing.  Once again one waste impacts another if that developer was using EDD you may have code that is so complex the effort to resolve is much higher.

We can try and combat defects with good development practices, such as pair programming, TDD, and comprehensive regression testing.  Any efforts we can find to identify defects sooner or prevent them occurring reduces the waste and the long term impact.

Wasted Potential of People

I have seen this added as an 8th waste of manufacturing, and it goes doubly so for software development.  In software development people are your greatest asset, it is a creative knowledge based activity and so providing the right work environment and opportunities is essential to getting the best from your people.

Demotivated people work slower and with less care, but enabling people to reach their full potential could reap rewards for you and your products.

Summary

Any system will have waste, some is necessary and some is not, but being able to identify what is necessary and what is unnecessary or what is waste and what is slack can greatly enhance your chances of making improvements that really help your software development process.

Often what you thought was waste is actually a valuable activity and what you thought was adding value was just adding waste. Understanding this helps you make the right decisions.

However, please remember – It is very important that waste reduction is NOT the Goal of your efforts,  Waste Identification is a supporting activity for the Theory of Constraints, any efforts to improve a part of your system that is not the bottleneck is a waste in itself.

Your goal is to improve the entire system and focusing on one area without consideration for the system as a whole leads to the wrong decisions being made. Waste is just one of many considerations.

 

 

 

 

 

Weeks of coding can save hours of planning 

In the context of Lean manufacturing there have been numerous studies that estimate that the proportion of value adding time in a production cycle is around 5%. The other 95% is deemed to be waste.  These studies also conclude that by far the biggest waste is overproduction.

Anecdotally I think it is a very similar story in Software development although my fear is that the proportion of value adding time is even lower.

Waste takes many forms but broadly speaking effort as a team/company fall in to three areas:

1 .   Valuable Effort – Value adding activities, these activities cost time and money, and there is a consequential opportunity cost but they add some value.   However, the value may be able to be realized more effectively.

2.  Obvious Waste – Non-value adding activities that are evident. These activities cost time and money (and opportunity cost) but add no value to the product being created. Examples are vacation, breaks, sickness.

3. Valueless Effort – Non-value adding activities masquerading as Valuable Effort, they cost time, money and have an opportunity cost but add no value to the product being delivered.

Waste Reduction is Not Your Goal

I will be covering the wastes in more detail but it is very important that waste reduction is NOT the focus of your efforts,  Waste Identification is a supporting activity for the Theory of Constraints, any efforts to improve a part of your system that is not the bottleneck is a waste in itself.  But identifying waste can aid in your efforts to improve your bottleneck so is a great tool to support your other activities.

 

The 7 deadly sins

Lean identifies 7 wastes  (recently adding an 8th Waste)

  1. Overproduction
  2. Inventory
  3. Tranportation
  4. Over-Processing
  5. Waiting
  6. Motion
  7. Defects
  8. Wasted Potential of People

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

Overproduction

Overproduction is considered the worst of the wastes and ultimately it is this particular waste that is the basis of much of the Agile Manifesto for Software Development.  Which is why systems thinking is a topic I keep coming back to.

Agile is founded on the premise that at the start of the product we know the least and lack of flexibility is the biggest constraint in the success of software development. Traditional methods plan, create, test and support endless features that were unnecessary, the cost of this waste is unfathomable and big enough to trigger the Agile movement and challenge the way we work.

Overproduction was also the primary waste identified in the book “The Goal” by Eli Goldratt, and if you haven’t read that book I would heartily recommend it. The book is . great primer for the Theory of Constraints and for understanding Lean thinking. 

Planning is Waste?

But Agile has not completely fixed this problem, and in my experience development teams regular and persistently develop unnecessary features.  With many teams choosing to work without sufficient time spent planning; story writing; prioritizing; and without consideration for whether the work they are doing adds any value now or more significantly adds the most value next.

Road mapping, planning and even story writing are often incorrectly perceived as ‘waste’ and the avoidance of waste is used as a justification to get back to coding on something that is likely not valuable and almost certainly not the most valuable activity to be worked on next, which is a far more insidious waste than the planning ever could be .

Features “not needed yet” are implemented on the basis that it will save time later, or features are added because “We know we will need it later” – (7 words I dread to hear.)

We work to look or feel busy, in our minds we translate activity as being productivity when there is little correlation between the two in the context of software development. In software, creativity; problem solving and planning are far more valuable efforts than unfocused coding.

Give me six hours to chop down a tree and I will spend the first four sharpening the axe.

Abraham Lincoln

In most cases features have no value until they are in the hands of a user and being used for productive effort. So any activity not spent getting the next most valuable feature into the hands of a user quickly is just waste.

Writing extra features that are not used or rarely used extends the production time but brings little or no value, it also compounds all of the other wastes because by it’s nature production of something of little value needs to go through the system thus exposing an unnecessary feature to all the other wastes.

When you next start work on something ask yourself: “Is this the next most valuable activity for our customer?” If you cannot confidently answer that question then maybe you need to spend more time planning so you can spend less time coding something that is not needed.

The worst case scenario

In software the biggest risk to any project is that it will be cancelled or obsolete prior to being used by your customers.  This may sound obvious but if a project is cancelled ALL of the features are/were waste. All that effort produced no value for anyone.  That time, effort and money could have been spent elsewhere.  So getting your product right is only any good if you get your product delivered.

Delivering value to your customer quickly is the best way to mitigate the risk of your efforts being wasted, and Done is not really done unless it is in the hands of a customer and actually being used for a productive purpose.

 

Overproduction is a big topic and deserves a little extra focus so I’ll delve deeper into the other wastes another time.