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.

NoEstimates, Applied

[A colleague recently posed the following rhetorical scenario about how to deal with a situation that presumably requires upfront estimates, to which I responded internally. I’m republishing it here, as I think it’s a common question, especially for service providers who are perhaps skeptical and/or misinformed about NoEstimates techniques and philosophy.]

A market opportunity demands that I have a gismo built by a certain date.  If delivered after that date the gismo development has absolutely no value because my competitor will have cornered the gismo market. If I miss the date, Gismo development becomes sunk cost. I’m looking to hire your top-notch development team.  Before I do I need to know the risk associated with developing gismos by the compliance due date to determine if I want to invest in gismo development or place my money elsewhere into other opportunities.  I need to understand the timeline risk involved in hitting that date.  Your team has been asked to bid for this work.  It is a very, very lucrative contract if you can deliver the gismos no later than the due date.  Will you bid? How will you convince me that I should choose your team for the contract? How will you reduce my risk of sunken cost of gismos?

Let me take each of these questions in turn, since each is important and related but independent of the others.

Will you bid?

This depends on factors like potential upside and downside. Given the uncertainly, I would — in the spirit of “Customer collaboration over contract negotiation” — probably try to collaborate with you to create a shared-risk contract in which each of us had roughly equal upside and risk shared. Jacopo Romei has written and spoken on this topic much more comprehensively, eloquently and entertainingly.

How will you convince me that I should choose your team for the contract?

This is relatively orthogonal (or should be) to the question about estimating, though the subtext — that the appearance of certainty somehow credentializes someone — is commonly conflated with ability to deliver. In a complex, uncertain world, you probably shouldn’t trust someone who makes promises that are impossible to follow through on.

I would “convince” you by creating a trustful relationship, based on how fit for purpose my team were for your needs. Though I wouldn’t call it “convincing” so much as us agreeing that we share similar values and work approach. Deciding to partner with my firm is a bit like agreeing to marry someone: We conclude that we have enough shared goals and values, regardless of the specifics, and trust each other to work for our mutual benefit. For instance, two people may agree that they’d both like to have children someday; however, if in the unfortunate scenario that they can’t, it needn’t invalidate the marriage.

How will you reduce my risk of sunken cost of gismos?

This is probably the question that most relates to the question of understanding when we’ll be done. In addition to the shared-risk model (see above), we have a few techniques we could employ:

  • Front-load value: Is it possible to obviate an “all or nothing” approach by using an incremental-iterative one? Technical practices like continuous-delivery pipelining help mitigate the all-or-nothing risk. Will delivery of some gismos be better than none?
  • Reference-class forecasting: Do we have any similar work that we’ve done with data that we could use to do a probabilistic forecast?
  • Two-stage commitment (Build a bit then forecast): Is it possible to “buy down” some uncertainly by delivering for a short period (which you would pay for) in which we could generate enough data to determine whether you/we wanted to continue?

Reference-class forecasting: Reference-class forecasting is “a method of predicting the future by looking at similar past situations and their outcomes.” So do we have any similar work that we’ve done with data that we could use to do a probabilistic forecast? If we do, I would run multiple different forecasts to get a range of possible outcomes. My colleague’s scenario is about building a software gismo, so if we’ve built other things like this gismo, we would use that past data. Maybe we’ve done three similar kinds of projects. The scenario is a fixed-date problem: Could we deliver by a date (let’s say it’s Christmas)? Here are some forecasts then we would run with data from previous work:

Project A 

