As a coach, I’m getting truly tired of talking to managers and leaders who’s sole drive to adopt agile methods is for…
More, increased capacity, to go Faster!
For example, I ran into a few leaders of one company at a conference. They came to the conference to learn a little bit more about “Agile”, but they’d already made the decision to adopt it within one of their key divisions.
Not only had they decided to adopt it, but they’d already decided that agile would give them an increase in capacity, so they reduced the development teams in the division by 50%. The thought was—agile will give us a force multiplier of at least 2x our capacity, so we can redirect those resources (people) to other initiatives.
In fact, they were incredibly proud of how “conservative” they were in their plans, thinking that more cuts would soon be possible.
Speechless
If you know me at all, you know that I’m rarely without words. But in this particular case I was literally speechless.
I tried to explain to them that agile wasn’t necessarily a “speed play” and certainly it wouldn’t instantaneously give them a 2x productivity boost. But my words fell on deaf ears as they’d already gone “All In” with this strategy.
I left them feeling a bit sad for them and their teams…
What sort of “play” is Agile?
Ok, Bob, if it isn’t a “speed play”, then what sort of play is agile? I’m glad you asked! I usually coach agile as—
Agile is a “Quality Play” that if you play the game with integrity, commitment, and balance, can become an awesome “Speed Play”. But it’s (speed) isn’t free…
If you don’t play it well, your agile adoption might even be slower than your previous approaches!
So let’s explore some of the ways that agile, if played well, can go fast—
Avoid Rework
It starts with committing to getting your work done within each iteration. That includes meeting all of your Definitions-of-Done on a consistent basis and not letting work “seep” from one sprint to the next.
For example, I would much rather have a team commit and deliver on five fully done User Stories in a Sprint than delivering ten partially done stories—especially if the completed stories deliver the highest value to the customer.
Too many agile teams allow rework – bug repairs, completing test automation, refactoring, or poor designs escape the sprint to later. Even most of the agile tools allow for splitting stories to capture the work that was done in the sprint vs. the deferred work. I think this sends the wrong message to the teams. That skewing work beyond the sprint is acceptable.
Read my lips – it’s not, get everything Done-Done-Done!
Waste Avoidance
From a lean perspective, waste is anything a team does that doesn’t directly deliver value to their customer. For example, gold-plating a feature and delivering more than the customer asked for would be waste. It might be incredibly thoughtful and well designed, but if the customer didn’t ask for it, then don’t do it.
Most consider waste to be mostly tied to software. But it can surface in nearly any deliverable. You can do too much testing, documentation, design, planning, and have too many meetings as well. You can also hand work off to each other and create waste via queuing delays—waterfall thinking is notorious for this.
Read my lips – swarm around your work, limit Work-in-Progress (WIP), and only deliver what the customer asks for.
Requirement Avoidance
Do you really think every product, department, or company needs everything they ask for in their requirements? I think the answer is—No! When I worked at EMC on their Network Attached Storage products we realized that only about 40% of the UI features we developed were used. So, why did we build they other 60% of, dare I say it, waste?
Because we didn’t KNOW exactly what the customer needed, so we were essentially guessing—taking a shotgun approach and hoping that we hit the mark.
Imagine a world where we could have iteratively delivered features to the customer, received their feedback, and “trimmed the tail” for things they really didn’t want or need? Well, there’s a word for that—properly executed agile development.
Read my lips—deliver the highest priority (value) features to your customer every few weeks and show them off. There is the distinct possibility that they will say “Good Enough” before the end of your backlog.
Creativity & Innovation
I’ve saved the best for last, or at least the option with the greatest potential. This is the space where we activate, what James Surowiecki calls the Wisdom of the Crowd. Where we engage the team with the customer and enhance their understanding of the customers’ real challenges and problems
Then, once they have a view, they can explore creative solutions to the problems—and not just by implementing wordy requirements that may or may not do it. It’s this focus on problems and creative / innovative solutions as a team, that holds a promise for teams to truly increase their capacity.
It’s also one of the hardest to balance in real-world agile teams.
Read my lips—never blindly trust the requirements on the backlog. Instead, get intimate with your customers and stakeholders in understanding their problems and challenges. Then deliver innovative solutions that you’ve created as a team.
Wrapping Up
So the next time you hear someone talking about the speed implications of agile and letting their youthful enthusiasm get the best of them, please stop them. Try to explain that it isn’t a “speed play”, but instead amplify that it’s a “quality play that might be able to go fast”.
Then send them a link to this blog post.
We need to nip this wrong thinking in the bud. It’s part of the reason there’s so many bad agile adoptions in the world. The other part of it is looking for a silver bullet and a free ride. Nothing worth having in this world is free. Yet, folks think that agile will solve all of their problems.
It might. But it requires understanding, commitment, balance, and hard work to achieve the promises of agility.
Stay agile my friends,
Bob.