Month: October 2017

WiP Limits and Velocity

I recently presented at a conference on the topic of Work in Progress (WiP) limits, and in particular Little’s law.  As part of I gave a demonstration and from it drew the conclusion that WiP limits have no direct bearing on velocity.

This caused some controversy so I’ll try to explain again here.

little

Applying Little’s Law

Mathematically speaking we can increase the speed with which we get served in two ways:

  1. We reduce the number of people in the queue (We limit WiP)  or
  2. We increase the speed each person is served (We increase Throughput – in this case by adding more people, or installing faster equipment)

Note:  When mathematically applying Little’s law the pre-condition is that the variables are independent, the assumption is that number of people in the queue does not impact on how quickly the server works.  This works in mathematics, but maybe not so much with people in reality.

The principle is that WiP and Throughput are two independent variables and changing one does not change the other, only cycle time is impacted.

The wider impact of WiP limits

Of course the goal of my talk was to illustrate that whilst you may feel you are getting more done by not limiting your WiP, and having a whole bunch of work in progress this has no bearing on your actual throughput which is governed by your bottle neck.

When using Little’s Law in a controlled environment we can show that limiting WiP doesn’t impact throughput (unless we limit it to less then our bottleneck and starve it – say two servers and limiting the queue to 1 person). What limiting WiP does do is reduce cycle-time enabling you to be more flexible and more responsive and to have more reliable forecasts.

Work in Progress Limits will directly impact Cycle-time

Contradictory Claims

Unfortunately this contradicted one of my other claims in the presentation where I said that Limiting WiP helps increase throughput of the team.

The confusion of course is understandable, when using a mathematical example there is no cost for context switching and the example was to show the impact of WiP on a stable system isolating variables to demonstrate what happens.  The real world is far more complex and there are many more variables.

In the real world

Generally speaking the ability to focus on less things means less multi-tasking, reduced cycle time means you have less things on the go at once, and for less time. These help you be more productive and thus indirectly the throughput will go up, but this is a result of you being able to focus not as a direct impact of the WiP limits.

There are many indirect benefits of using WiP limits,  but Cycle-time is the prime beneficiary, the rest is a bonus or an indirect consequence.

 

 

 

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

The 4 steps to successful software delivery

After [reading / posting] a recent article on waste, (read it here), someone asked me why we shouldn’t do work that we will need later if it is more efficient to do it now?  You have already dug the hole—doesn’t it make sense to do all the work in that area together?

This is very similar to the argument for splitting stories horizontally along business layers: “We can be more efficient if we optimize and specialize.”

Yes, you might achieve local efficiencies by taking these steps. But local efficiency is not the most important factor in your decisions. Efficiencies and optimizations need to be considered in the context of the whole system.

The primary goal is to Maximize Value Early

For both project and support work, our goal is to maximize value for our organization, and to realize this value as early as possible.  In a consultancy firm, there is a slight abstraction, as work is paid based on time and materials, and these steps are distributed between client and team. Regardless of who owns the following steps, success depends on shared awareness of these priorities.

The 4 Steps

The four steps are designed to focus our energy where it will have the most impact first, and then building upon the previous step by shrinking the focus area through each subsequent step. Hence they are in descending order of impact.

1 – Prioritization
(Selecting Which Project/Product to Build Next?)

The most important decision your organization needs to make is which work will bring the most value NEXT. This has the most impact on your company’s bottom line, so should get the lion’s share of effort and focus.

Program Management

 

Describing the value a project will bring is far and away the most important aspect of software delivery. If possible, create a formula for calculating business value to help with these decisions. If you are unable to quantify or qualify the value to the organization of the work being undertaken (at a high level), then you are likely working on the wrong thing and all other actions you take could be waste.

Some projects/products will obviously bring in huge amounts of revenue. Others may save huge costs in manual entry and work-hours. Some may support business-critical systems that, if not supported, create extensive risk and potential cost. A project might also fulfill a safety or regulatory concern, or business objective.

Naturally this is complicated and can be difficult. Priorities change. Time factors and organizational politics come into play. A lot of the time you will be making informed guesses about value and costs. But this decision dwarfs all of the others in the impact to the bottom line, so is critical to put the right amount of effort here.

I would consider this to be the responsibility of the Program Manager or Project Management Office, but I see the responsibility to be to identify the projects that will bring most value to the organization as the end of their role. “Day-to-day Project Management” responsibility lies elsewhere.

I would however strongly encourage this decision-making process to be transparent and inclusive.  Hold a regular Project review board and invite the stakeholders. Make the process clear and help everyone understand how the decisions are made. I would also suggest a visible roadmap of work planned.

Finally, I would encourage you to not plan beyond your company’s horizon. If new work is likely to emerge in the next 3 months that may significantly change priorities, then only plan for 3 months.  Only start a product or project at a point you feel committed and certain it will be completed. Starting something with the expectation of pausing or pivoting suggests it wasn’t the most important thing to work on next.

2 – Direction
(Product Ownership – Building the right Product)

Whether this a new product or supporting an existing product, it is important to ensure that you build the right product,  Product Ownership is covered in lots of detail in other places so I won’t go in to details but I suggest watching this video:

po nutshell

