Agile / Lean development — Waste is Eliminated

Background

At Redgate we believe strongly that the best way to deliver valuable software to our customers is via agile and lean development practices. To support this we’ve been working to create a clearer picture of what good looks like (WGLL) for an Agile/Lean development process so teams have something they can reference as they look to continuously improve.

We’ve identified 9 principles which are important to us. This post explains the “Waste is Eliminated” principle in more detail.

Why “Waste is Eliminated”

One of the twelve principles of the Agile Manifesto is:

“Simplicity — the art of maximizing the amount of work not done — is essential.”

Equally in Lean, one of the five principles is mapping the value stream, where the goal is to identify every step that does not create value and then find ways to eliminate those wasteful steps.

These principles are key to working in a lean agile way

What does waste look like in software development?

Waste in software development can manifest itself in many ways and you can think you’re doing a great job because you feel really busy, but in reality, it may not be that effective.

• Have you ever found yourself switching between tasks, leaving one, part done, to progress another, only to then switch back, leaving that one half done to make a bit more progress on the first?
• Does your team have some partially completed work with nobody actively working on it?
• Do you find yourself wishing you had more people to help with answering escalations from support and not spending time fixing the issues that caused those escalations?
• Do you understand why the steps in your development process exist, or do you do them because “that’s what we’ve always done”?
• Do you find yourself building lots of error handling into some code, or making the UI pixel perfect, when the purpose of it is to see if the users like the idea of it?

All of these are examples of where waste may have crept into your process.

What does good look like?

• Teams will have a defined process and understand the value each stage adds.
• Teams limit the amount of work they have in progress / not released
• Teams defer making decisions until the last responsible moment — they don’t box themselves into corners — they reduce the amount of rework (n.b. the key word on this one is “responsible” — don’t fall into the procrastination trap)
• Teams have established a “need” before embarking on developing a feature
• Team regularly reviews its processes to eliminate wasteful process
• Team frequently inspects its goal(s) to check it’s still the right thing to be doing
• Teams readily make use of solutions (designs / code libraries etc) created by others (internal or external)

How to get good

There are many techniques you can use to help your team achieve this amazing state

• Stand-ups and retrospectives are a great way to ensure you’re all focused on doing the right thing, and to review your processes and agree experiments to see if improvements can be made.
• Kanban, with WIP (work in progress) limits are a great way to control the amount of work started and identify the bottlenecks in your process — with that information you can inspect and adapt.
• Systems Thinking; Current Reality Trees; The 5 Whys are all techniques that can help you explore your process and the problems you’re experiencing
• User story mapping and focusing on an MVP (minimum viable product) can help ensure you’re focusing on the right bit of functionality, and a Spike and Stabilise approach can help ensure you don’t gold plate unnecessarily.

These are just a sample of techniques that can help get you started on this topic.

And if you find something else that’s worked for your team, we’d love to hear about it.