What do managers do when their teams are using Scrum or some other agile approach to software development? The notion of managers as facilitators was really brought home to me by Diana Larsen in a talk at Agile 2007. Daily standup is one of the first places the rubber meets the road when you’re trying to facilitate a team rather than manage it.
The first thing you can do is show up to a few standup meetings. There’s a lot you can tell about a team just by occasionally showing up to their daily standup meeting.
Who’s there and who isn’t?
Does the whole team usually attend the standup in person each day? Are the same people always missing? How does this effect the team? Maybe you have what the Scrum Bestiary calls a seagull on your hands.
Engaged or disengaged?
Are the team engaged and seem motivated? If not why? Is there something de-motivating the team that you should know about? Are individuals on the team disengaged? Maybe someone’s not entirely happy being on the team (someone the Scrum Bestiary calls a rubber duck).
Do the same issues keep coming up?
Do the same problems seem to come up every time you attend a standup. Does the team keep talking about the same blocking issues? Do the same people seem to get blocked each time?
In each of these cases your inclination might be to (over) react. In fact managers need to remember that “News is just news” and be clear when to offer an opinion and when they are being asked to make a decision. See “What should I do if the team is having problems?” (below).
Frequently asked questions
Some common questions that come up when managers attend their team’s standup meetings:
Should I attend every standup?
No. You probably don’t have time anyway. Attend one or two standups for each team each week. What’s really important is that you attend regularly throughout the project and not just when you hear elsewhere that the team has some problem or other.
Showing up only when you hear the team might be struggling is a clear red flag to them… “The manager is watching”. There’s nothing quite like the feeling of being watched to make people feel they have things to hide.
Do I say anything at standup?
No. You’re a chicken not a pig and chickens don’t get to interrupt the standup. That doesn’t mean you can’t answer questions if the team has any. For example you might be able to help with questions about the overall project schedule.
After the fifteen minute standup is finished the team probably addresses any questions that came up and have been put in the parking lot. A good way to put something on the table is to add your question or issue to the parking lot and have the team discuss it after standup.
Can I help?
Yes, but be careful not to over commit. You probably have a lot of other things on your plate and the worst thing you can do is let the team down. In Scrum Bestiary parlance you are a cow. Chasing up small things for the team or using your network to resolve problems is a great way to show them that you’re not some pointy haired manager. Be very careful about signing up for real tasks the team is trying to finish in the sprint. In most cases this is a bad idea.
What should I do if the team is having problems?
Your first reaction is probably to try and “fix” it. This is the command and control approach to management not the managers as facilitators approach favored by the agile community.
There are two great phrases* I like to think about when something serious comes up:
“News is just news” – News is just data. Don’t feel like you have to act on it then and there. Many things will sort themselves out very quickly and the team will deal with them without any “help” from management.
“Are you looking for a decision or an opinion?” – When someone comes to you with an issue make sure you’re clear as to whether they want you to decide on something or just give them an opinion so they can figure it out for themselves.
In other words once you’ve heard the news ask them if they want a decision or simply an opinion. Above all don’t try and make a decision and implement it without the team. Your first course of action should always be to help them not tell them what to do. The Scrum Master and/or senior members of the team should be able to sort thing out. The may need your help but they don’t need you to try and fix everything for them.
* Credit for the two quotes must go to someone from Borland who used these during his talk at Agile Development Practices 2008 in Florida. I don’t have his name because I got to the talk late and he was standing in for the listed speaker.