Learnings on waste!
The concept of waste is something I have only recently started to learn. This is due in part to my immaturity in the software development world, in particular, my lack of on the ground agile software development experience, lean, SAFe, XP modern agile, etc…..I’ll freely admit, the concept of products in IT and product development is new for me, but an incredibly refreshing concept. Regardless, it is something that I find incredibly compelling and inspiring. The mere shift in mindset, from doing or managing a project to building a product has had an immense impact on me. Positive of course! Thanks @neilKillick.
Waste is something, I feel, I have let build in my projects in the past and no doubt my current. So, what is waste?
This blog, as with pretty much all my posts is an attempt at self-learning and in turn, share my insights with the few readers that take the time. I’m by no means making any progressive statements into waste that haven’t already been made.
The Toyota Production System(TPS) identified 7 major types of waste:
The Poppendieck’s later translated those for software development:
Partially done work
Essentially what waste is encouraging us to do, is look at the moment we get a customer requirement to the point when we deliver something of value back. And throughout this, we are reducing the time line by reducing waste.
1. Partially done work is wasteful, why? It’s a distraction! It’s something that keeps diluting our capacity to deeply focus on new work. It can lead to impacting the team’s rhythm, reducing confidence by not seeing the efforts of the team released as working software. A sign of partially done work might be too much currently “In-progress”. A number of features may sit waiting to be tested, all the while more work is being pulled in, potentially leading to a build-up of incomplete work, or partially done work.
2. Extra features can be wasteful, why? Are we not going above and beyond to deliver more value? From what I understand, extra features relates to Toyota’s “Overproduction”. It ties to ensuring what you build is what is needed. Extra features represent that last minute add-in to scope, the person with power or outspoken capability to push something across the line, just because the business “know” the customer needs it. This can happen even when there is little or no evidence to support its value. Extra features correlate to increased on-going expense/overhead. All features should be tested, maintained, tracked and off course, released to customers. There is an inherent cost in keeping a feature in customers hands regardless of whether it adds value or not, the value-add, of course, justifies the on-going expense to keep it. If something isn’t pulling its weight, why maintain it? Why distract your customers with it?
3. Relearning, seems to imply that there is little room to fail and learn from it, or as Samuel Beckett said:
“Ever tired. Ever Failed. No Matter. Try Again. Fail Again. Fail Better.”
However, when it comes to waste, relearning relates to all the things/overheads we do that don’t provide any direct value to our customers. They are pure overhead. Excessive documentation or laboured signoffs or change control forms or complicated risk registers. Relearning also talks about team member turnover. If you don’t care about your team, or as modern agile teaches us “Make people awesome” or they’ll leave/disengage, simple as that. Relearning waste can relate to time lost handing over to a new team member. Essentially knowledge is being relearnt due to the predecessor walking out the door.
Constant interruptions or multi-tasking, can this be relearning waste? Every-time you break from what Cal Newport refers to as deep work(amazing book by the way, link, go buy it!) it will take at least 15 minutes to “relearn” your way back up to your last point of progress. If you are constantly shifting between tasks, there is a lag time in getting up to speed, “oh, where did i last leave this?” This is something my manager is incredibly good at preventing. @TimTunbridge is always pushing to see whatever task is at hand through to completion, or at least as far into the “Done” zone as is in his control.
Documentation, the agile manifesto talks about interactions over documentation, put it doesn’t talk about no documentation. The relearning of the same knowledge is a bit of an achilles heel for me. At points when I’ve analysed, or understood something, worked on a solution/design, but haven’t clearly documented my progress. There is a number of wasteful actions here, I’ve left work that is partially done, and further to this, I’ll lose time in the rework/relearning, in order to get to my last point of progress. Understandable we don’t work in a vacuum, so we don’t have the luxury of seeing all work started through to completion. However, there is waste and it is much larger than it could be if quality documentation was adopted.
4. Handoffs! What the hell are they? It basically relates to a teams workflow. An analyst, pulls from the backlog, documents requirements, engages the business, gains their approval and all seems ready, and then they “throw it over the fence” to a designer, they put their 10 cents into it, who in turn “throws it over the fence” to an engineer! Something is built, now it must be “thrown over the fence” to a tester. Fundamentally, this, handing off approach is waterfall development, they are staging their work independently. What is the waste? The team is in a way playing a game of “Chinese whispers”, the features value gets lost or distorted by being passed around. It’s actually quiet astounding. Poppendiecks’s suggest 50% of knowledge/value is lost from every handoff. From Analyst(100%), to UX(50%), to engineer(25%) to tester(12.5%), 88% is essentially lost by the time it gets out the door to a customer!
88% is essentially lost by the time it gets out the door to a customer!
5. What about delays! This seems pretty apparent, right? It’s about closing gaps on the end to end process. The team gather customer insights, translate them into some form of requirements for a build and then capture feedback on that shipped feature. Spending large amount of project time documenting all the requirements, having large amounts of work in progress, thus encouraging partially done work, all lead to delays in getting work through to the customer. The Lean Startup talks about some of the initially things the author, Eric Ries does when consulting with a business. He essentially starts by limiting the amount of work in progress and putting constraints in place to prevent anyone within the team from pulling new work from the backlog. This is managed by setting up “WIP limits” – WIP – work in progress, limit – only accepting a certain quantum of work to live in a state of progress, be it; “design”, “build” or “testing” as an example.
6. Task switching, surely an obvious point of waste. as i’ve said earlier in this post, every time you jump from task to task, you lose that time to re-familiarise with the task. Tying back to sprint planning in scrum, it is a regular point of complaint that so much time is lost in planning; “there is so much work today, I should waste time planning, just tell me what I’m doing”. Without a clear goal or set of goals, the chance of task switching grows, as does a lack of shippable features. A reduction in task switching, significantly increases focus, which should increase the likelihood to deliver some level of customer value much sooner.
A great example of this, is the agile gardener! On the weekends I like to get out into the garden, I mostly, just sweep, mow, whipper snip and weed, at the end I collect up all the debris or waste for the compost bin. Now, if we consider the process of preparation – getting the tools out and ready, doing the actual maintenance and the final task of collecting the debris and putting it in a bin. A traditional and seemingly efficient process would be to take all the tools out, then conduct all the maintenance, mow, sweep, weed, cut stuff, then collect the debris into piles and finally putting the waste or debris in a bin. What happens if something interrupts me at any point earlier than disposing into the bin? I’ve essentially delivered no value to my garden admirers(mostly my lovely wife). If I focus on each of my associated tasks in delivering the goal of a neat garden, I can reduce the risk of not tidying my garden, by completing each task rather than starting many of them at once. I might mow then put the grass waste in the bin. I might whipper snipper, and follow that by sweeping up the debris and putting it in the bin. I might then sweep the remaining general debris and put that in the bin. At each point of putting debris in the bin, I’m making valuable progress to a neat garden, because each task has a neatness value in of its self. Therefore I’m closer to continuously delivering value.
7. Defects! So, this is probably a pretty straightforward form of waste. If we commit to spending time building our product and as part of the process we are producing waste, we should be looking at ways of eliminating or reducing defects as much as possible. A defect can simply transpire to be some unideal state or transaction during the customer journey or it can be the heavy overhead of a demanding approval process. The Poppendieck’s have a formula which is:
Waste = (Impact of Defect)*(Time Defect Lies Undetected)
Essentially the longer you leave a defect in the product the greater the impact. I guess at a basic level, a defect with a low or minor impact might only cost $0.05, however, because the defect is minor, it’s not a smoking gun, and therefore is left, for maybe 4 or 5 months. Depending on the overlap of this defect, this could easily lead to 100’s of thousands, if not millions of dollars lost.
I hope you enjoyed my attempt to learn about waste. I’d love to hear your comments.