Agile Micromanagement, the good and the bad

Jim Highsmith wrote an interesting post about micromanagement. He mentioned Steve Jobs and Bill Gates are good examples of successful product manager micromanagement. I totally agree with that.

He also talks about the Agile process micromanagement. Experiencing both worlds, waterfall and agile as a developer and a manager. I have a strong opinion about it. Agile is all about micromanaging!

Consider these:

• You are coding and someone is talking about your code as you type it (Pair programming).
• Every day you stand up and tell the whole group what you did yesterday and what you will be doing today (Daily Scrum meeting).
• You retrospect about what you did well and what you can improve on (Retrospective)
• You show everybody exactly which task you are working on and how it is progressing (Visible card wall)
• You respect work in progress limits (Kanban WIP limit)
  
• You make a code commit and let everyone know about it. (Continuous Integration)

The more I think about it, the clear it is to me: Agile is all about micromanagement. The good or bad depend on how people adopt its principles and practices. I have experienced many benefits that come from such micromanagement. In fact, when I look back at all projects I participated on, the projects I consider more successful (people enjoying working, delivered great products and improving the work process) are the ones with lots of micromanagement.

Three stages of the Daily Scrum

Lately I have been working in a large Agile program. With large Agile programs, comes common large team challenges, and the need to adapt the Agile development and management practices to better suit the large team challenges.

Currently the program has 180 people distributed over 12 teams. Each team is formed by 15 people (project manager, business analyst, quality assurance and developers; for short: PM, BAs, QAs and Devs). All teams are following agile practices such as 2 week Iterations, Daily Scrums and End of Iteration retrospectives.

In this blog entry I will describe how the daily scrum (or daily stand-up) meeting went through 3 different stages as the program grow from one team to 12 teams (of 15 members), adding up to 180 people on the program.

Stage 1: The Daily Scrum meeting

When the program was small (up to 2 teams of 15 people), each team had a daily scrum. The teams were getting good value out of the daily update. The three questions answered by each team member (what did you work on yesterday, what are you working on today, do you have any blocker?), and some informal catch up by the PMs, BAs, QAs and Devs of the two teams was enough to keep all program members in sync.

Stage 2: Scrum of Scrum with PMs and non-PMs

As the program was growing (consider now 5 teams of 15 people) the teams were still having the daily scrum meeting. However the individual teams started losing context on the status of the program, and important inter-teams updates and communications were not flowing as easily as when the overall program size was smaller.

We started having Scrum of Scrums after the teams’ daily scrum. The Scrum of Scrums (SoS for short) had the same format as the daily scrum: the participants would stand in a circle and would quickly give status update by answering a few questions. The questions were slightly different than the daily scrum questions. The SoS participants would answer the following 4 questions: What did your team do yesterday, What will your team do today, is anything blocking your team, is your team about to put anything in other team’s way?

The participants of the SoS were PMs and non-PMs: team member, such as BA, QA or Dev. The PMs presence was mandatory and they would drive the meeting (answer the 4 questions.) Each team had two representatives: the PM, and the non-PM team member. The PM would daily select the non-PM team member to attend the SoS (this was done in the team daily scrum). At times a team member would volunteer to come, as he/she had to give some important update to the overall program.

The non-PM SoS participants brought very important aspects to the SoS. First they would complement their PM with the extra detail (not too much detail, but enough for spawning the interest for the other program team members.) Second, they were effective radiators of information. They would bring information back from the SoS to their teams (at times the PM was pulled into other meetings prior to returning to their teams.) And last, the non-PM SoS participants made sure that the SoS did not become a PM update meeting.

Stage 3: Scrum of Scrum for PMs

The program was growing in size. Consider the phase where the program reached 12 teams of 15 people. The SoS with PMs and non-PMs became less effective. First, it was taking too long for 24 people to talk. Second, the SoS was becoming a mixed forum of discussion. The PMs wanted to go into further project management details, while the Devs wanted details on the development activities.

