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.
Community comments
No process is good enough
by arock durai,
Re: No process is good enough
by Ben Linders,
focusing on pure speed in the short term leads to shortcuts
by 雷 慈祥,
Re: focusing on pure speed in the short term leads to shortcuts
by Ben Linders,
No process is good enough
by arock durai,
Your message is awaiting moderation. Thank you for participating in the discussion.
The reason why projects fail, is because all software processes depend on the assumption, that the exact requirements of the customer is well known. The Agile guys may argue it is not so, that is why sprints are done. Still it doesn't work. Because if the requirement gap is detected after couple of sprints, then again we are in deep trouble. More than processes, developers should be given access to good tools( such as profilers, code generators).
Re: No process is good enough
by Ben Linders,
Your message is awaiting moderation. Thank you for participating in the discussion.
I agree partly with you Arock. Following an agile process helps you to find out earlier how good your requirements are, which in itself doesn't solve the "requirements gap" that you mention. What I have seen is that agile retrospectives can help you to investigate this gap, looking at the collaboration and communication between the team members and the product owner. Already in a next sprint you can change the way of working, to decrease the gap. It needs some investment, but many teams that I have worked with usually reap the benefits already after just 1 or 2 sprints.
focusing on pure speed in the short term leads to shortcuts
by 雷 慈祥,
Your message is awaiting moderation. Thank you for participating in the discussion.
hi Ben,
What do you mean by "shortcuts" here?
Re: focusing on pure speed in the short term leads to shortcuts
by Ben Linders,
Your message is awaiting moderation. Thank you for participating in the discussion.
The word "shortcuts" is used by Matthew Heusser in his article "who says agile development can't be faster?", so I can only assume what he means with it. I've seen it used when steps in a process (the way people work, their Definition of Done) are skipped. In the short term, a team can deliver earlier, but due to technical debt is usually means that more work need to be done in the future. Going fast initially will slow you down.