Picking Agile vs. Waterfall “Projects”: a Ten Point Quiz.

For some reason, I woke up today realizing that I have been working with, and writing exclusively about, enterprise scale software agility full time now for five years running. I’ve had the fantastic opportunity to work with some of the world’s largest enterprises, each adopting agile at scale. Some of these initiatives were extremely successful, some quite successful, and a few, less successful than we had hoped. (We’ll return to that latter topic later in this post.) I also woke up with a “bee in my bonnet” (pick your own, more contemporary idiom here….) about a topic that has come up repeatedly in the last few weeks.

The topic is this:

As agile moves across the chasm from the innovators and early adopters to the early majority,

(flow interrupting Note 1: if you haven’t already read the important, and now classical, text, Crossing the Chasm, by Geoffrey Moore, you might want to stop reading this blog post right now, download this book, and then come back after you have read it. I’d guess that your world view on technology adoption will be substantially altered thereafter. Mine certainly was and still is.)

enterprises that are adopting agile, especially larger scale IT enterprises, look at their “portfolio of upcoming projects” and then have to decide which projects they want to implement using their new-found agile instincts, vs. their traditional waterfall mandates.

(flow interrupting Note 2: As readers of Agile Software Requirements are likely to know, I’ve become quite uncomfortable with the “project” word and practice in agile development; maybe I’ll fire that post off in another day or so).

In some cases, I’m even peripherally involved in picking the best projects for agile implementation. Sometimes, I’m even asked for a discriminator as to which projects best lend themselves to agile development. But as I told an enterprise the other day, though, perhaps they are talking to the wrong guy, because for the life of me, I can’t seem to find any excuse any longer to not apply agile development to any project anyone actually cares about! (See, for example, https://scalingsoftwareagility.wordpress.com/category/high-assurance-and-regulated-environments/).

So I woke up today thinking about a 10-point True False test that one could use to make these “tough” decisions. Here it is:

Question T or F
1 The project requirements are fully determinable in advance of development
2 And if (1) is True, they are likely to remain completely static during the course of the development effort.
3 If (1) and (2) are True, they will remain static even if takes our teams teams longer (30-50-75%) than estimated to complete the project
5 There is no significant technological risk whatever in the project.
6 The users/customer are unable or unwilling to evaluate early delivery of solution increments. Early deliveries have no value to them.
7 There is no value to our enterprise in helping teams figure out how to “build small increments of working, tested high quality software in a time box”.
8 There is no value to our teams or productivity in collocating product ownership (content authority) developers and testers for this project.
9 There is no value in helping our teams learn better software engineering practices driven by agile, including such things as collective ownership/peer review/pair programming, emergent design, continuous integration, single code line, test-driven development and test automation.
10 Our organization is addicted to the adrenalin rush and heroic efforts required by late project risk discovery.

You know where this is going …. if you answered False to ANY of the above questions 1-9, or True to Question 10,  then your project is ready for agile. (And if perchance you didn’t answer False to any of 1-9, ask yourself “is this project really worth doing?).

There, I have that off my chest.

OK, now back to the discussion of “less successful” projects. Yup, I suspect we all have them, and perhaps it would be a sign of industry maturity if we could more readily admit them (see my friend Philippe Kruchten’s report “The Elephant in the Room”) from the 10th year Agile celebration in Snowbird, UT on February 11th and 12th; also see Ryan Marten’s post on the event here).

But as I look at the (perhaps obviously biased) test above, I ask myself the question “In these less-than-hoped-for successes, would the enterprise, the program  and the teams have been better off than if they hadn’t adopted agile?” Based on my direct knowledge in these few cases, and an opinion that I  know is shared by my cohorts and agile champions in those same programs, the answer is “Hell, no.” Moreover, they can always inspect and adapt from there!

Be agile. After all, don’t you and your enterprise deserve the benefits?

3 thoughts on “Picking Agile vs. Waterfall “Projects”: a Ten Point Quiz.

  1. One thing that continues to amaze me is this black-and-white thinking ‘your project is either agile or it is waterfall’. During the last 15 years I haven’t seen a single project follow a pure waterfall lifecycle. In reality, there are many different shades of grey.

    In other words, I don’t think projects should choose between ‘agile’ and ‘waterfall’. Rather, it’s a question of tailoring the project approach to fit the context, constraints and environment.

  2. I agree with the first response, this article is far too black and white. But that is the nature of a checklist, not a comparison matrix. What do I do if my project doesn’t fall neatly into yes/no gates on these questions?
    When it takes 10 sprints to make a releasable piece of complete software that cannot be truly tested or evaluated until it all comes together, does that mean the iterative nature of agile development was unnecessary? Is there really a simple waterfall vs agile decision to be made here? And what should I do when only ‘some’ of the software requirements cannot be handled in a standard agile process due to external dependencies, legacy system integrations, or clear expectations of final results? When you look at a backlog for a complex enterprise project, it is generally fairly easy to define the stories that require advanced planning and design before you start cutting code. It has also been my experience that the greenfield stories can continue in a standard agile manner, while a more waterfall (know first) approach is taken on other stories.
    Would be interesting to see the checklist as items on a continuum, maybe something like (I will target checklist point 1)
    – Get going (pure agile) if: General requirements are known and there is flexibility in how they can be implemented
    – Plan first (iterative design-build, DSDM?) if: Requirements are still fuzzy or there is significant complexity (i.e. legacy systems) or high levels of external dependency that have not been resolved.
    – Waterfall (full design / build): The solution must meet an exact spec (i.e. PCI compliant banking software)

    It has been my experience that large projects can contain all three aspects of the above, making the checklist the wrong type of medium for decision making.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s