Does Agile "Speed up" Project Work?
Teams moving to Agile commonly ask me if it will “speed up” their project over Waterfall. I find that teams making the move to Agile do find an improvement in efficiency, but it's not as clear cut as that. Since I’m asked quite often, I thought I’d share my response for all.
Agile does help make a team more efficient through various points: 1) Agile helps defer work on unimportant or low-priority features or functionality. Agile provides many instances to course correct and reprioritize work versus a typical waterfall plan. This means that the team doesn't waste cycles, preventing wasted effort from the team. 2) Agile processes give far more transparency as to the team's progress for a given release date. At the end of every sprint, you know the progress made towards the goal. This transparency and meeting deadlines prevents budget overruns and resource lockup, which appears as "faster," as those problems occur frequently with Waterfall projects. An important reminder here, since Agile embraces changing priorities, the plan (backlog) you start with in Agile may not be what you finish with. I call this out because if teams end up deferring work to a later release, it is not fair to say they missed their goal, because the goal moved on them! 3) Agile helps focus work on the Minimum Viable Product (MVP). Agile says to do just what is asked, and no more. Once you clear MVP, you can add on the "nice to haves." Akin to prioritization, this saves time by cutting through the noise, and only delivering precisely what is asked, which reduces wasted effort. And a final point, Agile encourages teams to embrace automation, which can reduce defects, and in turn reduce rework. That said, automation is not exclusive to Agile, so I personally cannot attribute those efficiencies to Agile.
If Agile does all of this, does that mean it “speeds up” a project? It is a somewhat philosophical point, but I argue, no. When comparing apples to apples, Agile does not speed up the work itself. As an example, Agile does not allow you to take a 4-month project in Waterfall, and compress arbitrarily to one month. If a software project needs 100 lines of code to develop critical functionality, it will need the same code in both Waterfall and Agile projects. The work itself is equivalent, assuming both project teams use automation for build, test, and deployment. This, to me, means Agile does not "speed up" the project.
Accordingly, you must be careful when measuring efficiencies in Waterfall vs. Agile. Agile allows for frequent re-prioritization, transparency, and focus, which in turn makes teams more efficient. As I noted, take caution in saying that Agile “speeds up” a team though. Do not make the common mistake of thinking it does, and that the team can adjust as the customer demands. Yes, Agile makes you much more efficient, and there’s a logic and a limit to said efficiency. Understand those limits before committing dates to customers!
Agile author, trainer, coach, Digital Transformation, DevOps
7 年Good thoughts! We've had the discussion on whether Agile is faster and cheaper and found that to be a myth. I like your point about 100 lines of code taking the same time whether Agile or not.
I would agree that Agile is certainly more focused and in many ways more efficient
Senior Development Director - Post Trade Services
7 年Going through the process of converting from waterfall to agile right now, one of the selling points we were given was that Agile will speed up the process. I would tend to agree with your statements above that the Agile process will not speed up the process but will introduce efficiency, reduce defects, and focus on the true priorities.
Senior Director Program Management Office @ SimCorp | Strategy | Transformation | Leader | CTO
7 年Great article and arguments for why Agile improves the outcomes! Building the right thing and building it right. Remove not needed features and defer less important stuff for later in favour of getting more valuable things right now. I think I can help make your case for agile even stronger, though. I would argue that not only the ability to achieve better outcomes is improved, but also the speed and efficiency. This is achieved by the inherent principles in agile that reduce batch size, lower the work in progress, introduces a pull mechanism, builds in continuous improvement, mandate stable high performance teams, favouring optimization for speed before resource optimization, requirements structure that enables flow, and more. It normally does not reduce the time it takes to write the 100 lines of code, but it reduces a lot of waste around that work. Finding this waste and removing it it much easier in an agile process. I agree to not committing to any dates that you do not have empirical productivity numbers showing that it would be possible. Don't take any future assumed speed improvements into account when planning. Especially not if we are talking short term.