Agile can be a highly effective way to drive up the productivity of software-development teams—especially when enhanced with techniques such as single-tasking and elimination of sprint-level commitments. We also agree that many aspects of Agile can be applied successfully beyond just software-development projects. For example, Agile’s “retrospective” is a beneficial practice that has existed long before Agile, and has often been called a “lessons learned session,” similar to what the U.S. military calls an “after-action review,” or AAR.
As a result, when we offer advice on when not to use Agile, we’re not saying that all Agile techniques must be eliminated from consideration. Rather, we’re saying that the combined set of what we consider Agile’s core elements—including the product backlog, the frequent delivery of incremental software capabilities, and frequent customer interaction to refine scope—can be highly effective in some IT project scenarios, and suboptimal or ineffective in others.¹
Similarly, when we offer advice on when Agile makes sense, we’re not saying that Agile is the only effective way to perform incremental software delivery, or to promote customer transparency and intimacy. We are saying that it can be a great approach, worth serious consideration—especially when enhanced for even greater speed and reliability, as described in our recent book.
Finally, we understand that there may well be a host of additional considerations when deciding which execution methodology is best for a given project. Chief among these could be how well your current staff know Agile and its various complements, and how experienced they are at applying it. As such, this guide is intended to highlight key considerations that are often overlooked, as opposed to serving as a comprehensive manual for all possible considerations.
The decision tree in the figure below lays out our logic for when Agile should be seriously considered, and when it should be removed from consideration. As an additional bonus, we have incorporated logic for when to use Lean Process Value Stream Analyses (VSAs) in our decision tree as well, given that they tend to be most impactful on software projects (both custom-developed and commercial off-the-shelf [COTS] software). (Additional details on how we recommend that Lean Process VSAs be used are laid out in more detail in our book, but we thought it useful to include here; similarly, we reference “Ultimate Scrum” as an enhanced Agile approach that we cover in detail in our book…for the purposes of this article, you can consider Ultimate Scrum as a schedule-buffered, continuous-flow-based approach to Agile, developed originally by co-author Wolfram Müller of www.Speed4Projects.net.)
As shown in the figure, we believe only four questions need be asked—here is our rationale for each:
1) Does the scope include software-enablement of business processes?
We ask this because both Agile and Lean Process VSAs offer significant benefits to software projects. Lean Process VSAs can help shrink the process footprint of both custom-developed and COTS software, significantly tightening scope to drive dramatic speed improvements. Neither Agile nor Process VSAs as we’ve proposed using them in our book will be very helpful on projects that are not software-enabling a business process.
2) Does the scope include significant custom software development?
We ask this because Agile is far more beneficial for custom software development than it is for COTS implementations, while Lean Process VSAs can be very effective for both.
3) Is the scope lacking in specificity, and unlikely to remain stable?
We ask this because Agile is far more applicable for scenarios in which scope requires significant refinement, and is likely to change frequently through the course of the project. Consider, for example, a construction project, for which the blueprints must be highly specified and must remain pretty stable. In software it’s usually pretty straightforward to remove a chunk of code during the course of execution; in contrast, it’s not so simple for a construction project to remove, say, an entire floor that’s already been built. While software projects might typically lack this level of specificity, this is not always the case.
4) Is the customer willing and able to offer flexibility on scope?
We ask this because Agile defaults to scope buffers to help manage project risk—specifically, the part of the product backlog comprised of “nice-to-have” features, as opposed to the “must-have’s.” If things go wrong and you’re only able to deliver on the must-have’s, then the project is still successful, even if only minimally so. If things go well and you’re able to deliver on the entire product backlog, then you will have exceeded customer expectations; but this only works if the customer is willing and able to offer flexibility on scope. If they don’t stipulate any “nice-to-have” features, or are unwilling to pay for them, then the scope flexibility that Agile prefers simply won’t be there.
If all four of these questions can be answered affirmatively, then Agile will likely be your most effective choice of project-level delivery methodology (at least for the software-development tasks). It is important to note, however, that Ultimate Scrum is designed to rely more on schedule buffers, in contrast with most Agile/Scrum approaches, so if using an Agile/Scrum approach that is schedule-buffered, Question #4 will be less relevant. In addition, we should note that, while Lean Process VSAs serve as a highly effective companion to Ultimate Scrum, they can complement any approach for software-enabling business processes.
¹Note that we deliberately omit sprints from this list. While we acknowledge that sprints are regarded as a core element of Agile as commonly practiced, we recommend that the batch-size-reduction benefits of sprints be taken to the limit—all the way to a batch size of 1—achieving what Lean practitioners call “single-piece flow,” effectively eliminating sprints altogether. This is a key characteristic of Ultimate Scrum.
You must log in to post a comment. Log in now.