… over processes and tools

https://unsplash.com/photos/chcyjyRQV74

Here’s an experiment for Agile teams. It’s best for teams that are well established. I’ve used a version of this in various teams I’ve led over the years.

The idea is to examine reliance on processes which have built up over time. This can benefit by discovering what is good process and what is irrelevant. It also helps us understand (or remember) the benefits good processes bring.

Experiment

Set up

1. Time box at least one iteration. Where it helps, talk to others in your organisation and warn them that you are carrying out an experiment.
2. As a team, write down all the processes you currently use. These might include: “stand ups”, “retros”, “code review”, “pull request”, “Friday social”, “architecture meeting”, “walking the board”, “story pointing”, “bug review”, “QA meeting”
3. Identify which of these processes are depended on by external people or teams. For the purpose of this exercise, you will temporarily eliminate as many processes as possible. But, we can’t let people outside the team down. Where you need to maintain an externally visible process, come up with a rota. Ask for permission for one person to represent the team so that others don’t have to.
4. For the remaining processes, create a list in a shared document / wiki / page. These are the processes which you will stop doing as a team.

Method

1. When you would normally conduct a listed process, instead stop and think. What are the useful outcomes you would normally achieve? Seek out and interact with others on your team directly instead. Can you achieve the outcome without reverting to process?
2. If you feel that you have missed out on something useful due to a missing process, write it down against the shared list you prepared above. You are building the profile of what future success looks like for that process.
3. Sometimes, one or more of the team start encountering problems. A missing process may be preventing work being done. Or, people may be encountering other hardships (such as loneliness or anxiety). When this happens, call a meeting to discuss it. Is there a way to accomplish the desired outcome without, or with a subset of, the existing process? During the experiment, try to only add back the bare minimum processes.

Conclusion

This experiment should result in useful outcomes:

1. You may identify processes which were getting in the way of “individuals and interactions” and which can be replaced with more direct interaction.
2. You may find that your processes are good, but can be tuned to more specifically support the outcomes you need as a team.
3. You might find that processes you previously took for granted are particularly valuable, or that they provide unexpected side benefits. These are good learnings to share, both within the team and externally.
4. You should learn about relationships with external people and teams and which of your processes support them

Interesting results

I’ve had a few interesting results from this type of experiment over the years. Below are just a few to whet your appetite!

1. A small, complex build and the sprint board

A small team I led was implementing a security protocol needed for integration from 3rd party systems. As an experiment, we stopped using our normal processes, including our standard use of a (physical) kanban-style sprint board.

We quickly found that we still needed a way to see what was done and what remained. The simplest way we could do this was to divide up the protocol (OAuth 2) into different parts.

So, we added back in physical cards, and put them all the up on a wall. However, we didn’t feel that the normal backlog/in progress/done columns or urgent/non-urgent swim lanes were needed.

We then decided it was useful to draw dependencies between the cards. As we went we marked off which card was complete.

our path to success

What did we learn?

1. There’s a good reason to use a sprint board. We needed to (a) organise ourselves and (b) project to the rest of the company what our status was.
2. As a small, tightly-knit team tasked with a complex subsystem build, we didn’t benefit from the normal way of moving cards across a board. In this context, it made more sense to visualise progress on a dependency graph. This made it easier for everyone to focus on the outcomes.

2. Detoxing morning stand-ups

A few years ago, I led a team who were used to Scrum (though not a particularly healthy implementation). The usual anti-patterns had set in.

One person would stand at the back and hide behind the others. The manager liked to talk most of the time. Everyone’s tasks were examined in an old-school reporting-in fashion. The (thankfully now deprecated) three Scrum questions were used “What did you do yesterday?” “What are you doing today?” “Any blockers?” Nobody really paid attention unless they had to speak.

So, we ran the experiment, stopping our normal processes including morning stand-ups.

We started by planning out a rough increment of work (about 4 months), and a rough plan of how we would evolve the system, keeping it demonstrable and working as we went. We made our progress visible to others via a constantly updated spreadsheet with some rudimentary burndowns.

We were all focused on just one or two shared deliverables at any one time, so there was no need to discuss status or blockages each morning. It was clear to everyone how far we had gotten the day before and what we needed to achieve next.

However, after a while, one of the QAs mentioned that they were missing the stand-ups. Incredulous, we asked him “why?” He reported back that he just missed having contact with everyone first thing in the morning. He felt that it got him ready for the day ahead, and that he felt lonely at the start of the day without them.

So, we added morning meetings back in, but not in the traditional stand-up sense. Instead, we met every morning to have a coffee together and socialise.

there was much rejoicing around the coffee machine

What did we learn?

1. Traditional stand-ups often function in unexpectedly positive ways to support a team.
2. Stand-ups are also useful when dealing with unusual events. This was very evident during the recent global pandemic when people needed to discuss their feelings and feel less alone.
3. The point of the original “Agile” stand up was to do something different. It was a release from a broken tradition of draconian project management meetings. These days, the tradition of Agile standups needs to be challenged and disrupted in the same way that standups did for their predecessors.