James King

One of the paradoxes of working in an agile way is that it should create a predictable rhythm (or cadence) but it is actually best suited to tackling rapid change and great uncertainty.

Predictable work in the face of change and uncertainty sounds like an odd thing to aim for, which means that some agile teams default into one of two antipatterns

• Assuming that being agile means being reactive (or “responsive”) and ending up in a world of constant rushing with a potential lack of clear direction; or
• Trying to make the world outside the team extremely predictable so that the team never has to risk committing to things until they “meet the definition of ready” or more accurately “are defined precisely so there is no risk”.

The first approach leads to the opposite of “sustainable pace” while the second approach leads to a lot of waste, increasing pressure from stakeholders and then the opposite of sustainable pace.

In a world where your understanding of the problem you are solving evolves as you work AND the world is changing nearly as fast as the team is creating value, predictability can never come from detailed analysis or extraordinary commitment.

So what?

So – I claim that creating predictable habits leads to better results. For example, if I want to commit to learning Spanish, I could say that I want to learn to speak at a basic level in 3 months, but it probably better instead to commit to a Spanish lesson a week and a 20 minute practice a day.

Committing to the habit is how you will achieve the goal.

Nice in theory I think. 

Applying the theory

So I told a team that they would find predictability in all the uncertainty and change … IF THEY WENT AGILE.

They believed me so they went agile. We agreed to work in sprints and use velocity; we defined what “done” meant and we used stories to better understand our work.

But unfortunately the world did not become more predictable around the team and they still had heaps of change impacting them. 

Then I admitted that whether of not they face uncertainty, some teams find velocity and story points are dodgy and actually distract them from the work they are doing.

They were sad and asked if they should ditch all the scrum and story jargon and go hyper-kanban instead. 

A pure focus on getting stuff done should help, in theory, with ever decreasing cycle time and an incredible focus on managing the work. But I knew they would be sad when they learned that there is no “hyper” in Kanban, just great transparency and persistent evaluation what causes cycle time and quality to get better or worse. It is actually no less work and it only leads to improvement if you have the time to make your work really visible and constantly reflect on how to remove waste from it.

They decided to skip the hyper-Kanban and take onboard the transparency and reflection. 

I said I would design a retro to help them and I did so. 

I got ready to run it, but the team moved too fast for me. They built some of the transparency and reflection into their general discussions between retrospectives, including their stand-ups, but also including other times. 

We supported the discussions with an occasional look at some data from our wonderful Jira reporting tool that is every bit as clean and smooth as you would expect. 

Actually the data was a bit woeful because their coach was not helping them to remove all the noisy data that was actually impeding transparency and reflection. I wont say who the coach was because it was me and I don’t want to admit to being part of the problem. It is easier to blame the tools and the processes than to take individual accountability in agile.

Anyway, in spite of the messy data, they found some clear indications in their story wall, filters and sprint reports. So they had some options (or hypotheses) for areas to make some minor tweaks.

They also took on board the idea of limited WIP when making improvements, so they wanted to try one or two improvements at a time rather than to create a large laundry list of “new sprint resolutions”.

I still wanted to run my retro but it seemed to run counter to the idea of limiting change to one step at a time when they already had some ideas for improvement, based on pausing and reflecting during the sprint. 

I didn’t want to waste the agenda I had created but I feared that we would generate more ideas in the retro, which would actually create a backlog of things to try, which would in turn result in either a wave of improvements happening all at once and creating chaos, or a backlog of potential things that sat their aging.

It would not be seemly to be the coach who ended up being one of the impediments to predictability and continuous improvement after all.

So I did not run my retro and now the agenda for a potentially cool workshop/retro is still sitting in my backlog to this day.