We changed the SoS format. At this stage, we broke it into several SoSs: The PM SoS, the Dev SoS and the QA SoS. In fact the PM SoS called was named SoS: Scrum of Scrums. The Devs and QAs meetings had other names such as Dev hurdle and QA catch up. The PMs kept the SoS in a daily basis; the other roles varied the frequency of their catch up meetings.

The SoS became a PM update, but it was an essential (and quick) PM update. Actually, the SoS still kept the stand-up in circle format, which prevented the PMs form giving long updates (specially after standing up in each team stand up, and then in the SoS). Also the PMs were still focusing on answering the original 4 questions of the SoS (described in stage 2).

The art of facilitating the SoS made an enormous difference. It was simple: whenever a PM would go into a detailed update (for example, I found a bug pattern in my team that …), or two or more PMs would repeat the same information (e.g. blocker: my team could not commit because the Continuous Integration server was down) the item would be added to the Parking Lot.

The Parking Lot items would be discussed at the end of the SoS. PMs that were not required could leave the meeting. If other people would be required, they would either be dragged into the meeting room, or a meeting would be scheduled later.

In summary, the described stages of the daily scrum worked for the program in different stages of the program. My main learning from this experience: try what works for your team, but do not hesitate on adapting.

Standups need a Scrum Master

You really need a Scrum Master (or Iteration Manager) to do proper standup meetings. Sure, you can still do them the casual way, but I dare to say that most likely they will be of not much use.
Let me describe two scenarios: The first is done by developers only. The second is run by a scrum master and she makes sure that the standup follows the protocol.

Scenario 1
Depending on the time the standup takes place, most developers are still waiting for the cafeine to kick in and try to remember what they did yesterday; at least the parts worth mentioning.
One after the other, they describe what they did, how great a job they did and what they are planning to do today. Often they mumble to themselves like lonely souls in a bar. Now, imagine a group of, let's say, 6 developers doing the round. Without some mental help, could you remember what each of the developers did the day before or even only which problems they encountered? Maybe, for one or two, but I doubt that you could do that for all of them. So, if no one has to remember and to follow up, how is it guaranteed that issues have been resolved?
How do you know that a specific feature has really been implemented? In short, it is not possible to track and therefore not possible to manage. So, at the end of the iteration it is common if not accepted that there will be surprises. Most likely of the unpleasant kind.

Scenario 2
The scrum master brings out the story board with all the story cards on them and spents a minute or two to memorize important key elements. All of the story cards which are currently played feature the owner's name and estimate and the progress done so far. Some of the cards feature red stickers to indicate problems which needed to be resolved. Once she is setup she calls out and officially starts the stand up meeting.
The developers gather and start in the same way as the other group from scenario 1 did. The scrum master looks up the card currently played by the reporting developer. She listens careful to every word and makes notes. Developers will be reminded to speak clearly and audibly for everyone if needed. If the card features a red sticker, she removes it if the problem has been resolved.
After the standup, which is a really busy moment for a scrum master, she has lots of notes and her engaged day starts. First, if not done on the fly, she will update the story board ie. moving cards to different stages, noting progress, placing red stickers, ...
She then will start to work out solutions for the problems reported. That could be to get new hardware, borrow a resource for a couple of hours from another department, etc.. The scrum master keeps the engine going all the time and knows at any moment the state the current iteration is in.
The next day, the procedure repeats. She listens again to each of the short reports and takes notes. She even might ask a couple of questions during the standup -- if short -- or address developers off-line to make sure that the story is working out as planned and that resolved issues are really resolved.

Comparing those two scenarios. Which one do you think is more effective, which one has the least chance of issues being overseen or worse forgotten? The answer is obvious. In the 2nd scenario, the scrum master is on top of things and chases loose ends and essentially herds the cats.

What can you do if your environment does not provide a scrum master? Well, this is a hard question. In best cases someone steps up to the challenge and tries to be as much of a scrum master as possible. Often, this is already an individual with leader capabilities like the tech lead or project manager. Which one of those two will fit the bill better? I won't try to answer this question as this needs to be decided on a case by case basis. Both have advantages and disadvantages which need to be evaluated against their personal role and agenda.

Now, if I reconsider the title of this blog it should be: 'Software Projects need a Scrum Master'.