Project A (forecast from https://actionableagile.com/)

Project B

Project B

Project C

Project C

Now we can pick our level of confidence (that is, how much risk we’re comfy with) and get a sense. Say we’re very conservative, so let’s use the 95th percentile:

  • Project A: at least 584 work items
  • Project B: at least 472
  • Project C: at least 891

So we have the range based on three actual delivered projects that we could do, very conservatively, at least 584 things between now and Christmas. Furthermore, we might also know that each of these projects required some number of work items (300? 2000?) to reach an MVP. That info would then help us decide whether the risk were worth it.

Two-stage commitment (Build a bit then forecast): Is it possible to “buy down” some uncertainty by delivering for a short period (which you would pay for) in which we could generate enough data to determine whether you/we wanted to continue? So maybe we’ve never done anything like this in the past (or, as is more likely the case, we have and were simply too daft to track the data!). The two-stage commitment is a risk-reduction strategy to “buy some certainty” before making a second commitment. Note that this approach protects both the supplier and the buyer.

In this case, we would agree to work for a short period of time — perhaps a month — in order to build just enough to learn how long the full thing would take. For the sake of easy math, let’s say it costs $1m each month for a team. Would our customer be willing to pay $1m to find out if he should pay $8m total? Never mind the rule of thumb that says if you’re not confident that you will make 10X your investment, you shouldn’t be building software. Most smart people would want to hedge their risk with such an arrangement. So this approach lets us run the forecast as soon as we’ve delivered 10 things, so here’s an example of the forecast:

Example forecast after delivering 10 items

Same idea; we are now basing this on the data from the actual system that we’re building, which is even better than the reference-class approach. Note also that by continually reforecasting using data we could decide to pull the plug and limit our losses at any time, whether that is a month in, two months, etc.

Better questions to ask

People propose rhetorical scenarios like this one with a certain frame. Getting outside of that frame is one of the first challenges of this new way of thinking. It’s not that NoEstimates proponents don’t care about when something will be done (rather, assuming that the information is helpful, it’s just the opposite — we use techniques that rightly portray non-deterministic futures) or are flippant with respect to cost. (For those times when I have come across that way, I humbly apologize.) Rather, we want to offer a different thinking model, such that we ask different questions in order to reframe to bring us to a more helpful way of approaching complex problems, like:

  • In what context would estimates bring value, and what are we willing to do about it when they don’t? (Woody Zuill)
  • How much time do we want to invest in this? (Matt Wynne)
  • What can you do to maximize value and reduce risk in planning and delivery? (Vasco Duarte)
  • Can we build a minimal set of functionality and then learn what else we must build? 
  • Would we/you not invest in this work? If not, at what order-of-magnitude estimate would we/you take that action? 
  • What actions would be different based on an estimate?

And when we do need to know some answers to the “When will it be done?” question, we prefer to use practices that give us better understanding of the range of possibilities (e.g., probabilistic forecasting) rather than reflexively take as an article of faith practices that may not yield the benefits we’ve been told about. That’s why I always encourage teams to find out for themselves whether their current estimating practices work: Most of the time — and I publish the data openly — we find that upfront estimates have very low correlation with actual delivery times, meaning that, as a predictive technique, they’re unreliable (Mattias Skarin found a similar lack of correlation in research for his book Real-World Kanban). It’s not that NoEstimates people are opposed to estimating; it’s that we are in favor of practices that empirically work.

My Favorite Pairing Partners

I’ve been reflecting on the many things for which I’m thankful, and, of course, that includes many people. I wouldn’t be where I am today — nor have enjoyed life nearly as much — without the numerous people who have paired with me, whether it’s been via software development, trainings, coaching, role-sharing, conference talks, etc. So here’s a gratitude in photo-gallery form — thank you to all of you (and many more not shown) who have taught, listened to, borne with, encouraged, supported, shared with, challenged, laughed with and otherwise made amazing memories with me. You have made me a better person, so thank you.

  • Torsten Leibrich (ThoughtWorks), Manchester, UK
  • Xavier Paz (ThoughtWorks), Santiago, Chile
  • Yasir Ali (Asynchrony), Los Angeles
  • Ryan Stephenson (Asynchrony), London
  • Luca Minudel (ThoughtWorks), London
  • Paul Ellarby (ThoughtWorks), Kansas City
  • Umar Akhtar (ThoughtWorks), Bonn, Germany
  • Ryan Boucher (ThoughtWorks), Cebu, Philippines
  • Anette Bergo (ThoughtWorks), Cebu, Philippines (with "Mitch," Krystle and Marlon)
  • Michael Fait (ThoughtWorks), Crawley, England
  • Vipul Garg, Bonna Choi, Kris Gonzalez, Saleem Siddiqui (ThoughtWorks), Seoul, South Korea
  • Malcolm Beaton (ThoughtWorks), Venlo, Netherlands
  • Cliff Morehead (ThoughtWorks), Seattle
  • Greg Jesensky (ThoughtWorks), Bangalore, India
  • John Yorke (Asynchrony), St. Louis
  • Patti Mandarino (ThoughtWorks), Chicago
  • Dimitrios Dimitrelos (Accenture), Athens
  • Karl Scotland, Paris
  • Jason Tice (Asynchrony), St. Louis
  • Lisa Smith, Denver
  • Roger Turnau (Accenture) and John Pinkerton, Kansas City
  • José Rosario, Prakriti Singh, Duda Dornelles, Esther Butcher, Michael Fait, Mridula Jayaraman, Mia Zhu, Péter Petrovics, Nishitha Ningegowda, Nelice Heck (ThoughtWorks University), Bangalore, India
  • Chris Turner (ThoughtWorks), Miami (and client friends)
  • Jim Daues, Matt Carlson, Jason Tice, Anthony Bruno, Lean Kanban St. Louis meetup organizers
  • David Kershaw (ThoughtWorks), Los Angeles
  • Hubert Shin (Samsung), Chicago-Seoul
  • Alexander Steinhart (ThoughtWorks), Berlin
  • Daniela Mora Herrera, Paola Ocampo, Susana Opazo (ThoughtWorks), Santiago, Chile
  • Xavier Paz, Mila Orrico, Andrea Escobar, Luciene Mello (ThoughtWorks), Santiago, Chile
  • Jeffrey Davidson (ThoughtWorks)

Leadership-Standup Questions

As more leaders and people in management organize themselves into teams working at coordination and strategy “flight” levels, they — like the operational teams they support — use daily standup/flow-planning meetings. While the goal is the same — to collaboratively plan flow for the day — the questions may differ, since the levels at which they’re working are different.

So what do standup meetings at coordination and strategy levels look like? Here are some questions that you may ask yourself and your fellow leaders:

  • What process,  meeting or organizational policy can I make more psychologically safe today?  One of the most important jobs for a leader at any level is to promote psychological safety. Hear the voice of Edwards Deming whispering in your ear: “Drive out fear, so that everyone may work effectively for the company.” (Sometimes, because of voice-silence asymmetry, that might actually mean not attending a meeting if you’re not sure that your presence will promote safety.)
  • Where are silos occurring?  Where are handoffs between teams and processes happening? When you’re a leader working at a coordination or strategy flight level, you have a wider-lens view on flow. With that vantage point, always be looking for organizational-refactoring opportunities that will lead to better end-to-end flow.
  • What failure do I need to learn from and share to set an example for others? If we want our colleagues at the operational level to be free to admit and learn from mistakes, leaders at other flight levels need to set the example. What public-service announcement might you write? What learning would you like to share with someone other than those at your same flight level?
  • Where has it been a while since I just actually saw where work was being done and value created? Leaders need to spend time “going and seeing” in a psychologically safe way so that they can actually remove friction in the lives of our colleagues. One group that I worked with kept a lightweight gemba-walk chart in their obeya and incorporated it as a regular part of their coordination-level standup.
  • What decisions am I planning to make that others could make? If that question makes you uncomfortable, ask yourself what is driving that feeling and perhaps fear that you need to be the one making those decisions. To use David Marquet’s two pillars for distributing control, perhaps you need to be clearer about your vision. Or perhaps you fear a lack of competency in your colleagues. What competencies are our colleagues needing in order to do what we’re asking them and that they’re aspiring to do?
  • Whose coaching invitation might I seek today? As modern leaders try to spend increasing amounts of their time coaching and pushing decision-making downward, they need to respect the need to be invited rather than force themselves on their colleagues. However, it’s possible to seek an invitation by being safely present and available (see the next question) and showing up as something other than a boss.
  • What meetings am I planning to attend that I may not truly be needed at, and how can I create more space in my day to be available to others? If you’re justifying your existence by attending meetings, it’s likely that you’re assuming too much decision-making authority or simply not providing much value to the organization. Moreover, you’re not going to be available when someone pulls the metaphorical andon cord and needs management support. Your time is better spent developing others; as Noel Tichy writes in The Leadership Engine, “The ultimate test for a leader is not whether he or she makes smart decisions and takes decisive action, but whether he or she teaches others to be leaders and builds an organization that can sustain its success even when he or she is not around.”

Do you even know what a kanban is?

Jerry: What happened to my stereo? It’s all smashed up.
Kramer: That’s right. Now it looks like it was broken during shipping and I insured it for $400.
Jerry: But you were supposed to get me a refund.
Kramer: You can’t get a refund. Your warranty expired two years ago.
Jerry: So we’re going to make the Post Office pay for my new stereo?
Kramer: It’s just a writeoff for them.
Jerry: How is it a writeoff?
Kramer: They just write it off.
Jerry: Write it off what?
Kramer: Jerry, all these big companies, they write off everything.
Jerry: You don’t even know what a writeoff is.
Kramer: Do you?
Jerry: No. I don’t.
Kramer: But they do, and they are the ones writing it off.
Jerry: I wish I just had the last twenty seconds of my life back.

— Seinfeld, The Package

Kanban is not exactly new to knowledge workers. It has been around since at least 2005. Yet even today when I hear someone say “yeah, we’re doing kanban” because they’ve decided to “get rid of iterations” or simply depict their requirements on digital cards, such as in Kanbanize or — may God help them — Jira, I feel like Jerry: “You don’t even know what a kanban is.”

I understand the reason for the confusion, though, as it has to do with the differing uses of the concept of a “card.” Kanban is roughly translated from Japanese as “signal card.” But a signal for what?

The first manifestation of kanban was in physical manufacturing, in which the card represented not the actual component or parts being built (like a tire or a box of screws) but a signal that the system had capacity to pull in the next batch of material. This “signal of capacity” was the key to just-in-time assembly, reducing inventory, improving flow and preventing overburdening of the system. (The card actually “recycles” itself back into the system.)

This is not a kanban
In intangible-goods delivery systems, the card is not a kanban.

In knowledge work or “intangible goods” (e.g., software) delivery systems, we also want to obtain those lean benefits. The problem arises from misunderstanding the purpose of the cards we use: The venerable agile user story is expressed on a card (either physical or digital) — it’s one of the Three Cs! But the user story is a signal of demand and not capacity. Thus any card that we post on our work board is more analogous to the physical part in a manufacturing line (or, to use a different example, the visitors queueing at a museum or botanical garden). We need a virtual kanban to signal capacity and create a pull system.

We create these capacity-signaling virtual kanbans usually in one of two ways:

  • Visual indicators of space (like an empty box)
  • Explicit work-in-progress limit signs (like WIP=2)

So in knowledge work, it’s not the card but the available open spots for the card that are the kanbans! Signals of demand — work that someone wants to be done — are powerless to realize the benefits of flow. Rather, the only way we achieve a pull system is to signal capacity. Otherwise, it simply can’t and shouldn’t be called kanban in any meaningful way.

Flight Levels and Metrics

A couple of years ago, I introduced a two-dimensional model for thinking about how to measure software-delivery teams’ health and fitness-for-purpose. In the ensuing time, I’ve realized that the two dimensions — delivery aspect (product and service) and perspective (internal and external/customer) were insufficient for organizations looking to connect beyond the team level.

Fortunately, a model for higher-level alignment and improvement already existed: Klaus Leopold’s Flight Levels. And as I’ve increasingly used this model, the third dimension of my metrics framework came into focus: level. And that has brought me to what I and some dad-joking client friends are calling the “rubrics cube” of metrics. Don’t worry: It’s a much better tool than a pun.

“The Rubrics Cube”

This framework for measurement consists of three dimensions:

  • Delivery Aspect: Product/What, Service/How
  • Perspective: Internal/Provider, External/Customer
  • Level: Team/Operational, Program/Coordination, Portfolio/Strategy

The dimensions are meant to cover most areas of concern to stakeholders. For instance, a product team cares about its own internal health in terms of how they’re working, so they might track team engagement (which would be a metric in the upper left of the purple slice). A portfolio manager would likely care about the collective return on investment of a portfolio of products (which would be in the lower right of the royal-blue slice). A delivery manager might want to know when a product — whose work spans multiple teams — will be done (which would be in the upper right light-blue section). 

Team/Operational Level (Purple section)

The purple section deals with delivery-team or operational-level concerns. This is typically the level at which a product team, including roles like scrum master and product owner, works.

Program/Coordination (Light-Blue section)

The light-blue section deals with program or end-to-end coordination-level concerns. This is typically the level at which management, including project managers and product managers, works.

Portfolio/Strategy (Royal-Blue section)

The royal-blue section deals with portfolio or strategy-level concerns. This is typically the level at which highest-level leadership, including executives and strategic vision-setters, works.

As Klaus notes in describing flight levels, “at Flight Level 2 and 3, it isn’t about the board. The system represents the points of communication.” Accordingly, the measurements we use at those levels should do the same, communicating information that allows leaders to make better decisions that are aligned all the way to top-level strategy.

I’ve found the cube to be useful insofar as it gives a variety of stakeholders, most of whom have their own “view” onto the organization, a language for describing what’s important to them. We can now talk about “what they care about” using the terms of the three dimensions, which seem to resonate with them.

Patrick Henry lithograph

Forecasting by “The Lamp of Experience”

https://www.loc.gov/item/2001700209/
No, this is not a planning-poker meeting.

Many people are familiar with Patrick Henry and his “Give me liberty, or give me death!” speech on March 23, 1775, whose closing line became the war cry of the revolution that led to independence, which Americans celebrated yesterday.

Less well known is Henry’s position on forecasting! But the wisdom of this American patriot is as prescient today for us in knowledge work as it was for the fledgling freedom-seeking colonies of the 18th century.

First, here’s that founding father on the idea of basing decisions on hopefulness:

…it is natural to man to indulge in the illusions of hope. We are apt to shut our eyes against a painful truth, and listen to the song of that siren till she transforms us into beasts. Is this the part of wise men, engaged in a great and arduous struggle for liberty? Are we disposed to be of the number of those who, having eyes, see not, and, having ears, hear not, the things which so nearly concern their temporal salvation? For my part, whatever anguish of spirit it may cost, I am willing to know the whole truth; to know the worst, and to provide for it.

I was once involved in a leadership group that met weekly to review its work board. The chair of the group would go card-by-card through the in-progress tasks and ask each responsible person when he or she thought the card would be done. “Oh, about two more weeks, I’m pretty sure,” was the inevitable reply. Two weeks was the time-honored estimate that the leadership group had learned was just right: Not too ambitious as to require an accounting at the following week’s meeting, but also not too much of a sand-bag as to call the boss’s attention. It was also, I suspected, largely based on hope.

But if not borne of hope, how would Henry propose we plan? He continues:

I have but one lamp by which my feet are guided, and that is the lamp of experience. I know of no way of judging of the future but by the past. And judging by the past, I wish to know what there has been in the conduct of the British ministry for the last ten years to justify those hopes with which gentlemen have been pleased to solace themselves and the House.*

Indeed! Henry was encouraging his fellow patriots to lean against the human optimism bias and use data to inform their decisions.

In my example with the leadership group, after hearing leader after leader parrot the “two weeks” estimate, I went through the archive of cards that had been completed. Sure enough, hope was hardly a reliable guide: I found that the 85th-percentile completion mark was 63 days! That meant that 85% of the time, work finished in 63 days. Even the 50th percentile was 35 days, more than twice the two-week estimate.

To paraphrase patriot Patrick, the group simply had nothing to justify those hopes with which they had been pleased to solace themselves and their chair. Rather, they could have used the “lamp of experience” to forecast when their work would be completed.

Ultimately, Patrick Henry’s data-driven argument held sway, and the colonies acted not by “hugging the delusive phantom of hope” but by seeing that the battle “is not to the strong alone; it is to the vigilant, the active, the brave.”

Fortunately, in most organizations, moving toward a data-driven way of making decisions isn’t a life or death proposition as it was in 18th-century America. It can, however, require vigilance (track your data!) and a bit of bravery (dare to offer your estimate in probabilistic terms!).

*The “data points” of British conduct that Henry enumerated:

Is it that insidious smile with which our petition has been lately received? Trust it not, sir; it will prove a snare to your feet. Suffer not yourselves to be betrayed with a kiss. Ask yourselves how this gracious reception of our petition comports with those warlike preparations which cover our waters and darken our land. Are fleets and armies necessary to a work of love and reconciliation? Have we shown ourselves so unwilling to be reconciled that force must be called in to win back our love? Let us not deceive ourselves, sir. These are the implements of war and subjugation; the last arguments to which kings resort. I ask gentlemen, sir, what means this martial array, if its purpose be not to force us to submission? Can gentlemen assign any other possible motive for it? Has Great Britain any enemy, in this quarter of the world, to call for all this accumulation of navies and armies? No, sir, she has none. They are meant for us: they can be meant for no other. They are sent over to bind and rivet upon us those chains which the British ministry have been so long forging. And what have we to oppose to them? Shall we try argument? Sir, we have been trying that for the last ten years.

Single-Magnitude Story Sizing (Rather than Same-Sizing)

A practice exists in the agile community of “same-sizing” (sometimes called “single-sizing”) user stories. I tend to cringe when I hear this because it’s often accompanied by questionable guidance that it’s “required” for kanban or continuous flow or NoEstimates (it’s not). But at the recent Lean Agile Scotland conference, I heard an interesting and helpful clarification of at least one person’s version of this practice that switched on a light for me.

 

Lyndsay Prewer gave a talk on reimagining agile ceremonies in which he touched on “evolving estimation.” He noted that his teams had started following Pawel Brodzinski’s three-choice approach of “estimating”:
  • 1
  • TFB: Too F-ing Big
  • NFC: No F-ing Clue
Sounded good — I like Pawel’s cheeky and simple heuristic. But I’ve seen teams interpret this as meaning all stories need to be a one either in terms of relative sizing (doing only the “ones” in a Fibonacci estimation session, for example*) or absolute time (doing only stories that would take one day). But here’s where it got interesting: Lyndsay then explained that, for his teams, the “single-sizing” — the “one” in Pawel’s approach — meant that the team expected the story would take between two and 10 days to finish (10 days being the total duration of the two-week sprint). This single size then wasn’t same-sizing at all: It was single-magnitude sizing. Lynsday gave me hope that perhaps not everyone who says he’s doing “same-sizing” is actually trying to make upfront guesses about uniform effort and delivery duration.

 

At the very least, though, it gives us some language to clarify things with: Single-magnitude sizing is indeed a salutary practice, insofar as it accommodates the impossibility of guessing delivery time as well as the need for predictability. A few additional points of guidance and clarification:
  • Saying that any story seems likely to finish within a range of time (good use of time) is different from saying the specific time that it will take (fool’s errand). We’re not saying that Story X is a five (or whatever) but simply saying it’s likely 10 days (or 20, etc.) or less. Mike Cohn stated this well when he wrote “Try to keep most estimates, or at least the most important estimates within about one order of magnitude, such as from 1-10. There are studies that have shown humans are pretty good across one order of magnitude, but beyond that, we are pretty bad.” But Cohn goes to far, in my opinion, with his next advice, which refers to the Fibonacci sequence “That’s why in the agile estimating method of Planning Poker, most of the cards are between 1-13. We can estimate pretty well in that range.” Data is showing that we can’t (upfront estimates have little correlation with actual delivery times). Playing poker is gambling!
  • The reason we care about sizing within a single magnitude is that it helps us satisfy the assumptions behind Little’s Law, which makes forecasting more reliable.
  • The data should inform the sizing, not the other way around. Rather than starting with the boundary of a sprint, I would start with the actual data of observed delivery times and work backward from there. For instance, if a team finds that stories are sometimes taking up to 15 days to complete, forcing them into a two-week (10-day sprint) cycle is only going to drive counter-productive behavior.
  • If you are using this approach for sprints, then I would make the sprint duration at least twice the highest number in the range. For example, if you’re observing stories to take between two and 10 days, I would make the sprint 20 days long, because you need to accommodate the possibility of starting one of those 10-day stories late in the sprint, which would jeopardize the sprint goal (remember, you don’t really know which stories are going to take 10 days because effort — even if estimated perfectly — is only one of many sources of variation). That’s if you care that everything gets finished in a sprint time box. (And if you don’t, then what are sprint boundaries really doing for you?)
  • It’s not necessary to have every story fit that magnitude range. Here’s where percentile levels on scatterplot charts come in handy. You might choose to accommodate some outliers by using the 85th percentile as your upper range. In the example scatterplot below, we see that the 85th percentile gives a range of delivery times between three and 17 days.

    scatterplot
    Delivery-time (aka Cycle Time) scatterplot chart from Kanbanize.com

  • Sizing stories in this way is different from estimating them further, as in assigning time or story points.
So let’s single-magnitude-size our stories. Since the “one” in Pawel’s approach should not refer to the relative size (to say, other Fibonacci numbers) or a unit of time, it’s probably better referred to as something other than a number, like a color. I’ll propose green, since it indicates “go,” as in good enough to go with. So here’s my simplified magnitude-sizing proposal:
  • Green: seems to be within the 85th-percentile range of previous work
  • Red: something other than that

 

*It’s described by at least one person (though I’ve heard it said this way many times): “The idea, at least at high level, is very simple: slice down your tasks until they are all more or less of the same size (1 story point), then your final estimation is just a matter of summing the total number of stories.”

 

Explicit Policies and Classes of Service

IMAG4717As I was driving today, I pulled up behind a car that was stopped at a light. The light turned green, but the car didn’t move. I waited a couple of seconds, then switched lanes and drove around it. As I looked in my rear-view mirror to see the car just beginning to move, I thought “What a terrible driver!”

Why did I think that? It’s because we expect certain levels of driving in a civilized society, minimal thresholds of competency, or, if you will, service. I quickly thought of my daughter, who is learning to drive and displays a PERMIT DRIVER sign in the back of our car. Of course, the reason that learners need to display such signs is largely to manage expectations, which is to say, to convey that other drivers should expect a lower class of service around this driver. For instance:

  • Longer reaction time at stop lights
  • Less predictability with stopping distances
  • Reduced average speeds
  • Greater variation in lane position

Which brings us to the idea of explicit policy and classes of service. The permit sign gives some indication of what other drivers can expect. It makes semi-explicit a policy: For people learning to drive, we are more tolerant of substandard driving service. Among other things, this means that we’ll give a greater berth for these cars and agree not to get too angry with them. For most policies, including this one, we should not only name the policy but also define what treatment or behavior that entails. This allows all participants in the system to know what is expected and how to tune their behavior accordingly. For a learning driver, she knows that she can drive more slowly than the speed limit, and it’s acceptable.

The same is true in knowledge-work systems. We make policies explicit and define them with classes of service, which are policies for selection and processing based on different customer expectations, relative value, risk or cost of delay.

Some examples in work might be:

  • Production-defect fixes are completed 85% of the time within two days.
  • Standard work is completed 85% of the time within 11 days.
  • We pull UI fixed-date work into Ready when it is within 30 days of due date.
  • High-risk due-date items are completed with 95% ontime performance.
  • We always have exactly one tech-debt item in progress.

These classes of service then enable a conversation around the fitness of the delivery system. We ask (at a Service-Delivery Review), is this an acceptable service level? How much are you willing to pay to increase it? Are we possibly over-delivering, in which case we might allocate capacity in a different way?

Going back to driving, we have only two policies, one for licensed drivers and one for learners. But in reality, we experience more, just as I dealt with the “distracted driver,” who had her own unique set of service expectations. As in knowledge work, I might not have been dissatisfied with her performance if she had made explicit her policy — I’m distracted and may have a delayed reaction at stop lights. I would merely have expected it (and sought to change it at the next Dept. of Motor Vehicles service-delivery review, if such a thing existed!). As for those learners out there, here’s my proposal for an updated sign:

new sign

Culture Add Over Culture Fit

You’ve probably heard of the culture-fit interview. Maybe participated in one. Organizations and teams rightly want to know not only does this person have the skills and aptitude for the job, but also “will this person work in our particular environment?” Prospective employees also want to know that. But by emphasizing culture fit — the assimilable qualities of the person — we may lose sight of an important benefit of bringing new people into our organizations: the person’s additive qualities — new ways of thinking and working, external experiences — that bring energy, creativity and improvement that we can’t simply bootstrap ourselves into from within.

Why Culture Fit Can Be Pernicious

First, don’t hear what I’m not saying — that seeking culture fit itself is unhealthy. Culture fit is absolutely an area of concern, and organizations and candidates should of course consider it in the mix of hiring and development attributes. However, we need a counterbalance, a corrective to it. That’s because culture fit is all too often a one-way concern: Will the person fit in with us? Lest we miss out on what our new hires have to offer, we need that to be bidirectional and mutual: What can we co-create that we couldn’t before?

The lure of culture fit can be particularly pernicious for organizations that pride themselves on their culture. And it makes sense: You don’t want to hire a person who is at odds with the group’s core values and principles. But the tribal nature of culture means a rejection to some degree of outsiders. No matter how much lip service we give to diversity and inclusion, we’re often satisfied with a superficial accomplishment: We’ve hired people who help us create a rainbow in corporate photos, but unfortunately that diversity is only demographic deep. The truly helpful impact is measured only insofar as we allow their ideas to penetrate the often impermeable boundaries of our culture after we’ve hired them.

For example, I once worked with a leadership team who had been in the organization for many years and typically managed their work through spreadsheets, which meant that the group tended to meander in their discussions and would jump from one priority to the next. When I joined their ranks and offered the idea of making the work more visible on a card wall, the group had a choice:

  • Reject the idea out of hand
  • Nod and passively acknowledge the idea but ultimately ignore it
  • Consider then either try or reject the idea

Only the third option demonstrates that a) the group was intellectually curious enough to discover new ways of working and b) viewed their new colleague as having something to contribute. Unfortunately, this group’s choice was to ignore it. Only long afterward did I realize that it wasn’t intentional or out of malice but merely because the group had become so ossified that they couldn’t even countenance what it might mean to work differently. Partly because they had been successful on their own, they had no mental model for improvement that originated somewhere else. It’s the opposite of the “prophet without honor in his hometown” problem; it’s more like “Can anything good come from outside of here?”

