Twelve

This article expresses, in written form, the talk that Chet Hendrickson and I gave at the deliver:Agile conference.

Al Smith once said “The cure for the ills of democracy is more democracy”.

We say The cure for the ills of “Agile” is more Agile.

Kent Beck has said that when he formulated Extreme Programming, he took the good practices he knew and turned the dials up to 11.

Here, twenty years later, let’s look at what happens if we turn the dials up to 12.

We’ll begin by considering some of the issues, concerns, and ills of Agile today, and look at how we might cure them by turning the dials up to 12.

Specialized Roles

Agile approaches today include various specialized roles, such as “Product Owner” (or the XP “Customer”), or “ScrumMaster” or “Coach”. And often, teams on the ground include other specialties, such as testers or architects or designers.

Scrum, a popular would-be Agile approach, says that the Scrum Team should include “all skills necessary to produce the Product Increment”. This is an excellent idea, but one that is often not used in practice. And even if it is, it doesn’t go far enough.

In particular, Scrum and XP both have one special role, the Scrum Product Owner or XP Customer, whose unique responsibility is to decide what to do, and when to do it. Scrum’s founder has gone so far as to describe the Product Owner as the “single wringable neck” on the team, declaring the Product Owner to be responsible for maximizing the return on the investment in the team.

A common result of this authority-based role separation, and in our view, all role separations, is that the team is held back from self-organizing, and from using their best ability to produce a creative solution to the business needs.

Whether the specialist is “inside” the team or outside, self organization is hampered by the extra lines of assumed authority:

If we turn the dials of self-organization all the way to 12, we would eliminate specialized roles, while of course still requiring all the skills and abilities needed to build the product. We call for a Complete Team, with as much skill-sharing, and as much self-organization as possible:

With dials at 12, we have a

Complete Team: A self-organizing diverse community working together in close proximity, including all necessary capabilities and skills

Backlog

Another concerning aspect of today’s typical Agile approaches is the notion of the Backlog (or, in XP, the Release Plan). There is a natural desire to have insight into what the future holds, but when this desire results in a list of “things to do”, we lose the very flexibility that is one of the fundamental gifts that Agile Software Development brings us.

The basic notion of the backlog seems to make sense. We look at the big picture of what we’re trying to build, and we figure out all the things we plan to get done by the deadline:

Unfortunately, that trick rarely works, because we aren’t good at seeing everything we’ll want in advance, and we aren’t good at figuring out how long it will take to build something we do not yet understand. The result, all too often, is that we try to stick with an impossible plan, missing the deadline and producing inferior product at the same time:

With dials at 12, we replace the notion of a backlog with an example-based plan. Each proposed aspect of our product, large or small, is described with one, or many, specific examples. In a software product, we expect these examples to be expressed as automated “checks”.

A large, as yet unspecified product capability might be expressed with one check, such as

Sales tax on one Chai Latte in Michigan is 18 cents
Speed display color in a 70 mph zone turns red at 71 mph

These checks stand in for the larger idea of “calculate sales tax for all purchases” or “display speed in red above the speed limit”. And, since those features are not yet implemented, the checks will fail.

As we refine what we plan to do, we create more and more examples, more and more specific, describing what the product needs to do.

As all the examples are implemented and run correctly, the product picture is visibly filled in. Everyone can see, at all times, exactly where we are. Seeing where we are, we can make good decisions about what to do next.

With dials at 12, we use

Example-Based Transparency: to give the team, and all stakeholders full visibility into the outcomes of the team’s work using a consistent set of real working examples.

Estimation

Then there’s estimation, in particular estimating how long each of the things we plan to do will take. Now, we certainly agree that in order to undertake building a product, or continuing the effort, we need to provide some sense of how things are going, and how long it’s going to take. It’s just that estimating each feature is often not the ideal way to proceed.

Our concerns include:

Contract Negotiation

Estimation too often turns into a kind of “contract negotiation”. When the team’s estimates are “too large” (how could that even happen), the powers that be often influence them downward. This can happen subtly or quite blatantly. Either way, the result is poor estimates.

Worse yet, an estimate that has been compressed by pressure will not likely be met, and if it is met, it will be done by reducing quality. Unless quality is unimportant, pushing back on estimates is not a good idea.

Focus on Cost

The point of building the product, one assumes, is to provide value. Estimating features results in a focus on cost. This is exactly not the way to run an Agile project, which should constantly be doing the next most important thing, not the cheapest thing.

