Monday, August 31, 2009

Rotating Scrummasters - A good practice?

In many Scrum teams a practice has emerged to have the Scrummaster role played by a different team member each sprint. The ideas behind this are many and varied:
  1. Rotating the Scrummaster allows more people to learn Scrum in-depth
  2. Each team member adds new ideas to how to run the Scrum project
  3. Builds skill redundancy for the team. If the Scrummaster gets sick, or quits someone can take over without too much lost velocity
  4. Helps empower the team, everyone gets to participate at all levels
  5. Helps prevent people just reporting status to the Scrummaster
  6. etc
But is this really a good idea?

Most of these benefits can be achieved with other means, and some are caused by the Scrummaster doing a poor job at leading the team. For example with number two, that can be accomplished by having a really great and open team atmosphere, or even good, dynamic introspections. You don't need to be "in charge" to bring forward ideas.

Depending on the context I think it could beneficial to rotate the Scrummaster role around. However, not every single Sprint. It makes more sense to allow at least three Sprints to elapse prior to rotating out the Scrummaster. It will take at least three Sprints for that person to get comfortable in their role and get their mind into the Scrummaster space.

Don't force every single person on the team to take on the Scrummaster role! Not every single person has the personality to do the job well and there is no point in setting someone up for failure.

Even if you don't rotate the Scrummaster role around, it is very important for that Scrummaster to train his replacement. People should always be able training one of their peers to do their job. In the military this is institutionalized for very good reasons, but many companies don't factor in the "bus factor" in their contingency plans. This can seriously harm a company or a release cycle.

What do you think? Should the Scrummaster role be rotated? If so what best practices do you have? Or should the Scrummaster role be assumed by one person so that they can master it?

Wednesday, August 12, 2009

10 Things a Janitor Can Teach You About Leadership

Col. James Moschgat wrote an article about the ten leadership lessons he learned from his janitor at the United States Air Force Academy, an unassuming Medal of Honor winner from the Second World War.

There are some excellent lessons here:
  1. Be Cautious of Labels - Labels don't define people, actions do.
  2. Everyone Deserves Respect - Golden rule stuff.
  3. Courtesy Makes a Difference - Goes with the above rule, respect begets respect.
  4. Take Time to Know Your People - Strengths, weaknesses, motivations, etc.
  5. Anyone Can Be a Hero - Save the day, save the project.
  6. Leaders Should Be Humble - Don't be like "modern" leaders like self-aggrandizing sports heros and the like.
  7. Life Won’t Always Hand You What You Think You Deserve - You need to work hard to get it.
  8. Don’t pursue glory; pursue excellence - Be great at what you do, even if it isn't "sexy", but love your job at the same time, life's too short for anything else.
  9. Pursue Excellence - See above.
  10. Life is a Leadership Laboratory - Examples of great leadership are all around, you just have to look.
Number eight and nine are pretty much the same, I would have pulled the following point into a numbered lesson "No job is beneath a leader". This lesson is one that I can really relate to.

In one particular example, about a year ago, one of the teams I was leading was working on a Java web project that was running a little late. OK, a lot late. The whole team had pulled together to put the final touches on the acceptance build. It was 10pm at night we had to get the build out the door before the end of the day. QC was many timezones away (India) and not yet in the office. We had 3 browsers to test, and only two hours to do this.

The solution was to import that QC test plans into Google docs, then have the entire team run through the test plans collaboratively in real-time. Executing test plans isn't part of a developers normal job, sure they run their own tests, but they not responsible for running sanity tests on builds that are on there way to the customers. But we didn't think twice, we all pulled our socks up and got the job done. Developers, Project Leaders, and Project Managers all worked together to get the testing done.

This allowed us to get the sanity testing done on all the supported browsers done in a fraction of the time it would have taken a single QC person to do it. When the QC started their day a few hours later, they spent their day running their more detailed test scripts against our drop to see if we had missed anything, but the Project Leader and I had confidence that what we were sending the customer didn't have any big functionality or rendering bugs.

When I look back at this example, I see three leadership principles demonstrated:
  • Lead by example
  • No job is beneath a leader
  • Rewarding the team for their sacrifice (reward followers)
Lead by example
In this instance I was able to lead by example by implementing functionality and fixing bugs quickly. By submitting good patches, and performing good code reviews. By working nights and weekends for those four weeks or so, I could show that I too was making sacrifices to my personal time, I tried to ensure that I arrived with the team and left with the team during that time. I wasn’t just dictating that overtime was to be done, I was actually doing overtime. After the project, several of the team members came up to me and thanked me for my contribution, and said that it helped motivate them to work extra hard and get the project done.

No job is beneath a leader
It wasn't in my job description to write code, review patches, or run test scripts, but I did it anyway because it helped the team accomplish the mission. If someone had to go out and pick up supper from the office, I did it. What was really great was that everyone did whatever had to be done. This was a great attitude to see on a team.

Rewarding the team for their sacrifice
I made sure to thank the members of the team personally nearly every night when they signed out for the day. At the end of the project I made sure they were compensated for their time, and provided little thank you gifts to everyone. Doing a few little things to thank them for their time and effort can mean a lot.

When projects run late, teams can easily get de-motivated, leading by example, doing whatever it takes to finish the project even if it’s “beneath” your position, and showing appreciation for the team’s sacrifices are three ways that can help show the team that you are with them and that you support them.

Remember that leadership is about influencing people, hence it is more of a service then a command. You need to influence your team to go the extra mile by being a good leader that your team will look up to, and be inspired from. These three principles honestly applied can help you become that leader.