Why do some teams fail to meet their sprint “commitments” (hate that word) sprint after sprint? In this post I argue that the cure is working extremely and counterintuitively small, but that our biases (and intuition) make that difficult. There are some deep human things at play.

The Goal

Thought experiment…

Team Acme is asked to set a goal. The goal involves doing a self-selected amount of work.

Here are the requirements for that goal. The output of the work must:

• do something (even if that something is insanely simple)
• be deployable into production (behind a feature flag is OK)
• be exercisable/testable/demo-able
• do no harm
• take five business days or less
• generate some learning/business value (a tiny amount is fine) There are absolutely no requirements as to the minimum size/amount/time of the work. When the team is done, they’ll reflect on their work, and set another goal.

Hmmmm

Faced with these constraints, teams (and the individuals on those teams) tend to think to themselves:

• If we make the goal too small, then there will not be enough work for everyone. We will not be able to split up the work, which will leave people bored (and management wondering why people are idle).
• A small goal will mean we are back in this same situation in a couple days. We should try to set a goal that that will take us a bit.
• We need something that everyone can contribute to, but that isn’t too big. Might it be better to think in individual tasks, and then craft a goal from that? Who does what? Who is good at what?
• *There’s no way a week’s worth of work will be truly valuable. I mean, this is kind of stupid because ANY team can do this with a super-small thing. What is the value of proving that? *What about the rest of the project?
• We’re told to set aggressive goals. If we want to be sure to meet these guidelines, we’ll be forced to underpromise. That’s lame.
• What if we fail? That would be an embarrassment, especially given how flexible the goal is.
• Oh this is a waste. This is an insult to our intelligence. It is a stupid test.

What Happens?

Do you see what is going on? Do you see the dynamics at play? What tends to happen next based on that internal dialogue?

• Team advocates for two week sprints so they can tackle meaningful chunks of work. They reject the <=5 day goal entirely.
• Tasks are farmed out to individuals. Team accountability for the goal turns into individual accountability for tasks. Individuals take on enough tasks to keep them busy for the duration of the block.
• The goal lacks cohesiveness (it represents multiple individual goals strung together), but it is more meaningful in the eyes of the team than a small goal.
• The goal tends to be big for various reasons. Why? Small goals are dangerous. Big goals mean you are trying. Big goals keep people busy. Big goals give you a plausible excuse if things go wrong. Big goals delay the next goal setting. Big goals don’t insult your intelligence. Big goals don’t force you to painstakingly decompose the work into tiny pieces. Oh, and the sprint is two weeks.
• The team accepts high rates of utilization, and tries to “fill up” the sprint (thereby establishing the goal based on the Tetris-like accumulation of individual tasks).
• Somehow, the team fails to achieve the goal, and has lots of valid reasons for why that happened (interruptions, scope creep, new learnings, new team members, tools, etc.)
• This pattern continues despite their best efforts to reflect/adapt Suffice to say, they didn’t set a three day goal.

Why?

Recapping…none of this is illogical to the individuals on the team and their manager. Even though the team had ultimate flexibility (they could literally make a tiny front-end change, for example) … they chose not to take that route for various reasons. Why?

• Fear of failure
• Fear of judgement
• Fear of our success being linked to the success of our teammates. The need to control our own destiny
• Sense that “more time” always equals less pressure
• Aversion to being “under the microscope” / overly-scrutinized
• Pride (“this insults our intelligence” or “I’ve been doing this for twenty years …I can be left alone”)
• Desire to do our best, and tackle meaningful challenges
• Aversion to anyone being idle
• Intuitive sense that smaller batches incur high “set up” costs (in this case planning, context switching, etc.)… which equates to more meetings, and less time “getting the job done” This is some deep stuff. And amazing how it all manifests in how we set goals and plan our work.

So What?

How do athletes tackle a new skill? They master movements. They work on technique. They start small and ramp up.

How do orgs tend to adopt Agile? The team sets a sprint length (often according to a global release cadence out of their control), and starts playing the game. They play a game of Tetris:

“Progress” is measured in the amount of work delivered each sprint (“Velocity”)

… not based on achieving meaningful goals.

The problem is that teams often fail to master working small, and working together. The deep human items under “Why” above remain. They get caught in a cycle of “failed sprints”… with lots of very plausible reasons why they’re happening. Or they become dogmatically predictable and fail to deliver outcomes.

The alternative to all this seems very scary (for the reasons mentioned above). If Agile is sold to “go faster”, then the thought of going insanely slow and working very minimally (and on the surface inefficiently) is anathema.

That’s insane! How could you have 5 day sprints, 3 day sprints, 1 day sprints, variable length sprints, or no sprints at all? That’s too advanced for our team! We’d never be allowed to do something that extreme! The work needs to go on!I propose, however, that this is exactly the set of intuitions and biases that we must challenge. What would it take for a team in your organization to take on the goal above with three days worth of work, even if it meant they needed to swarm and help each other? What would it take to nail working very small?

That’s it for today. Timebox hit. Thoughts?