Australian Scrum Community

Just before my round of scrums today I was thinking about our regular practice of leaning on something during the scrum. The prime position for one scrum being the table near the story wall. We joke about how it’s sometimes a Lean Up rather than a Stand Up (it’s joke, but not one of those funny jokes).

Is 15 minutes too long for us to stand still and listen without needing support? It smells wrong to me.

Watch out for leaning scrums something is wrong.

So you’re running Scrum on your project and you have a burn down chart, a sprint back log and everything is ticking along nicely, or is it? Do you have trouble getting developers to update the sprint backlog? Do they still loose focus of the end of sprint date? Maybe the management keep asking you how things are going, even though they have access to your sprint burn down on the network.

These could be symptoms of an electronic Scrum process. By electronic Scrum process I mean you have sprint data held electronically in say Excel or Visual Studio Team System, your developers and management are required to access these over the network as and when they need to (or more than likely when they feel like it), in reality this just doesn’t work reliably enough. How many times have you heard a developer shut down his pc shortly followed be him grunting “damn I haven’t updated my estimates” by which point it’s too late, he’s going to miss his bus, taxi or a beer!

Then we come to management, ever heard your manager respond with “ah yes I know you sent me a link to it somewhere I just couldn’t find it, and as I was walking past anyway…”

The solution: The team whiteboard

By all means keep your data electronically, I do, but create a team whiteboard with the following basic items:

• The sprint burn down chart.
• The task estimates sheet (sprint view – used to drive the burn down chart).
• A pen to update the sprint view.
• The number of days remaining in the sprint – I print this big number on one piece of A4.
• Task cards, divided into 3 columns (or more) , Todo, In progress and done.

This “kills two birds with one stone” by providing a highly visible progress gauge to all team members and management AND allowing the team to easily update the board, either during the day or as they are walking out the door.

All that needs to be done by the Scrum master then, is to come in the morning, grab the estimate sheet off the board, update the electronic version and reprint that and the burn down chart, and off course update the “days to go” number.

“The daily scrum is for the team” is such a simple notion, but always hard to bring to reality. In most workplaces you are told who you report to – team leader, manager, director, board, shareholders. So when the first scrum is held everyone talks to the scrum master, as they are the boss. Whereas in Scrum the team needs to be their own boss.

Recently I started daily stand up meetings as the first step in the transition to scrum in my new workplace. Of course everyone reported the PM, which is great for the ego, but no good for the team. After a week of telling everyone “Don’t report to the PM, report to each other” I had got us to the same place we started at.

I found a stress-toy shaped like a rugby ball and decided to bring it to the next stand up.

When all were gathered I held aloft the ball and announced that we would now report to the holder of the ball, then threw it across the room to whomever was standing there. The result was nearly all of the team reported to the ball holder.

Currently we can’t hold the stand up without the ball. In the near future we should be able to hold stand up without the ball and actually report to each other. (Of course I am not the first to do this…check this out )

Since first posting this I have become aware of potential confusion over the term “Project Charter” which traditionally outlines the project – vision, purpose, success criteria etc. This is what we call a Project Definition in Scrum. What I am describing here would be better termed a “Team Charter” as it is focused on the internal working of one or more Scrum Teams. I agree with Diana Larsen who suggests that what I am calling the Team Charter and Project Definition are both necessary at the start of a project and should be well aligned. This is an important consideration to take to the team when working on a Team Charter whether it is a section of a bigger Charter document or physically separate but related wiki page (my preference).

The original post follows – updated to use the refined terminology. I recently used the template outlined here as a starting point for a Team Charter workshop that I facilitated. The team came up with a few more sections and points but I still think this is a good place to start.

As a servant leader-style ScrumMaster, it can be difficult to encourage team members to adhere to the sort of disciplined work practices that agile development requires. Part of a potential solution to this is to get the team to put into writing the work practices it agrees should be adhered to. Such a document is called a Team Charter.

An example Team Charter can be found here at Think Box. Although only a partial charter document mostly relating to development-level eXtreme Programming practices, the example here is a good starting point for a team developing its own charter. It covers:

• Working Practices
• Planning and Estimation
• Tracking Progress
• Test-Driven Development
• Continuous Integration
• Coding
• Iterative and Incremental Development

Teams using Scrum may wish to add a number of other Scrum-specific items to this list. A good source for this are the Scrum Rules at the back of Ken Schwaber’s second Scrum book. The following is a list of possible additions that I have put together including some items from this source as well as from Joseph Pelrine’s recent CSM course.

• Daily Scrum – time and place, alternatives to physical attendance, participation of chickens, late penalty, 3 questions only structure, follow-up discussions
• Issue Resolution – impediment resolution, requirement ambiguity resolution, sprint scope renegotiation
• Done – definition
• Testing – user acceptance testing process
• Sprint Review Meeting – attendance, structure, preparation, what can be presented,
• Sprint Retrospective – when and how instigated, action item follow-up
• Sprint Planning Meeting – attendance, structure
• Estimation – daily update, method eg. Planning Poker, tasks no more than 2 days

In facilitating a Team Charter definition meeting, a ScrumMaster might stress how choosing and adhering to a good set of work practices is about the team assisting itself in working as effectively as possible towards its sprint goals. Working smart requires some discipline but the pay off is what you can achieve without doing overtime.

Thanks very much to Joseph for the link and the advice on Chartering.

Something I meant to post about a couple of months back was Jason Yip’s excellent article on conducting effective Daily Scrums (otherwise known as ‘stand-ups’ in XP-speak). The article is titled It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings and is a must-read for all ScrumMasters. It came in handy when I was doing some Scrum training with Joseph Pelrine in February. It seems that English-speaking agilists aren’t the only ones who find this interesting as this article has now been translated into Japanese!

Thanks to “Richard Banks“http://richardsbraindump.blogspot.com/ for the recent reminder on this one.