How can Agile make you Faster?
A reason that enterprises mention why want to use agile for software development is that they want to deliver faster. There are studies that show that agile projects can be faster, like the Columbus Agile Productivity Benchmark Project described in evidence of success of agile projects. How can agile be used to become faster?
In the blog post who says agile development can't be faster?, Matthew Heusser shared a discussion that he had at the agile testing days conference:
At Agile Testing Days in Potsdam, Germany, in November 2012, Lisa Crispin and Janet Gregory, authors of Agile Testing: A Practical Guide , made the bold claim that "agile means faster" is a myth.
Later in the conference, Janet Gregory explained to Matthew Heusser what she meant with this:
The point of agile is not speed, she says. It might be a by-product, but it won't happen right this second. (…) An agile conversion slows you down, at least in the short term-and that short term is not a week or two. It may be a year or two.
Matthew provides several arguments why he considers agile to be faster. He explains how building the right things and skipping requirements that are not worth doing saves time. Another reason to use agile is that “The Old Way Isn't Fast, Either”:
(…) comparing an agile team that can't get something done in a year to a more traditional team that can is a false comparison. In a year, the traditional team will have 12-and-a-half requirements done, a mess on the floor and nothing to ship.
He concludes his blog post by explaining why he disagrees, and explains how he thinks that agile can help teams to become faster:
One question remains: Is it faster? Crispin and Gregory might argue that it does not matter, that focusing on pure speed in the short term leads to shortcuts, pain and slow performance in the long term. I contend that teams can focus on eliminating waste and improve velocity as they improve process.
In making agile go fast, Chris Turner reflects on reasons why agile project can go slow. He describes four reasons that he often sees, and gives some suggestions how to handle them:
- The wrong people: Remove people from the team who aren’t following good engineering discipline or are making things more complex.
- Putting the process first: Establish open communication and self organising and empowered teams.
- Using the wrong technologies: give teams authority to make technology decisions, and allow technology choices to be reversed if they hinder delivery.
- Making the architecture too complex: Keep your software as simple as possible, refactor.
Neil Killick describes in his blog post sustainable pace – the Fastest way to deliver software how asking an agile team to speed up can slow down software development. He tells a story about an agile team that is capable of delivering on average 10 stories in every 2-week Sprint, where the number of stories to be delivered is increased:
Now imagine we asked the team to take on just ONE story every Sprint. (…) Well, we can’t be sure but it is fairly safe to assume that the 1 story is guaranteed to be delivered. We can also be pretty sure that it will be of an extremely high quality
(…) we ask the team to deliver 2 stories per Sprint. While it’s highly likely that the team will surely deliver the 2 stories, the probability is slightly less than when we asked them to deliver 1 story. So we have a little less predictability.
Now imagine we’re struggling to hit a contractual deadline so we feel the need to “speed up”. So we ask the team that predictably delivers 10 stories to deliver 12 (now we’re over capacity). Or even 14? (…) the “faster” we ask (or worse, tell) our teams to go, the less predictable at delivering software we become, and that software is more likely to be of a lower quality.
He advices to allow teams to work at a sustainable pace:
(…) by allowing the team to find the right balance and deliver high quality software at their capacity, a cycle of success is created.
No process is good enough
Re: No process is good enough
focusing on pure speed in the short term leads to shortcuts
What do you mean by "shortcuts" here?
Re: focusing on pure speed in the short term leads to shortcuts