Don’t mistake adoption patterns for maturity patterns

“Kanban is for teams that outgrow Scrum.”

“We can’t limit our WIP until we get used to how we work.”

“You can’t start using NoEstimates until your teams have stabilized.”

“Mob programming is an advanced agile practice.”

I often hear the above statements, and many like them, even from experienced agilists. Many in the agile community have a view of certain practices as “advanced” or “for mature teams only.” They seem to base that assumption on the sequence of how they’ve seen them adopted. But it’s possible that they’re mistaking adoption patterns for maturity patterns.

It’s a type of questionable-cause scenario (aka causal fallacy, correlation does not imply causation) that essentially says “Every time I see a team start using <practice X>, it’s after they’ve tried <practice Y>; therefore, it must be because they need to do <practice Y> first.” This makes about as much sense as observing someone who has been eating fast food all of his life and then switches to a healthier diet, and assuming that eating fast food is a necessary step to eating healthy. Like fast food, just because a practice is popular doesn’t mean it’s the best thing for you. Why not start healthy?

To be sure, some practices do require a level of competency before attempting, such as coaching or continuous delivery. But I encourage people to question their assumptions about what they think are advanced practices that might not actually be easier than the things they assume as necessary prior steps.

One such practice is probabilistic forecasting. Probabilistic forecasting basically uses your delivery data — how long it actually takes you to deliver work — and creates a range and probability at each point in the range to tell you when future work might complete. It requires no special meeting, no poker cards, no debates about what a “3” is. It doesn’t require you to “same-size” your stories, to have a certain level of predictability or even to be able to deliver work in two weeks. Yet because teams tend to turn to it only after despairing of their points-based estimating practice, it has a connotation of an advanced practice.

Why? Partly for the simple reason that few scrum trainers know what it is, much less understand how to do it. Plus, organizations that buy scrum and SAFe training tend to want to put into practice what they’ve been taught. This brings up another logical fallacy, the sunk-cost fallacy. But I don’t need a fibonacci sequence to estimate the number of times that I’ve seen teams get wrapped around the axle of relative estimation, fail to give their stakeholders a reasonable answer to the question “when will it be done?” and get beaten up (or beat themselves up) over how bad they are at estimation. (Spoiler alert: Everyone is bad at estimating in a complex environment.) To return to the fast-food analogy: Why wait until your arteries clog to change your diet?

Perhaps the all-time masquerader of “advanced” practices is kanban. As I’ve noted, kanban has many connotations; the “advanced” version is that of flow-based or “iteration-decoupled” delivery. The idea is that teams must first go through Scrum — with all of their replenishment, delivery, demo and retrospection cadences tightly coupled to sprint boundaries — and only then “graduate” to kanban. Quick show of hands: How many immature teams that you’ve worked with are able to build potentially shippable product in two weeks? Doing everything in a sprint doesn’t magically make all the work fit in one, especially if you’re accustomed to yearly releases.  The number of anti-patterns and prevarications that occur from starting teams this way (“QA sprint,” anyone?) is in my opinion one of the major reasons that “transformations” rarely work.  Far from being a basic practice, highly coupled sprints actually require simultaneous competency across a number of technical (e.g., real continuous integration) and business practices (e.g., thinly slicing user stories) to pull off. 

Another connotation of kanban — using work-in-progress limits to create a pull system — is perplexingly saddled with the advanced tag. Here’s how advanced WIP limits are: Agree to not start work any faster than you complete work. It’s one of the few practices in which you actually stop doing something rather than start. Again, simply because you didn’t hear about it until after a niche group started talking about it doesn’t make it any less worth trying now (See: Office Space).

Speaking of limiting WIP, how many organizations resort to big scaling frameworks before mastering that rather basic practice? (Hint: Limit WIP at the highest level of your organization and you may never have to install a big scaling framework.)

And the list goes on. Mob programming? I recently worked with a team new to agile engineering practices (they had little understanding of how to test-drive development) who decided that they wanted to mob program for a couple of weeks before going off on their own individual work. It worked like a charm and gave them an opportunity for fast, shared learning and the confidence to proceed. Far from being an advanced practice, mobbing required only the ability to take turns (something we all learned in kindergarten).

To borrow another analogy: Many parents assume that the best way to teach a child to ride a bicycle is with training wheels. That’s how I learned and that’s what is being sold, so that must be the best way! But many parents are finding that balance bikes are an easier way to build confidence and competency. Like training wheels, which “are counterproductive because children become reliant on them,” some agile practices create unhelpful habits or inhibit learning. As the agile manifesto encourages us, “We are uncovering better ways of developing software…” I encourage you to question your assumptions (or your consultant’s) about just how “advanced” certain practices are. Don’t mistake adoption patterns for maturity patterns. And don’t let anyone tell you that something potentially good and useful now requires you to be more mature.