Like prioritization in Step 1, the most important responsibility in Product Ownership is Maximizing value–Are you working on the most valuable thing next?  You do this through experience and through feedback from users and stakeholders.

Feedback is crucial. To get frequent user feedback, you should be thinking about how you intend to deploy your software and then update it regularly. You should be thinking of this before or with your first story.

Deployment and ongoing updates should not be an after-thought.

Product Ownership is also about maximizing the work not done. The product should meet the needs and goals but only do what is necessary. There will be a point when the returns diminish. All work carries an opportunity cost, and at some point your time is more valuably spent elsewhere. Understanding this is vital.

Finally, I want to stress the importance of getting value to the customer quickly. Value is only realized when the software is used. We should be striving to getting the software in use as soon as possible. This may be in an unfinished state. It may be only a partial solution, but it should be adding value. e.g. it can be used alongside an existing product, or it could be used for this workflow but for another you use another tool etc.

Feedback from people actually using your software is the most valuable feedback you can get.

Just like prioritizing projects, prioritizing stories has far more impact on the success of the project than the following steps.

3 – Quality
(Build the Product Right)

Building the right product is more important than building it right. Building the wrong product is just a waste. But that doesn’t mean that quality is not important.

Quality means doing it right when no one is looking.

Henry Ford

When assessing cost of software, it is easy to focus on the initial development cost alone. But support maintenance and future enhancements all fall into the total lifetime cost of a product. The cost of defects magnifies over time, and the cost of supporting poor quality code is significantly higher and more risky. Re-learning and knowledge transfer are painful and costly to an organization and I can think of numerous examples where companies have been forced to abandon projects or replace software because they lost a key employee who had the knowledge locked in his head–or software so fragile no one dares touch it.

Good practices such as Test Driven Development, Pair Programming, Behaviour Driven Development and Automated Regression Testing may seem costly at first. But when considered in the context of lifetime cost, they are a sound investment. More importantly, they enable the right business decisions to be made because there is a confidence in the software.

Quality code with a solid set of tests enables refactoring and new features to be added with the knowledge you are not causing unintended consequences elsewhere by breaking older functionality. This reduction in risk is a considerable advantage, especially when supporting older applications.

This is not a carte blanche to gold plate or over-engineer. Quality Code is the right code for the story and No More. We write just enough to satisfy the story and we write it well. Over-engineering applies to the GUI too–we don’t add features or over-engineer.

4 – Efficiency and Improvement
(Building it Better and Faster)

By this point we should be working on the most valuable product to our company. With that taken care of, our next focus is to work on the most valuable feature or story for our users/customers. We should be doing it in a manner that enables us to be confident in the work and able to expand it later.

But guess what? You can do it better.  We should reflect on the decisions we made and how we make them. Are we making the right decisions?  What helped us make those decisions?  Are we making the wrong decisions? If so what could we change to avoid repeating those mistakes.

The reflection and improvement should be done at all steps and should incorporate the learning from all stages.  If we continually look for ways to improve we will get better and better.

If you always do what you always did, you’ll always get what you always got

Henry Ford

 

What about efficiency of developer effort?

So what of the original question about being more efficient with horizontal splitting of stories, or the perceived inefficiency of re-working the same area of code later?

It is a question of impact and perspective. In both cases the question is founded on ‘efficiency’ being a measure of the developer’s efforts.  What I would like you to consider is that in terms of delivering value to your users and ultimately your company efficiency should not be measured in terms of developer effort, but should be measured in terms of delivered value.

Efficiency should not be measured in terms of expended effort, but should be measured in terms of delivered value.

The most valuable decision is to work on the right project – this dwarfs all other decisions by an order of magnitude. But it is at a different level of scope than this question.

The next most valuable decision is what to work on. This generally best considered from the perspective of delivering value to the customer quickly and of being able to respond to their changing and emerging needs.

When we split horizontally or when we do extra work, we know we will need later we may give the appearance of making more efficient use of developer effort, but in doing so we reduce our ability to adapt to changing needs and more significantly we delay the time to deliver the next most valuable feature.

This is an example of working with a waterfall mindset. The measure is that while it delays us this week, we will make back the time next month or next year. So if we are not planning to deliver this to our customer until next month or next year, it might appear to make sense. But you may not have considered two factors.

If we are deploying frequently, we are realizing value with every release and in the value of our software isn’t massively more than the cost of developer time to create it, then it is likely we shouldn’t be working this project at all. So ultimately the cost of developer effort for having to rework the same code later for a new feature is insignificant to the value gained by delivering sooner. We should measure ourselves based on value delivered not the effort to deliver it.

The second consideration is that the work you are doing on the assumption of needing it for a future feature may not actually be needed. That feature is by definition lower value and less important as it has been prioritized lower.  There is a pretty reasonable chance that the customer may change their needs or there is the possibility of the project being cancelled or considered good enough as it is.  That work may never actually be needed and you would have delayed the project for work that had no value. The efficiency you are trying to achieve may just be an illusion.

This is the business equivalent of spending $10 today to save $1 next year.

When considering efficiency and improvement, remember your goal is to maximize value to your customer and to realize that value as quickly as possible.  Ask yourself if the efficiency improvement you are proposing fulfills those goals? If not it may be just be an illusion.

 

 

 

 

 

 

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.