Choose the Right Way of Working

And it may not be an Agile one.

Many companies try to be Agile. Many others use Agile ideas without calling them that. Few of those companies, however, question Agile’s fit to their situation, or begin products/projects with the question, “Which approach should we use here?”

For the longest time, nobody had to ask this question, because there was a standard way to manage work: a plan-driven, predictive approach such as Waterfall or PRINCE2. The process was well-documented, ubiquitous, and assumed to be right. Agile has emerged as a viable, acceptable alternative. And now, too many people are inappropriately trying to force-fit their work into Agile frameworks.

Let’s look at these two very different approaches. Many people think of Agile and Waterfall in terms of right and wrong, new and old. However, the real question is that of suitability.

When we work, we rely on principles that guide our choices, decisions, and actions. If we apply Waterfall practices — such as requirements analysis, Gantt charts, code freeze, and user acceptance testing — it’s because we’ve chosen to operate according to certain principles. Some of the Waterfall principles are:

Plan the work and work the plan
Limit change
Sign-off
People are resources
Maximize worker utilization
Hub and spokes

On the other hand, if we apply Agile practices — such as daily standups, acceptance-test driven development, and sprint demos — it’s because we’ve decided to operate by the Agile principles, by which these practices were designed. Some of the Agile principles are:

Team self-organization
Collaboration
Sustainable pace
Feedback
Continuous improvement

To be clear, more work principles exist beyond the Waterfall and Agile ones. There’s Limit work in progress (WIP), Eliminate waste, Don’t repeat yourself, and so on.

Principles are not the full story

Why do we pick some principles over others? We do so because of what’s important to us: our values. We might not make our values explicit, we might not share the same values, and they might not be appropriate for our work — but they’re still there, and they influence everything.

For instance, in millions of IT projects the important things are usually these:

Make early commitments (= promise what will be done by when and for how much)
Get it right the first time (= there’s really only one go-live)
Deliver on time and on budget (= that’s what success means and requires)
Use standardized processes (= they should yield success as long as the workers are skilled)

When these are your values, the Waterfall principles are the sensible way to approach work. You would want to make a plan and follow it closely, and use proven practices for managing the work and the workers.

In a different situation, other things might be more important to you: putting people first, adaptation, delivering value early and frequently, and continuous collaboration with your customer. If these are paramount for you, the “inspect and adapt”, empowered team, and take-small-steps elements of the Agile approach follow naturally.

Choose your methods deliberately — every time

Always managing your work the same way cannot be a winning strategy, because what you care about changes with the work. For example, if you’re an agency rebuilding my city’s website, I hope you’d collaborate with city staff and with citizens to discover changing needs and expectations, adapt the site accordingly, and release it gradually as more services are added. On the other hand, if the City decides to replace a decrepit highway with a tunnel (Toronto, I’m looking at you), I hope they get it right the first time, use taxpayer money wisely, and follow standard design and construction practices.

What if, instead, the city decided to use agile practices for the highway project? Would short sprints, user stories, product backlogs, and daily standups make a useful difference? I think not. When long-term predictability and promises matter, sprints add to planning overhead, user stories are carved-out specs, the product backlog is a weak representation of a project plan, and the daily standup is merely a daily status meeting. They do not increase agility — and indeed, increased agility is not needed here.

It’s thus important to choose methods designed to accomplish what’s valued. Some methods have been prepackaged for you, such as Waterfall, Scrum, and SAFe. But what if you have a hybrid – in other words, what you care about is neither entirely Agile nor Waterfall? Examples of that abound, for instance in contract software development, legacy modernization, and HR policy development. In those cases, no prepackaged set of methods can be a perfect fit, and you’d have to roll your own. (Facilitating the workshops in which staff and management do their own process and team design happens to be one of my favourite activities.)

Sometimes, the right methods still fail to yield the results you’re after, and as the situation unfolds, your values start changing. A common example is Waterfall “project rescue”: when a project runs into schedule and quality trouble late in the game, rescue efforts marshal everyone around to finish at least a few useful, working pieces. The values that dominated during inception — predict, commit, economize — are still important, but other ones — be flexible, satisfy the customer, don’t look bad — eclipse them, and give rise to practices reminiscent of Agile ones. Retrospectives (or post-mortems) of such projects may yield a recommendation to project leaders to be more critical of their values and assumptions on the next project.

Beware the one-size-fits-all approach. In a given work situation, before you ever plan, commit, design, implement, improve, or otherwise do any work, be explicit and deliberate about your values, principles, and assumptions in order to increase your effectiveness.