Urgency is a trap that keeps us from improving our processes

Ask someone why they don't change their process to be "better" and they will often tell you, "I just don't have time."

I see it a bit differently.  It's not time that's the problem.  It's urgency.

If it's worth improving it's worth improving now.  But it's not the potential gains I'm worried about. I'm worried about inaction because you are paralyzed by a lack of urgency.  One of the best ways to get this sense of urgency back is to think in terms of small short experiments that can be done in "this sprint" or in the next week.

Everyone wants to improve.  We hold retrospectives, we do postmortems, we have endless bitch sessions.  Potential solutions abound.  And for every issue almost everyone's got an opinion on how to fix it. The challenge isn't finding ideas, it's creating experiments for change and giving them a go. That's the activity that is so hard to do.  What I see again and again is that people resist attempts to improve the process during the process.  

Our process improvement lacks the urgency of the the work we are trying to do.  At the very least it competes with the urgency of the work for attention and a lot of times it comes up on the short end.

"Look, that's a great idea, but we just can't do it until after [some-deadline]," you'll hear people say.  The reasons given are that it'll be too disruptive, too distracting, require too much training.  And besides, no one's really sure they'll get the intended results until they've actually done it, so it's hard to make a reasonable argument for it's success. In fact, history works against you.  Most ideas for improvement make little difference.  So people would rather wait.

But waiting for some arbitrary deadline is folly.  Show of hands.  How many of you have seen successful efforts to change your processes that come between projects?  Ok, hold those hands up - I'll do a quick count...um, ok.  Zero.

The reason few (if any) have ever seen improvements between projects is that as soon as people finish one project they are off to join another project.  If they join it midstream then that project will consider change "too disruptive."  Ideas you may have about making things better will have to wait - again.

Another reason is that the next project will have a slightly different team.  They'll not want to hear the stories about the "old" team and all of "their" problems because "we're not going to make those mistakes."  Hubris is a huge factor.  So is optimism.  Optimism sucks ass.  (ha - mostly kidding)

To address these problems, and to add a sense of urgency to fixing the process, Agile practitioners often turn to the practice of the retrospective.  I love retrospectives, but out of all the suggested Agile practices this one is probably the easiest to do poorly.  The outcome of a retrospective should be a set of experiments.  The experiments should suggest changes to your team's process that you think will add value.  They should have clear objective and a way to measure their impact.

One of the Agile values is "Responding to change over following a plan."  What does this mean in the retrospective?  It means the teams need to focus on delivering working software.  One of the best ways to do that is relentless focus on improving velocity.

To respond to change and to be willing to work with changing priorities, teams need to focus on constantly improving their velocity.  The faster you can create working software, the more of it you can create.  The more of it you can create, the quicker you can adapt to changes.

I see a lot of retrospectives generate tasks for people - things the team thinks are issues - but then there are few suggestions or experiments for the team to improve it's own processes. Few suggestion or experiments for improving velocity.  If the list of things coming out a retrospective aren't things that are likely to improve your team's process or velocity, then you are probably focused on the wrong thing.  This is not to say that any topics are off the table as fodder for the retro, only to say that the team should always be checking whether the topics and their solutions align with the Agile values.

One reasons that teams make the mistake of coming out of a retrospective with tasks instead of experiments is that tasks are easy.  We all understand how to create a task and assign it to someone.  However, setting up an experiment and deciding on the measurable outcomes, and how to monitor those outcomes, is a lot of work.  It's also uncomfortable because you have to put up with change and wait for a measured result.

Well crafted experiments are generally small.  They tend to not require much training.  They tend to not be too disruptive.  Basically, doing small changes addresses most of the objections that people have to changing their process mid-stream.  But it does require some thinking and some work.  Tasks do not.

One sign of a good retrospective is if one of the items that comes out is to check on the progress of the experiments in mid-sprint.  You've created the experiments, setup a way to measure the impact, and now you're going to monitor and report the results mid-way through the current sprint.

Another sign that you have a sense of urgency around improving your process is if the first thing you do in each retrospective is to review the effectiveness of the previous retrospective's experiments.  If your retros don't start this way, you're probably doing them wrong.

All of this adds the needed sense of urgency to process improvement.  When do you do it?

How about right now.