A Scrum Master Can’t Help You
I failed Scrum.org’s question about whether or not the Scrum Master is a management position. I still think it was a trick question, and I did manage a 77% so I guess I’m qualified enough to still talk about Scrum.
The textbook definition of a Scrum Master is someone who “removes impediments” and facilitates the process for the team. I suppose from a process perspective the Scrum Master does do management type of work but in general terms the Agile community doesn’t agree that the team’s manager makes a good Scrum Master. The general thinking is that a manager can circumvent team self-organization and creativity by directing the team and in theory this is fine but in practice it’s just not reality for medium to large sized organizations. Read more
Recommended Agile Project Management Software
Kelly Waters posted an article recently asking what Agile project management tool folks recommend. Interesting results so far, but from other discussions I’ve been involved with on Linked In and general conversations with other crazy Agile people most of us recommend no software tool to start with.
It’s MUCH more important for teams to understand how to work in an Agile process BEFORE they adopt a tool. Agile teams that are co-located use sticky notes, spreadsheets and whiteboards to manage their work and it is extremely effective.
What this poll isn’t saying providing is context around who is voting and what their environment is. A decision maker who knows nothing about about Agile is probably more inclined to pick the tool first and base that decision on the most well known or “enterprise” version of the software that they hear other people use.
Remember, we value individuals and interactions OVER processes and tools so figure out what Agile is and learn the process BEFORE you worry about the tool.
What tool would I recommend? Well, first I would recommend sticky notes, whiteboards and spreadsheets/wiki until the team learns and really gets what Agile is. Once they know what being Agile is all about and management “gets” what it means, I would recommend either JIRA, Rally or Scrumworks. Rally is GREAT for enterprises, JIRA is great if you want a tool that can do it all and Scrumworks is really lightweight and simple.
Here’s the poll is you’d like to see the results.
Recommended Agile Project Management Software | Agile Software Development Made Easy!.
The Importance of Time-boxing
When using Scrum, your iterations are fixed time (1 week, 2 weeks, 30 days etc) and therefore your cost is fixed so the only thing that can vary is scope. Time-boxing is critical to success when implementing Scrum since you don’t really want to waste a lot of time in useless or long discussions. Yesterday I posted about an estimation session that went off the rails pretty quickly and it was due to the fact we (well, “I”) dropped the ball on enforcing the time-box rule. We started strong and finished weak. A stop-watch, wall clock, phone/pda or whatever is fine to use. I like to use this online tool. You can set the timer for whatever interval you want and it’ll beep when your time is up. I typically give warnings at 5 minutes to go and 2 minutes to wrap it up.
Our iterations are 1 week (we’re re-implementing Scrum, so the shorter the better to allow the problems to surface quickly) so we use these guidelines for time-boxing:
- sprint backlog: 1.5 hours – this is where the team commits to their work and break stories into tasks.
- development activities: 1 hour - If you’re stuck after an hour, ask a team member
- ‘stop the line’ discussions: 15 minutes -if a team members runs into a roadblock, the whole team stops and a quick 15 minute brainstorm session happens. All potential solutions are written on the whiteboard and then the line resumes work.
The biggest question the team always has around time-boxing is “what happens if the meeting is over and we haven’t finished our task breakout?” The answer is simple: The meeting is over. If you didn’t meet your goal, schedule another discussion or in this case, when it comes time to work on that story, time-box the task breakout to 15 minutes.
The lesson is, by time-boxing your efforts you force yourself into focusing on the issue or discussion at hand. It’s tempting to allow a couple more minutes here and a couple more minutes there, but avoid the temptation. The team will get into a rhythm pretty quickly and be much more efficient at time-boxing.