And that’s the danger of culture fit: Without intentional and disciplined practices that keep us open to the new members of our groups, we will atrophy in our existing ways of thinking and working.

Culture Fit without Culture Add

Many new hires struggle to find and stay in the flow channel, psychologist Mihaly Csikszentmihalyi’s concept for “being in the zone,” or full engagement in work. I believe that much of the reason new hires find themselves languishing outside of the flow channel is attributable to a lack of mutual integration and intentional concern for knowing (a person feeling unknown) and putting to good use the competencies of the people we’ve invited to come work alongside us (feeling unwanted).

By paying attention to culture-adding behaviors, we can design our organizational and team experiences to bring people back into the flow channel.

How to Emphasize Culture Add

So we need to balance two goals:

  • Help the new person to fit into the organization and
  • Help the organization to create space for the new person.

Some organizations offer “get to know you” activities during orientation, which is a helpful start. But we should go beyond learning about the person’s hobbies and family. What special qualities and skills does he or she have to bring to work to positively impact us? This is additive or supplemental thinking.

Heidi Helfand talks a lot about dynamic reteaming and how a single change — someone joining the team, someone leaving it — means that you have a new team. We need to take a moment to acknowledge that, rather than carrying on as if nothing happened. We have a new team member; what does that mean for us?

When I led the coaching practice at Asynchrony Labs, one of the questions we coaches would always ask each other about each candidate was “What can this person teach us?” That is, what new or different ideas or competencies might this potential teammate introduce to our group so that we might collectively improve ourselves? Though we wanted someone who would generally share our philosophical approach, we also didn’t want to remain as we were. We explicitly acknowledged that we had a hole in our group, and though we may not know exactly what it was, we pursued filling it from outside ourselves. It’s the perfect culture-add question, because it ensures by its nature that you’re honoring and intentionally expecting the new person’s unique contributions.

