3 commonly missed benefits of Lean & Agile

The business benefits of Agile and Lean are often misunderstood.  I’ve seen this lead to painful attempts.

Non-technical people often buy into Agile and Lean as a faster way to build what they want. They try to employ developers without seeking to understand the process of developing software. Frustration results.

At the other extreme, I’ve seen teams get excited then go through the motions without getting the gain - creating MVPs or using Pivotal Tracker - and finding it just leads to wheel-spinning and wasted effort.

Having been through both of these scenarios myself, I find it helpful to explain Lean and Agile in terms business proficiency rather than development methodology, focusing is on the improvements offered to the whole business. How do Agile/Lean offer lower management overhead, faster response to market, and more informed decision making? Understanding this helps put the process into context.

I’m also aware that I still have a lot to learn from experienced Leanists and Agilists, so this is an invitation to be taught as much as it is an attempt to explain.

Moving as a team

In Agile, iterating means releasing a working version of the product on a regular basis, usually every one or two weeks.  Lightweight tools like User Stories replace pre-planned specifications. Stories are fast to pick up, and quickly communicate the 'who' and 'why' in addition to the 'what.'

Does everyone on the team share an undestanding of what's being built, and of why and how it's going to be used?

A benefit of Agile is the whole team sees the bigger picture, and understands why they're building what they're building and how it'll be used. They can go to the direct source if they have a question, so you reduce the likelihood of building what you asked for but not what you wanted.  There's a phrase in Agile circles: "a Story Card is an invitation for a conversation."

Do you trust your team to make unforeseen decisions on their own?

When a project goes wrong, we suddenly have to cut things out of the plan at the last minute. Iteration allows you to communicate priorities with each other in advance so the team adapts naturally to unforeseen circumstances. Think of this as the way journalists write an article; the most important parts are always at the beginning so the editor can chop the article at any paragraph and it still works. Imagine if everyone on your team worked this way. When you have confidence that everyone understands the real priorities, you can reap the benefits that come from true delegation.

Understanding customers

Customer understanding is of limited value unless we can act on it.  Similarly, we see adaptability as a good thing, but adaptability to what? Adapting to a changing competitive environment can be achieved through research and leadership, but adapting to customer needs can be better acheived through frequent course-corrections based on direct customer contact.

Delegating responsibility for customer feedback – for example to Support or Customer Development – strips the team of their ability to regularly see how their actions affect their customers. Frequently deploying your product in front of customers gives the whole team customer feedback on a regular basis - a massive benefit that’s often overlooked.

Also, pre-planned iterations strip of you the ability to react and adapt. If you’re turning milestones and deadlines from project plans into iterations or sprints, you’re probably losing out on the course-correction opportunities.

Informed business decisions

As your ability to produce quickly improves, it gives you powerful decision-making capabilities.

Before, when you had a new idea, you and your team had to make the decision with a lot of unknowns. Should we build this or that feature? What will it look like? Should we charge for it? Will it affect support costs? How should the UI work? How much functionality is enough?

There was a lot to “get right” if that idea was going to work so the initial idea led to deep discussions. Lots of opinions, guesses and discussions, all the possible ways it could go wrong and how to prevent that. Then the planning.  Then, you’d actually start! Because of the high cost of making decisions with so many unknowns, are your small decisions taking longer?

With Agile and Lean production in place, you can start to collect information at the outset, before the key decision is made, and reduce the risk and cost of “getting it wrong.” Separate questions can be answered by making immediate but small deployments to a subset of users, and actually measuring the effect. Real information becomes easier to collect, and lowers decision-making costs. You can test a feature, or make a small change to your support documents, and know the effect.

This means that when you make big decisions, you actually have answers in your hands, rather than guesses, so you can act more decisively.

And since you can deploy code in smaller parts, you don’t have to plan it all in advance. There’s less to get right and less to predict and discuss.  Because decisions are made with real information rather than educated guesses, they become easier, more frequent and correct more often.

"Getting It Right"

A last word of caution - the idea of "getting it right" is a big discussion among Lean/Agile process-geeks and managers. A big Lean principle is making the right decision for your context, and I've heard this sentiment among experienced Agilists too.  On the other hand, it's a shame when I hear about a well-intentioned attempt at Lean or Agile that flopped because the process and tools were used without an adequate understanding of the gains offered . The attempt was abandoned and the effort wasted.  If you or someone in your team is getting the Lean/Agile bug, I'd recommend you learn the gains from others who've been there, then the tools and process will make more sense and you're more likely to grok how to make it work for you.