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?

A quick walk around the ReadyTalk office might lead one to believe that we have stock in 3M. Our hallways look more like an elementary school than a software development company, but there is a business purpose behind our mass consumption of Post-It notes and construction paper:

We are Agile.

ReadyTalk’s Agile implementation started over two years ago with the Engineering team’s adoption of Scrum, which led to a more efficient development process and more engaged developers. Engineering’s Scrum practice takes a pretty text-book approach with seven small teams working in two-week iteration cycles. Work-in-progress is managed using Scrum Boards that give a real-time status for the current iterations.

It didn’t take long for other departments to notice its success. Marketing was the next team to move to Agile, customizing a scrum/Kanban hybrid model to fit their unique needs. Managing their work in-progress with color-coded Post-Its and index cards has given their team more visibility to what everyone is working on and why. Their manager says, “Taking an Agile approach to our projects creates a team consensus on priorities and how we are spending out time. Our work has become less silo-ed.” She also pointed out how the use of regular retrospectives forces the team to look back on what they have done so they can constantly improve the process.

The visibility that the process provided into Marketing’s work was apparent to other teams too; the Events Team and Customer Care Teams took notice. Both teams recently adopted a Kanban board to manage their internal projects that were historically lost in the shuffle of their day-to-day responsibilities. One member of the customer care team says, “Our team is more connected to each other and more knowledgeable about what our teammates are doing throughout the day. Due to the nature of support, we sometimes find ourselves tied down to our computers and phones with limited opportunities to collaborate with multiple colleagues at the same time. The daily scrum is our chance to physically stand in a circle together and get everyone on the same page very quickly.”

Agile is all around us here at ReadyTalk, but each team has embraced it and made it their own. While the details of each implementation vary, individual teams and departments have taken the basic principles behind Agile and hit the ground running. The “evaluate and adapt” methodology means that the each team’s process is constantly improving to meet their changing needs for agile flavor all that’s their own.

Is your organization using Agile? If so, where and how? What’s working? What isn’t?