Some other options for emphasizing culture add:

  • Marketplace of Skills activity 
  • Strengths Interview (from First, Break All the Rules), which is then shared with each of the new hire’s teams for the first year
  • Create opportunities for the new hire to teach his or her new team (or other group) something that he or she brings ; another option is to have each new person, as part of orientation or onboarding, actually have a spot in the agenda to share something about what he or she brings. This demonstrates the organization’s view not only that each new person is valued but that the organization has a need to learn and improve and that the new person in their midst is going to help.
  • Personal Best
  • The Ten Faces of Innovation activity
  • Follow him or her on Twitter, etc. What’s the Twitter-follower imbalance? That is, how many of your team does the new hire follow, and how many of the team follow him?
  • Give the new person point of privilege in retrospectives and other team meetings

Ultimately we need to be taking the disciplined steps each day to ensure that culture adding happens, because in our tribal ways, it’s unnatural. Build in a policy whereby someone from the organization — I call this role the onboarding concierge — helps the group to learn about the new hire to find out what the person loves, especially the stuff outside of the role you’ve hired him or her for. Even simple changes in how we talk about our approach can help, like how one company changed their approach from “culture fit” to “values fit.”

Herman Miller’s Ed Simon (as quoted in The Fifth Discipline) summarizes the challenge well:

Embracing change does not mean abandoning a core of values and precepts. We must balance our desire for continuity with our desire to be creative. We must learn how to not abandon that core, while simultaneously letting go of past ways of doing things… This requires a new paradigm, a new model of how organizations work — organizations that operate in a continual learning mode, creating change.

For further exploration: