My team today had a very fruitful, but long, “Planning Game” meeting today to do sizing on our next project release. I admit it, I don’t particularly enjoy the rigamarole around the planning game and the whole iteration planning/close/track your velocity overhead junk. I got a really bad taste in my mouth from my first XP project because the project manager made the iteration kickoff and retrospective meetings nothing but sheer torture. It used to really bug me that I had to spend an entire afternoon being pilloried by the project manager for poor team velocity instead of coding (a really good way to improve project velocity). Later on in the project we had some other personnel come in who had more experience with Agile projects and they helped us straighten out our project management and eliminate much of the misery. I soon started to understand the value, or possible value, of many of the overhead activities that I had previously blown off. A couple pieces fell into place in my mind about Agile processes that continue to amaze me to this day.
- When applied intelligently a modicum of process can actually be valuable. Process and discipline doesn’t have to automatically equate to “useless document that nobody reads until it’s hopelessly out of date.”
- A project’s process goes a lot smoother when the team actively adapts the process to their (changing) situation.
- You and I and everyone else on the team is responsible for making the adaptations to the process. We don’t have to be stuck with a stupid unnecessary process. We can eliminate processes that don’t pull their own weight. We can add processes when we observe a lacking in the way we are working. Just to head off an obvious objection, you are obviously constrained by what the other teams you interface with are doing.
On paper there does not seem to be much process involved with an Agile project compared to heavy document-centric processes, but what is there needs to be followed consistently with something resembling discipline. One of the cool things about Agile is putting the emphasis back onto people instead of processes. An essential tenet of Agile thought is that teams are expected to actively and regularly change their process. It’s important on an Agile project to constantly reflect on how you’re running the project. One of the most important lessons for Agile software development I’ve learned is to pay attention to what you’re doing each and every day.
Another thing to keep in mind is that an Agile process purposely blurs the boundaries between project roles. My goal on a project isn’t just design and coding, the team‘s goal is to deliver working software that doesn’t suck. With that in mind, I’d urge all of us developers not to blow off the project management stuff in an XP or Scrum project. Here’s a rundown of some of these activities and why and how I think they’re important to developers.
Release Planning (The Planning Game)
At the beginning of a release cycle, get the team together and review the story list (high level requirements). The developers will get a chance to provide high level estimates based on the explanations of the requested features. These high level estimates will be used to generate a rough release plan and maybe a hypothetical iteration list. In order to estimate the stories the developers have to talk through possible solutions. Release planning is important because it helps create an expectation of the project completion date. The value for the developers is that it gives us a chance to start understanding the problem domain of the project and begin to develop a common vocabulary with the business folks. One of our lessons learned from our first project with my current team was the lack of a release planning effort. I know that I made some decisions that led to project inefficiency because I didn’t completely grasp the sum of the project goals and scope. From our marathon meeting today I walked away feeling like we had made an important first step towards getting our arms around the new system infrastructure to be built.
The whole “lessons learned” thing – what worked, what didn’t, what should we change. Take this seriously or you’re damned to repeat the same mistakes and never improve. One of the things I like best about my job is that we actually do make improvements in the way we execute projects so that we can stumble into completely new problems.
At the beginning of an iteration the team gets together and talks through the candidate user stories for the iteration. This varies quite a bit from project to project, but here’s roughly what we’re doing. The developers will task out the user stories in enough detail to make an estimate for the story that isn’t completely fantasy. The act of tasking together is essential. I’ve never seen anyone write this down anywhere, but the tasking exercise is one of the best platforms for creating a common technical vision between the developers and fostering communication between the developers and the folks managing the requirements. Tasking is design masquerading as an estimation activity. At the end of an iteration kickoff meeting every developer should have a basic understanding of the technical work for the next couple of weeks. I’ve seen projects do pre-tasking meetings before iteration kickoff to break up the work into more easily digestable chunks.
Take the estimating exercise seriously. On one hand, it gives the project managment and senior management types information to adjust expectations according to the rate of progress. On the other hand, decent estimating keeps us developers from being overworked. That whole sustainable pace thing is kinda nice. In my waterfall days there always seemed to be a binary switch from “working half-heartedly on planning documentation” to “working way, way too many hours.” I think one of the best ways Agile improves productivity over the long haul is by spreading the work more evenly over the course of a project.
Make the iteration kickoff meetings as brisk as possible, but no shorter. These meetings can drain the life from all participants if you are not careful. Consider it a valuable and necessary evil and get it over with.
Iteration Close (Retrospective)
It’s important to timebox your iterations. Having a brief meeting at the end of an iteration helps to enforce the rhythm of the iterative coding cycle. Use your iteration close meeting as a way to get the entire team to talk over how the project is going. Take a short break from the day to day minutae of the project and look at the big picture. What are we doing that’s working? What’s not working that we should change? What are the project risks and how do we mitigate them? Where are we going to lunch? How can we make the iteration meetings shorter and our estimates better? This is your chance to effect positive changes in the execution of the project. Do things like look at your bug history and try to spot trends or compare story estimates against actuals to improve your estimating.
Stand Up Meetings
Most Agile teams have a short standup meeting in the morning. The ostensible purpose is to go around in a circle and have each person (or just the developers on some projects) talk about what they’re doing and bring up any blocking issues or ask for help on a task. We use the Scrum burndown chart to track remaining hours in the iteration to get a feel for how the iteration is progressing and track velocity. I like to have a brief bug report from the testers as part of the standup myself just to keep the developers and testers on the same page. I’m pretty absent minded about updating my stuff on the burndown so do as I say, not as I do
Don’t ever let stand up meetings take very long on a regular meeting. It’s more or less harmful for a long-winded project manager to dominate the meeting as his or her daily pulpit. The standup is about the team communicating and collaborating. I think that the general mental health of an Agile team is easily measured by how miserable or how smoothly standup meetings go on a daily basis. Make the standup be a net positive for the project team.
Yes, you can sit down in a standup as long as you’re listening (I’ve got a prematurely arthritic knee so of course I sit). The original impetus for it being a standing meeting was to insure that the meeting was short.
I have no business explaining project velocity to anyone, so check out these links:
Basically the concept is to measure the team’s ability to deliver user stories in an iteration in order to predict the amount of work a team can accomplish in upcoming iterations. There’s a wide variety of velocity tracking philosophies and mechanisms, some of which are seemingly designed to flay developers alive. The finer details of how this is actually accomplished is more or less a mystery to me. I’m an ex-engineer and the embarassly unscientific nature of Project Velocity compared to the project controls team on a construction project bugs me.
My only real advice is to make the team as whole familiar with the mechanism for measuring project velocity. Again, taking project velocity seriously (do put an effort into your estimates, do track the actual effort for a each story in some fashion) helps the project manager set expectations and priorities while keeping developers from being overworked.
Non-story work like maintaining a build process, creating Wiki documentation, and minor refactoring work is not estimated because it is assumed to be a fixed ratio to the effort related to story work. This leads to the saying “We’ll just let Velocity handle that.” It’s kinda like a golfer telling another golfer to “just pick it up” on a 6 inch putt. A joke between my boss and I is to say “we’ll just let velocity handle it” anytime we don’t know how to estimate something.
A practice I really like in doing team estimates is to “throw” estimates. I think it encourages a lot more participation and discussion between developers without bogging down. We did this today in our release planning meeting and I thought it went well.
Of course, I have a lifelong habit of generally ignoring and disparaging project management in general so let’s not even pretend that this is a remotely complete list on how to manage an Agile software project. I’ve also never been on any two projects that did iteration management the same way.