Consistency is key

Recently, with little notice, I had to step back from work for a few days (with a 3 day flu on the tail end of it). This occurred from day 4 through day 8 of a 10 day sprint. The whole time I was gone, I was periodically checking my emails to see if everything was ok. When I finally got back into work on day 9, I found the team progressing nicely right where they should be. There were no fires. There was no emergency. The sprint was on track. It was business as usual.

I put some thought into how this could happen. I had been expecting the worst. I talked with a few of the team members about it (after telling them openly just how proud of them I was) and one of the team members said something that led to an ah-hah moment.

At one point was considering pulling another JIRA into the sprint. Then we stopped and said “Well, what would Ryan do if he were here?”

Then they proceeded to do exactly what I would have done (they worked with the Product Owner because they were blocked on some of the work with the proposal of dropping out this work in order to pull in an equal number of story points from the top of the backlog).

I don’t want to be unpredictable. I don’t want to surprise people. The key to getting people to understand a process and stick to it without supervision is to be consistent.

I think my drive for consistency comes from my love of strategy games. Often times, you can figure out the optimal strategy for a situation and boil it down to a series of steps to follow. As a general example, when I used to play Risk a lot (like 2-4 times a week with my group of friends), my strategy for each game would be to figure out which continent I owned the biggest stake in (Either I own > 50% from the card draws, or the territories I don’t own are split between all the other players so I own > 30% more of it than any of them), place ALL of my troops on a single one of the territories (Assuming I don’t own any border territories and scare anyone else from placing their starting troops in the same continent) and then plan a path to invade which will allow me to take the whole continent and end the turn with my troops defending each of my borders. Every game. It always delivered me the best chance at success.

The same applies with training a team in how to keep WIP (Work In Progress) numbers down. This purpose of that is to getting more stuff done and less stuff half-done by the end of a sprint. It also lends itself to pair programming and knowledge sharing:

Assuming a scrum board has 3 columns: To do (not started), In Progress (started), and Done (completed).

In order to determine what you should be doing, run down the following ordered list:

  1. Is there is any item ready for testing? Grab the testing subtask and start testing. Otherwise…
  2. Is there is any item in progress?
    • Did anyone mention having difficulty with it in the scrum that morning? Go help them out. Otherwise…
    • Is there any story that someone is working on alone (if your team has an odd number of team members)? Go work with them on the issue. Otherwise…
  3. Grab the highest priority item off of the To do list, figure out if someone else is free, and do some pair programming.

This was especially important at the start of our transition into agile. Given this established and consistent ordered list with no ambiguity, everyone knew what to do next (after being told multiple times, but that’s really another post in itself). As the team matured, established chemistry, and learned how to work together, they internalized the goal of this list and were trusted to make judgement calls on when to diverge from it when it made sense for the sprint as a whole.