In the project management world we take big projects and break them up into smaller pieces so they are less overwhelming to the people doing the work. This also makes it so we can track our progress. In Agile, we break them up into short iterations so we can create feedback loops to improve quickly. In traditional project management there is a lot of tracking and reporting. People are hired whose sole job is to track progress, report dates, and yell at workers for not hitting the arbitrary dates that someone else chose. In Agile project management, we try to do better. We try not to commit workers–we allow them to commit themselves. Instead of yelling at workers for missing planned dates, we tell them why the work matters and create a culture where workers buy in because they care about the project, the work itself, and not letting their teammates down. The tricky area when it comes to projects where people matter most is this: if we have a big project that we have to complete by a certain date, how do we know if we are ahead or behind of where we want to be? Think of it like a journey – if I’m moving across the country from Florida to California and I need to be in California by July 1st, I’d really like to know if I have time to visit the Grand Canyon or if I need to hit the gas a little harder. Because we don’t use many of the charting that traditional project management does, we need some tools to help us. But because people matter more than dates, we don’t want to risk our relationships with people when communicating if we need to speed it up. One fun way I’ve been experimenting with this was to stretch out the traveling metaphor much more than it should probably ever be stretched. My team was asking me explicitly: “We know where we have to arrive and we have an idea of how to get there, but how do we know if we’re tracking on time?” To help them, we did some high level estimation (t-shirt sizes) of every feature in the backlog. We are building a new foundation to an existing product, so we really have a pretty good idea of most of the features we are including. Once we had all of this estimated, we figured out how many weeks we had until delivery, and split the work into mostly equal parts. Here’s an example: let’s say I have 100 points worth of work in my backlog. If I have five weeks to get that work done, I would need to complete 20 points per week (20 points x 5 weeks = 100 points completed). If I have a week where the team only gets 15 points done – no biggie, try to get 25 done next week. If I have 2 or 3 weeks where we only get 10 points done, I become a little concerned and either adjust my dates or see if there’s any way I can help the team to try and get more points done. We have regular retrospectives to help us make sure we’re not slowing ourselves down. It’s my job as the team’s Agile Coach to communicate this information and make it visible so they can see for themselves how urgent it is. I don’t have to “create a sense of urgency.” If they care about the project and don’t want to let their team down, they will understand if things are urgent or not. Even more importantly, they will have ownership of that urgency, which they wouldn’t have if they just had a project manager yelling at them. The way that I am making the information visible to the team is through a treasure map that I drew on one of our windows. Each place on the map is a date and a few word summary of what we need to work on in that iteration. I split it into two week iterations. I also drew a speedometer, to show our current story points per iteration (in place of miles per hour) and an odometer to show how many total points we’ve completed. In that same area I have a release burn down and a sprint/iteration burn down, to show how we are tracking compared to how we need to track in order to hit our dates. Here’s an example of a burn down chart: The gray line above shows the ideal speed we should be burning up to be on target. The red shows where we actually are. Every time the red is above the gray, we’re tracking above target and every time it is below the gray line we are tracking below target. We now have several transparent ways to see how we are tracking towards our big goal. The team can see for themselves if we are behind where we should be, and they have a lot of ownership of the very important project we are completing. To create cultures in which workers can do their best work, it’s very important to give them the information they need to make the best decisions. Because they are closest to the work, they are the best decision makers. I hope you can use some of these tools to help your teams keep larger projects on track. If you need help through training or coaching, contact me at firstname.lastname@example.org. I’m a Training From the Back of the Room Certified Trainer and I’m passionate about helping teams meet their goals.
How are you visualizing your journey through change? If you have a story to tell, drop me a line – Jason.