Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Running XP
You're a project manager, so you know and love process; it's the people part that can be challenging. Running an XP will stretch your emotional intelligence (EQ), as it requires softer, more dynamic leadership than a by-the-book approach. Not that XP is all about soft toys and hugging trees; steering, guiding, and leading are the order of the day.
The leader needs to be more technical in XP than on a waterfall development—leading rather than managing, and focused less on status and more on big versus small picture.
Where's the Project Manager?
How to write a article on XP project management when there is no project manager in XP? I guess I should have come clean on that fact at the outset. Lack of courage, I suppose.
If XP is not about command/control but about a journey to solving customers' problems, leaders are needed, not managers. Going across the desert, I'd rather follow a leader than be constrained by a manager.
XP introduces the concept of a coach who is the primary facilitator of communication in the team. The coach knows where we're going—not in an absolute sense, but in a way that asks the question: Are we still doing XP? Doing XP means expressing the values and using the practices. Are we doing that? Or is there a breakdown in a pair of programmers? Could be technical, a personal conflict, or just too many onions for lunch!
The coach needs both strong soft skills and technical astuteness. He or she leads refactoring efforts at both a design and method level. From time to time he or she may be called upon to pair program.
Another, less exciting aspect of the coach role is to explain: "What exactly are those people doing in the conference room, and why are they sharing PCs?" A new approach as radical as XP can raise some upper-management eyebrows; you're going to need to explain the approach and be ready to demonstrate value. Value in XP is easy to measure: Customers get the functionality they want, when they want it. That's value.
Oh, another thing: If you're the coach, you better keep the snacks coming and get the team the fastest boxes you can find. I thought of a good use for your Microsoft Project box; you can use it to prop up your monitor.
Where Are We?
The role of the tracker is to gather metrics and disseminate them to the team. You need to decide what metrics are meaningful for your team (at that moment). Information overload with "number of methods that have fewer than 10 lines of code" or the like won't add any value, and important metrics will be lost in the haze. Keep the metric count low (less than 5), and definitely include something about the last build status, number of stories, and so on. We use the tried and true Post-It board for tracking throughput metrics. Yes, you can write a neat project web site to share the love. I've done this and it was great fun—pity nobody ever looked at it!
The message is clear:
Get metrics.
Make the metrics public, favoring simple tools (Post-It, etc.) over snazzy groupware products.
Check with the team to make sure that the metrics are valuable.
Keep the historical results.
All of this tracking, gathering, and Post-It note sticking should be done with minimal overhead. Think minutes, not hours.
How Fast Are We Going?
We have to have a way of knowing whether we're on track so we won't miss the release. Work rate or throughput is called velocity in XP. Speed with direction. With velocity, we're concerned not only with how fast we're going but whether we're doing the right things. We know how many stories we estimated for the iteration and their length to complete; using our past throughput, we can start to get a real metric-based picture of our work rate. There are many ways of measuring work. We use "Perfect Engineering Days" (PED); other XP-ers use "story points" or something similar. (We have factored in history and overhead into PED value.) The key point is that in your implementation you need to devise your own effort metric. This is good news if you're attempting to implement XP into an existing development framework; you can use whatever measurement the "process Nazis" have imposed from above!
What If the Customers Change Their Minds?
They will; that's okay. They can select new stories and redirect development. The only caveat is that the effort (PEDs, story points, and so on) have to fit within the timebox that has been defined for the iteration. There are technical issues to consider with inter-dependencies, but focusing on simple design can reduce these concerns. Your role as the coach (project manager) is to steer and guide the continual planning process. It may take a while to lose that twitch you get when you hear the word change; in the end, though, it will seem more natural to allow flexibility, and it aligns with your new XP values.
Are We Done Yet?
When is an XP project finished? When the team runs out of stories to implement, the funding runs out, or the customer changes direction and calls the work done. A weird side effect we've found in XP-ing is that the lack of panic at release time takes time to get used to. Development approaches that have few builds and long iterations tend to move into the chaos/panic realm at some point. This is not the case with XP. On the final day of one of our recent projects, the team just "went home" at 3 p.m., and that was that. If you want to tombstone the release event, you can. Like any release, it should be followed by the obligatory "wine and cheese" evening, or whatever you do in your neck of the woods to celebrate achievement.