New to agile? Remember to eliminate waste
When I teach any agile course I start out with the principles of lean that Mary and Tom Poppendieck have written about in their books. The very first of these principles is Eliminate Waste.
What does this really mean in practice? Let’s start with a definition – waste is anything which does not add value. We’ll leave the blog post about what value is for sometime in the future. For now let’s focus on what some non-value adding activities could be.
High on my list are two things we often take for granted: a) email and b) meetings. Let’s start with email. How much of it do you get? How much of it do you read? How often do you read email? Now on the other side – how much of it do you really need to be getting and reading? Last year I had a blog post on how Outlook is causing problems with agile teams which may be worth reviewing. It is astounding how much time we waste each day on email. Take some of the tips in the Outlook blog post and see if your productivity improves. Then remove yourself from some mailing lists that you never really pay attention to. Finally, try to empty your Inbox by doing something with each message – delete it, delegate it, or do something with it (file it or answer it). If you need a more serious intervention try this book:
Now, what about meetings. I won’t say a lot here about them because we all know in the past 30 days we have probably been to one or more meetings that we shouldn’t have been required to attend. Do yourself and your organization a favor – send out agendas for meetings you call. Ask others to do the same. This way people can make logical choices about attending each meeting.
What other wastes are there? An astounding number. Here are some of the big ones:
- Partially done work – any work in progress is waste because it isn’t delivering value yet. Try to minimize the amount of work you scrap. Do this by concentrating on high priority items and getting them completed. Remember, “just enough, just in time“, not “almost finished, but not quite!”
- Extra features – 64% of features are rarely or never used (Standish Group study). Look at each feature very carefully. Cut out the lowest value half before you even start.
- Complexity – I’ll have a lot more of this in a future blog posting, but suffice it to say that agile architecture and agile design are NOT oxymorons. Keep in mind that you are always trying to do the simplest thing that solves the current problem.
- Paperwork – need I write more? It is 100% waste to create paper by reformatting things available digitally. It is 100% waste to create a status report rather than having status be visible as a result of doing work (think about the taskboard and how it shows status).
- Delays – are there any points in time when your process gets delayed? A delay is always waste. It is time which can never be recovered. If your process has lots of periods where things are delayed, then those areas need to be closely examined.
- Churn – task switching, project switching and other switches cause churn. If you are working on more than one thing at a time you are losing efficiency and causing waste! Organizations need to recognize that shared resources while sounding good end up losing a lot of productivity to churn.
- Silos – when everyone has their own area of expertise the team will suffer. It is nearly impossible to get “flow” through the process when there is a handoff among nearly everyone on the team. We often have this in miniature when we do design then do coding then do testing, while still calling it agile. I call that Wagile (pronounced waj-il) for Waterfallish Agile. This will cause waste as people responsible for one part of the process wait on others to deliver something to them. That’s before we even consider the wastes inherent in the waterfall process alone.
- Lost knowledge – this is one many people miss. Why do we do “Lessons Learned” meetings at the end of projects if we aren’t ever going to learn those lessons??? We need to make sure the things we learn are captured and easily accessible to others. This is absolutely vital to improvement.
Some examples of areas of waste which can usually be eliminated: meetings, emails, status reports, and approvals. Areas of improvement include creating less architecture (just enough), less complex code (simplest solution that solves the problem, consider refactoring and pair programming), prioritization (work on highest priority item first, complete it, then move on), cross-functional teams (pair programming, shared code ownership, look for mentoring opportunities), and reducing churn (reduce the number of active projects, only work on one task at a time until it is either blocked or completed). Other things to consider include coming up with at least one action during every retrospective which will help reduce waste, eliminating something entirely for an iteration followed by deciding which small parts need to return, and making a rule that email should not be used for communication unless the email is less than 2 lines in length.
I know a lot of these things are difficult to change, so let me tell you a story to make the importance clear. As a trainer I have done many seminars and courses where one of the exercises is to create a value stream map of a process. I specifically tell attendees to pick a process where time is critical to their organization. Most end up picking something like a bug fix process. Once the value stream map is created we then calculate process efficiency by dividing value added time by total time. The average efficiency has been about 16%, although I’ve seen numbers lower than 1%! The second half of the exercise includes redrawing the value stream map by making changes that could eliminate waste. The efficiency usually goes up by a factor of 2-3X. There are huge gains in productivity just waiting for us to take them.
Do you have any good ways you’ve eliminated waste which aren’t mentioned here? If so, be sure to leave a comment so that others can learn from you!
Make eliminating waste a mindset in your organization and you will be successful in Making Agile a Reality™.
Thank You very much, Bob for another great Blog…