As geeky as it sounds, I love learning. When I was first exposed to the world of organizational learning back in the 90’s, I picked up a couple of handy phrases that I chant on weekly basis:
- Learn – Teach – Learn
- No Theory, No Learn
These phrases capture two of my mental models on organizational learning. Mainly that it is an iterative cycle, only comes through sharing, and requires reflection and measurement on your theory to learn. With that in mind, we frequently open our doors to our customers to Learn and Teach. They observe our stand-ups and planning meetings and we discuss how Agile development has infiltrated not just our development team, but our entire business. I always try to ask them – “What is your Theory?” before they come.
Creative Commons Kathy Sierra - Click to view her blog post on the topic
What’s Your Theory?
Many organizations are simply happy to take the first step toward the smooth and continuous flow of Agile development. But what I love about working with many of our customers like Pinnacol Assurance is their desire to go beyond amateurism, what Kathy Sierra shows as the road to becoming an expert. Amateurism is not enough; they want to become experts by fully adopting Agile throughout their organization and through a continuous improvement process.
At our last release planning session in April, members of the Pinnacol’s IT team participated right alongside our internal team. Wednesday of this week, members of Pinnacol’s leadership team shared in our company-wide rhythm of daily stand-up meetings, rotating through a variety of stand-ups from the dev team to IT to marketing.
How about a Learning Journey?
The goal of their trip was bringing mental models from outside of Pinnacol into their organization. I love that approach and it’s one we use ourselves at Rally. If we see a company doing something particularly well – whether it’s supporting their customers or hosting an out-of-this-world event – we ask to visit their company, shadow them for a day or two, and get first-hand knowledge of their success. It’s one of the best ways I know to quickly learn a model in a very hands-on way and almost immediately translate that into success at your own company – all without reinventing the wheel. Otto Scharmer who developed Theory U calls these trips – Learning Journeys. They are the first step to help you see what you do not know and getting you to open up and learn as a team.
Pinnacol has been very successful at attaining the benefits of Agile in flow inside of IT, but they are already looking above and beyond. They brought business representatives and operations leaders to share and learn about increasing agility in a larger, enterprise-wide context. I am really looking forward to hearing more about Pinnacol’s path to fast learning. You can read about Pinnacol’s adoption of Agile and Rally in the case study.
In this post, I’d like to comment on a request from a Rally client I recently visited. Their tool request? A burndown chart for each individual. We were in a small meeting and my intent had been to help them with their Agile adoption. “No, Jean, it is your Rally tool that is the problem.” Hmmmm. Let’s take a look. What seems to be the problem? “Your tool is not helping our ScrumMaster and management team track individual team members’ burndown during the Sprint. We absolutely have to have that.” Huh? I had to call foul and get the group to step back and talk about “What’s in a burndown chart and why?”
Individual team member tracking in a burndown chart is a bad smell. It suggests that the commitment made in the Sprint Planning meeting is not a team commitment. It also suggests that the management is not tracking value delivery, but rather team work. I dug further with this group about that. Each individual at this organization was expected to commit exactly to the number of hours any of their tasks would take, and stick to it. That commitment was meant to never change. If a team member was “taking too long” (which they claimed could only be known via individual burndown charts), management would then be able to “do something” about it. What happened to the Daily Standup for team check-in? But I digress.
Tracking in a burndown chart is meant to trace team commitment around the valued items it intends to deliver. At the end of the Sprint Planning meeting, it reflects the team’s initial estimate of effort to achieve that value delivery. During the Sprint, the burndown chart reflects daily, “Are we going to meet our commitment to delivering this value? If not, what is the single most important, the highest priority thing we must do today?” Finally, the burndown chart informs the Sprint Demo and Review about what happened with the team’s commitments to value delivery versus what they were able to complete.
What’s in a name? Well, when it is a burndown chart, there are three things:
- charting the initial Sprint Planning meeting team-wide commitment to the valued items the team can deliver in a timebox
- prompting the daily inspection of what is the most important thing the team must do today to meet that commitment
- informing the the team at Sprint review to evaluate how the team’s estimates and commitment compared to what value the team was able to deliver
About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.
Every day, the Agile Project team meets for a short status meeting. The purpose of the meeting is to ensure that team members are aware of what others are working on, and to provide visibility for delays and obstacles. Each team member tells the others:
- What they have been working on since the last standup
- What they intend to do today
- What obstacles are standing in their way
The ScrumMaster takes notes on each team member’s obstacles.
The Daily Standup Meeting is for status only, not discussion. If a team member wants to discuss something, they can propose a discussion in the future. For example, “I have some ideas for how we might do X—does anyone have time to talk about this today?”
Daily Standup Meetings are primarily for the team. The Customer and other stakeholders are encouraged to attend, but they aren’t allowed to speak.
The Daily Standup Meeting should be no more than 15 minutes. If all of the participants stand (rather than sitting) the meeting is over much more quickly. It is the responsibility of the Facilitator to ensure that the meeting stays on track and is over quickly.
RallyDev.com
