I have previously considered Scrum applicability by project characteristics, identifying key project attributes that enable successful use of Scrum and others that recommend against it. Those conclusions were supported by identifying trends in publications about successful Agile and Scrum projects, noting the types and characteristics of projects used to illustrate those successes. There are additional features describing both appropriate and less appropriate projects for Scrum, again taken from characteristics of projects in published accounts.
Low complexity requirements
Although not explicitly stated as an assumption, typical projects in the literature describing successful use of Scrum have relatively low complexity requirements. This assumption is marked by assuming that requirements can be discovered or derived very quickly (keeping pace with development) and with low effort. In those projects, this avoids a prolonged analysis and discovery period where no code is written that would be needed for more complex requirements OR significant delays during coding while requirements are fully developed. Another form of this assumption is seen where desired or similar functionality is visible in the marketplace by competing companies and is used as shorthand for the requirement likewise avoiding in-depth analysis. This approach to simplifying the Scrum process is found in the more theoretical literature as well. A common approach to illustrating the use of Scrum techniques includes describing projects recreating features of established software products or other simple functionality (e.g., a news web site with advertising in Becoming Agile in an Imperfect World by Smith & Sidky, and in Agile Software Development with Scrum by Schwaber & Beedle). In this way, neither theoretical analyses nor discussions of specific projects fully describe Scrum methods for achieving complex requirements.
Low organizational impact
Another implicit assumption in Scrum is that releases have low organizational impact. This assumption is indicated by the stated principle of making frequent releases: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Following from this assumption is the further supposition that cost to the business of making the process changes associated with those releases is relatively small compared to the expected value. Software and process changes requiring significant change management for user education or retraining, role redefinition, organizational changes, stakeholder communication, etc. may be too expensive to justify making those software changes often, as the principle would suggest.
Some industries can adopt a “Build it and they will come” attitude with their software products. When was the last time your favorite social media site asked you what new features you wanted or if you’d rather that they just left things alone? Never, right? And yet they continue to change their products in Agile fashion, looking for more, new ways to capitalize on your use of the system. I have heard of entire business models being broken by changes to features in online public platforms. Ok, for them perhaps, but can you do the same with your in-house business systems? When the answer is ‘no’ then clearly the Agile principle needs to be challenged.
Infrastructure projects
Many Agile and Scrum texts assume that all development infrastructure and platforms are in place prior to the start of the project. Underlying this simplifying assumption would appear to be an admission that Agile methods are not suitable for infrastructure projects. As an example of this conclusion, or perhaps as a metaphor for it, I offer the following scenario.
Imagine yourself in New York City in the early 1850’s and that the goal of your project is to make travel easier between Manhattan and Brooklyn across the East River. An Agilist might look at the current approach of using ferries and by looking to prioritize rapid progress might suggest purchasing or building many more ferries or scheduling more passages across the river. Over the coming years when ferry capacity was exhausted, the Agilist might simply build yet more ferries or attempt to make them bigger or faster. At no point does the Agile approach solve the problems associated with inclement weather or the growing ferry gridlock or how to get trains across the river. At no point would an Agilist consider a 17-year project to construct the Brooklyn Bridge. And yet the visionary solution was to invest those 17 years, gaining no incremental functionality throughout the construction, until delivery of the final capability as a single event – the very opposite of an Agile approach.
Expensive failures and rework
Some Agilists promote the idea of “failing fast” as a means of discovering what won’t work and believing that will guide teams to more workable solutions. This approach enables a bias toward coding first rather than spending time in analysis and assumes that coding iterations will more quickly arrive at a solution that wasn’t imagined or understood at the outset. This approach must assume that that the cost of failure is low, and that rework is cheap. Rework might be relatively cheap in a software product where the only sunk cost is labor (although software developers command premium salaries in the current market). And the cost of failure might be low if the functionality offered is relatively simple or noncritical as in online entertainment or social media.
However, in products where cost of failure and/or rework is expensive, for example where materials are expensive and not reusable, where user safety is at risk, or where impact of failure is large (e.g., semi-conductor design, military, space travel, healthcare), the idea of iterating approximate solutions/failures has considerably less appeal or justification. Who wants to fly in an airplane (even as a tester) where any of the controlling software was built by Agile techniques (“Oops, we forgot to account for this rare windshear event!”)? In those domains projects reasonably choose extensive analysis, design, simulation, and prototype testing prior to coding to mitigate the chances and costs of failure.
In the prior post I concluded that, following from the expectations of pragmatic project management, PMs should evaluate the use of Scrum per project, leveraging those elements that best fit the needs, omitting those that do not, and using included elements during the phases in the project lifecycle where they provide the most effectiveness and value. Based on the types of projects considered in this post, PMs should as well consider whether Scrum is a fit at all for the project or if the risks of the approach outweigh the benefits.
