Agile Through a Matrix Lens

“Agile” is something most teams do wrong*, without realizing they’re doing it wrong. A good 2×2 matrix acts as a lens, helping to convert information into insight. Let’s apply this lens to agile as applied within a company, and see if it helps people decide to do things differently.

When You Say Agile, What Do You Mean?

There may be as many definitions of agile as there are teams practicing agile development. Generally, people are talking about iterating in what they do. Instead of having a long, throw it over the wall process, out of which emerges a deliverable; a team will have a series of shorter iterations where they engage stakeholders and otherwise rethink what they are doing to course-correct and “get smarter” about what they are doing. The Wikipedia page on agile is pretty comprehensive.

Most teams think about agility in terms of how their development teams manage their process. When “going agile” is the only thing you do, your product does not magically become more successful. Some teams** think about what it means to be agile when determining what the development team should be doing in the first place. My epiphany was in realizing that these are two separate decisions an organization can make.

A 2×2 Matrix of Agile

When an organization can make two discrete decisions about being agile in how they create products, it results in four possible outcomes. A 2×2 matrix can act as a powerful lens for exploring these decisions. Our first step is to define our two axes.

Requirements – how are they treated within the organization / by the team?

• Requirements and expectations are immutable – this is the typical expectation within a large bureaucracy; someone built a business case, got funding, and allocated a team to deliver the product as-defined.
• Requirements continually revisited – this is what we see nimble teams doing – at different levels of granularity, context, and relevance; at a low level, this is A|B testing and at a high level this is a pivot.

Development process cadence – how frequently does the team deliver***?

• Infrequent delivery – there is no one size fits all measure to define infrequent vs. frequent; some companies will have fast-moving competitors, customers with rapidly evolving expectations, and significant influence from evolving technology – others will not (for now).
• Frequent delivery – the precise delineation from infrequent to frequent delivery is contextually dependent.

With these two axes, we can draw a matrix.

A subordinate message that I couldn’t resist putting into the matrix is that it is harder to do your job in an agile way. I think you could pedantically argue that agile is easier – by saying it is easier to deliver the equivalent results when your process is agile. And that’s true. The point is to deliver a more successful product, which is harder than delivering a less successful product. An agile approach makes that task easier. Maybe another way to think about it – [tweetherder]if your team is not capable of delivering a good product, going agile will make that more obvious, faster[/tweetherder].

Living in Boxes

Everyone can map their team into one of the four boxes. That’s the power of this sort of abstraction.

Here’s where I can use your help: What are better names for these boxes? I have satisficed with these names, but they could be better. Please comment below with proposed alternatives, because I’ll be incorporating this lens into other aspects of my work, and I want it to be better than it currently is.

Waterfall as Practiced

While there are some teams which consciously choose agile because of the planning benefits or perceived risks to quality, I believe that most waterfall teams are still waterfall either because they haven’t chosen to revisit their process choices, or they tried and failed. Perhaps their instructors weren’t good, perhaps the team was not equipped to make the shift. My guess is that their organizations were unwilling or unable to support any change in the bureaucratic status quo, effectively making it impossible for the teams to succeed.

BUFD & BUFR (Buffed and Buffer)

BUFR is an acronym for big up-front requirements, and BUFD is the equivalent for big up-front design. Both of them are labels assigned as part of the decade-old war between interaction design and extreme programming. Conceptually, the battle is between rationalists and empiricists. In a nutshell, the requirements are Defined (capital Defined), then the team applies an agile development methodology (mostly) to incrementally build the product according to the requirements.

This is another area where can explore more – what are requirements, what is design, who owns what? My main point is that the developers, while going through the agile motions – even when getting feedback – are only realizing some of the benefits of agile. Yes, they can improve the effectiveness of their particular design or implementation at solving the intended problem. Yes, they can avoid the death-march.

The problem is that the requirements are set in stone metaphorically.

At the end of the day, the team is empowered to rapidly iterate on, and change how they choose to solve the target (market) problems. The team is not empowered to rapidly change their minds about which market problems to target.

When agile is being introduced to a larger organization, as a grass-roots initiative starting with a development team, this is corner the team will find themselves in.

Req’s Churn or Glacial Dev

I struggle for the right way to describe the situation where the people responsible for determining the requirements are getting market feedback and changing their requirements, which the people responsible for creating the product are unwilling or unable to accept changes from the initial plan.

From the development team’s point of view, “the product manager can’t make up his mind – we are just churning, without getting anything done!”

From the product manager’s point of view, “the development team is too slow, or intransigent, and can’t seem to keep up.”

There’s only one environment where this approach is somewhat rational – outsourced development with limited trust. When the relationship between the product management / design team, and the product creation / test team is defined by the contract, or the two teams do not trust each other, the only reasonable way to make things work is to establish explicit expectations up front, and then deliver to those specifications. Note that the specifications typically include a change-management process, which facilitates reaching an agreement to change the plan. The right way to make this type of relationship work is to change it, but if you’re stuck with it – this is your box.

Agile as Intended

Ah, the magic fourth box. Where rapid delivery leads to rapid learning which leads to rapid changes in the plan. The success of agile is predicated on the assumption that as we get feedback from the market, we get smarter; as we get smarter, we make better choices about what to do next.

This is what enables a sustainable competitive advantage, by enabling you to sustainably differentiate your product from competition, rapidly adapt to changing customer expectations and market conditions. Effectively, you are empowered to change what you choose to do, as well as how you choose to do it. This is what agile product management is about – enabling business agility.

A winning strategy involves selecting an attractive market, developing a strategy for how you will compete within that market, then developing a product (or portfolio) roadmap which manifests the strategy, while embodying the vision of the company. It is possible to do this in any corner of the matrix (except the upper left, in my opinion). The less willing you are to rely on your ability to predict the future accurately, the more you will want to be in the upper right corner.

Conclusion

There isn’t a particularly strong argument against operating your team in the upper right hand corner of the box, Agile as Intended. The best argument is really just “we aren’t there yet.” From conversations I’ve had with many team leaders, they seemed to think that getting to the lower right corner was the right definition of “done.” They thought they were “doing agile” and that there wasn’t anything left to change, organizationally. And they wondered why their teams weren’t delivering on the promise of agile. It’s because they weren’t there yet.

Hopefully this visual will help drive the conversation forward for some of you out there. Let me know if it helps light bulbs go off.

Attributions and Clarifications

Special thanks to Prabhakar Gopalan, who introduced me to The Power of the 2×2 Matrix, a really good book for framing ideas, in his craftsman product management training class.

*Agile isn’t a noun really something you do, agile is an adverb describing how you do something. English is a funny language, and “doing agile” is generally used to reflect developing a product in an agile manner. Sometimes it is important to point this out – particularly when you’re trying to help people focus on the product and not the process (like here), but for this article, I didn’t want to dilute the other messages. As a bonus, the people who would be tweaked by the use of agile as a noun are generally people who “get it” and I like the idea that they read the whole article, just to see this caveat. Thanks for reading this :).

**This is based on anecdata (thanks Prabhakar for the great word), but my impression is that small companies commonly do this – think Lean Start Up – and large companies rarely do this. I suspect this is more about the challenge of managing expectations and otherwise navigating a bureaucracy built to reward execution against a predetermined plan.

***Definitions of “deliver” make for a great devil is in the details discussion too – do you deliver to end-customers or internal stakeholders? What if your existing customers refuse to update every month? How many versions of your product do you want in the field? Another great topic – but not the focus of this article?