During the past few months, we have recognized a growing need for a way to connect with other engineering teams using scrum. The Agile community in Denver is well served by user groups, like Agile Denver and training offerings from Rally, but we wanted a way to ask very specific questions to other scrum practitioners in the community and discuss practical solutions…so Scrum for Breakfast was born, or should I say baked?

We get other ScrumMasters and Engineer Managers from local companies together once a month for breakfast to talk about the details behind what’s making scrum successful within our organizations. Sometimes we tackle what holding us back. Sometimes we discuss the weather. Sometimes we drink Snooze flat out of coffee.

The group is small and follows scrum principals of 5-9 people, so we can get the most out of the conversation. The attendees are individually invited based on the topics and past conversations. The format lacks any real structure, and we have found that this loosely organized approach allows us to cover a variety of day-to-day scrum issues and solutions. Sometimes the conversation will completely shift gears based on information offered up by a contributor but everyone walks away with new ideas and approaches that can be implemented right away.

Our first month’s focus was around the tools that we use to manage our scrum process. Some teams use software, like Rally or VersionOne, while others use an analog system of white boards and stickies. Here at ReadyTalk, we use a combination of both systems. What we quickly learned was that no matter what each team used for tracking their tasks, the communication within the team was much more important. Teams that were most successful were aware of what their team members were working on before their daily stand-up and with out logging into any software: they simply talked to each other. Tools won’t make a team talk to each other, in fact- relying too much on a tool might make your team members talk to each other even less.

Tools, both electronic or analog, are also used to communicate status to people outside of the scrum teams. We discussed what metrics are important and to whom. One participant asked the question about what the numbers we share really tell people reviewing them. We shared our feedback about tracking and publishing metrics and were all in agreement that it is often difficult to interpret the metrics of a single sprint (in our case two weeks) with out the context of what went on during that iteration.

What methods are you using to track your work? What do you communicate about your progress to people outside of your teams?