You’ll encounter “Agile” gurus who tout sorting on both cost and value, since clearly if you have two things you could do that are of equal value, you should do the cheaper one first. While this is technically true, we don’t care. We find that the focus on cost is so pernicious that we would prefer, where possible, to avoid the issue by avoiding the estimates.

No Good Way

There’s basically no good way of estimating things we’ve never done, and haven’t even fully specified. The ideas are too fuzzy to provide for meaningful estimates.

A much more sensible thing to do is to slice off a small but valuable part of a larger feature, and do it in a very short amount of time. Rinse, repeat.

With dials at 12, we have a continuously-available, continuously improving Working Software Product.

With the product available for all the stakeholders to view, inspect, test, and use, we change the conversation from “what might this cost” to “what shall we do next?”. And, much sooner than a pre-planned product might provide, we can discuss “who could use this now”, or to “what one thing could we add to make it so?”

With dials at 12, we focus on a

Valuable Working Software Product: consisting of a continuous, sustainable, ideally accelerating delivery of an ever-improving product

Sprints and Iterations

Another area of interest in today’s “Agile” is the notion of “Sprints” or “Iterations”. In contrast to the topics above, Sprints or Iterations aren’t quite so frequently bad. We consider them optional, and they are certainly not optimal when you get your dials to 12.

Enabling Constraint

There are two fundamental reasons for the use of the Sprint or Iteration. First, it helps to ensure that there will be an inspectable product for stakeholders to view, to satisfy their concerns and to provide direction. Our “Working Software Product” clause serves that need.

The second reason is our concern here. Sprints or Iterations can serve as an “enabling constraint”. Often when we constrain our options, and do so wisely, we learn more rapidly. In the case of Sprints and Iterations, we have to learn to build working product in some short interval of a week or so. We have to learn to take our large fuzzy ideas and refine them to fit into small, short intervals.

And this is a good constraint, and often teams actually do learn this. Sometimes, unfortunately, they do not.

Our usual approach when a team can’t get a version of working product in a week is to require them to do it in a day. Yes! We don’t relax the constraint, we tighten it. We keep the team feeling safe, but very challenged.

Soon someone will say, “Well, if we just did one tiny thing …” and they’re on their way. And they are: the secret to short-cycle creation of working product is to do very small things in very short cycles.

The dark side of Sprints and Iterations is often pressure.

Arguably, a little deadline pressure is a good thing, helping us focus on completion. And that’s a thing we like about Sprints and Iterations.

But too much pressure is bad. It invites people to take shortcuts to deliver more than they realistically can, resulting in poorly-designed software, with far more defects than there should be. (We’re pretty sure that no one wants defects, so the number there should be is zero. While we rarely get to zero, no one really wants even one.)

In Twelve, we want to see continuous delivery of our product, valuable working software:

Valuable Working Software Product: consisting of a continuous, sustainable, ideally accelerating delivery of an ever-improving product.

Rituals, Events, Ceremonies

As we think about setting our dials to 12, we recognize many cyclical intervals in our product development effort:

The red/green cycle of our next test;
Working sessions of a few minutes or a few hours;
The working day;
The working week;
The monthly stakeholders’ meeting;
The quarterly review;
The annual company retreat;

Whatever the team’s intervals, and the company’s intervals may be, with dials at 12 we treat them all the same way:

Entry Bracket [: We determine a concrete prospective example of what we plan to accomplish in the interval;

Build: We do our work during the interval, building the desired product, working to accomplish what we set out to do;

Exit Bracket ]: We assess our performance in the light of the passed interval, and use our actual results in retrospect, to prepare us for the next entry bracket.

Every interval, from small to large, follows the same pattern of setting a concrete objective, building toward the objective, and assessing how we’ve done, preparing for the next interval.

Ideally, every prospective example is an executable check put into our growing catalog of checks. In practice, sometimes we may not be able to be that concrete, but even then, we make an entry into the catalog, even if its result has to be filled in by hand. Wherever possible, we automate the check.

With dials at 12, we use

Bracketed Intervals: to provide, at every level, a rhythmic focus on goals bracketed by prospective and retrospective consideration.

Twelve™️

Complete Team: A self-organizing diverse community working together in close proximity, including all necessary capabilities and skills using
Bracketed Intervals: to provide, at every level, a rhythmic focus on goals bracketed by prospective and retrospective consideration, to deliver
Valuable Working Software Product: consisting of a continuous, sustainable, ideally accelerating delivery of an ever-improving product, providing
Example-Based Transparency: to give the team, and all stakeholders full visibility into the outcomes of the team’s work using a consistent set of real working examples.