Learning To See Waste
In Lean, waste is anything that does not add value. The key to Lean is getting work flowing rapidly and this is done by identifying and eliminating sources of waste. Some sources of waste are obvious - tasks blocked through lack of feedback, rework due to misunderstood requirements and things like that. Some sources of waste though are not so obvious. Some are so insidious that we live with them all the time and assume they are an inevitable part of daily life.
Scrum Australia 2013
Over the last 2 days I have been taking part in the inaugural Scrum Australia conference. We have had Agile conferences for a while but this was the first specifically Scrum-themed one held in Australia.
Scrum - It's Not All About The Developers
I recently checked back in on a team I had started up a while back. Over the months since I had set them free they had made a few modifications to the process and in doing so had fallen into one of the most common traps I have seen teams fall into - they had made it all about the developers.
My first inkling that there was something amiss came when one of the testers on that team approached me for some advice on how she could be more efficient in her testing. She felt she was falling behind. When I dug a little further it turns out the team had delegated the job of unit testing to the testers to "free up the devs". This was in addition to the acceptance test automation the testers were doing as well. The devs had also resisted any attempts to assist with testing so "they could be more efficient".
Delivering Value - Uncovering The Real Needs
The key to Agile and Lean methodologies is “the rapid delivery of customer value”. Anything that does not add value is considered waste. In Agile, value is often defined as “working code” but this is too narrow a definition. It assumes that the only stakeholders that matter are the end users of the software and that the only product the team needs to produce is the software.
In reality, the team is unlikely to be producing just software. At the very least there will be documentation and other end user collateral. There will also be artifacts that are not valuable to the end user but may be of immense value to other stakeholders. It could be argued then that pretty much anything turned out by the team has value to someone. So what is waste? Working code is too narrow. Absolutely anything the team does is too wide.
Task Switching...And why it's bad
OK... Imagine for a moment that I have three tasks that I need to do. Each task will take one week. The deadline to complete them all is three weeks. They are all equally important.
I have two possible ways to divide my time. I can do the tasks sequentially, or in parallel. Finish one then do another, or work one day on each then switch to another -