MARTYHAUGHT

Recently, several things have occurred that have brought my attention to how you plan an agile project. Before I get into the specifics of my current situation let me give some background. I was introduced to agile development in 2004 on a project was pretty close to pure XP. We had two years to experience a fairly smooth agile project, including over a year where part of the team was remote. During this time I explored deeply the aspects of agile development as well as other important parts of the XP equation (DRY, refactoring, TDD).

In the last few months, things have gotten more challenging on two of my projects. One is an agile project that has recently added many new team members with no prior agile experience. The other is not an agile project and I’m only one piece of a large coordinated effort. Two other pieces of this puzzle have drawn me to blog on this topic. First, I started rereading Planning Extreme Programming by Beck/Fowler a couple months ago. Though I have been practicing all these points for the last 4 years, it’s been refreshing to review what they wrote back in 2001. What is beautiful is that the simple concepts they cover offer solutions to the struggles I’ve experienced recently. The other piece is a series of blog posts by “Obie Fernandez”, especially his latest in the series.

Planning is a crucial step in software projects. I’ve seen it too formal, too lengthy, non-existent, you name it. My experience with agile has been the best planning I’ve seen. It’s thorough, concise, timely and gives me enough guidance to get rockin on code. It’s hard to imagine a process that is more efficient. The IPM, Iteration Planning meeting, is the most important part of planning in my experience. Doing a release plan falls largely into the same type of event so I won’t treat it separately. For those of you not familiar with agile an iteration is a short time period (two weeks, in our case) where we work on a finite list of features (stories) that should all be complete by the end of iteration. Everything is fully tested, integrated and ready to roll out to production when it’s done.

Several pieces go into making an IPM successful. Collecting and writing good stories is an important pre-cursor to this meeting. Without that an the IPM won’t really be complete. It’s also important to have your development team be familiar with the process but by in large what is most vital is the presence of the customer. By this I’m referring to some representative of the business side of the client and one that is knowledgeable about the domain as well as empowered to make decisions. Their role is fairly simple, discuss the stories with the development staff and prioritize what will be done which includes pushing out stories that do not fit into our time box.

So what’s the big deal about having the customer there? In XP circles, the IPM is a dialog about what stories the customer would like done this iteration. It’s a chance for the developers to ask questions and discover what the essence of the story is. By nature, the story should be too brief to be comprehensive. It should just be enough to capture the business value of the story but not too much more. This requires the dialog and allows both sides, development and business, to come to an understanding about what the story is about. Ideally several things get identified: the importance of the story, business value and how it relates to the application, its priority to other stories, technical risk involved and level of effort to get it done. This dialog can be so efficient as there’s no middle man, no long emails or other forms of communication/documentation that can be misunderstood. Both sides continue discussing until they are satisfied. How perfect is that?

What I didn’t realize, after taking this for granted for several years, is what happens when the customer isn’t present. More effort has to go into gathering requirements and trying to capture what the developers need to know. More meetings and rounds of communication have to ensue when all questions/requirements weren’t imagined before the developers looked over the story. I don’t believe I have ever seen a case where everything we needed to know was gathering up front. XP is about discovering this in an organic process. Ultimately time slips by and it ends up wasting more meeting time for everyone. This is really obvious when a misunderstanding spans 3+ rounds of communication. I know those involved are frustrated with the process as they keep exploring ways to solve it. What I find interesting is that the simplest solution of just having the customer show up to the IPM would actually solve the issue. I’m pretty sure it’s also the most efficient use of everyone’s time as well.

Obie actually puts this requirement into his MSA which I think is brilliant and vital. I know I’ll be more clear on this as a requirement for future projects. My second, non-agile project is a prime example. For nearly a month I was stating what simple things I needed to get started on my part of the application. It was documented in a large meeting that included several project managers, various executives from different parts of the business as well as the slew of technical staff that needed to coordinate on this. Week after week I waited for my requirements and what I needed to succeed. I did get some of them but other parts weren’t delivered in a timely manner. What’s worse is that there was a fundamental misunderstanding on what was possible and what was desired. Neither side knew because there was no dialog. Finally, about two weeks before the due date, the weekly meeting was dominated by this one aspect focusing on one of my deliverables. Luckily we broke out of the normal project management flow and just went into a conversation about what they wanted and what could be done. Ideas started flying and I clarified what could be done and at what efforts. In less than 30 minutes we figured out all the things I had been asking for nearly two months earlier.

For me, all of these things together has just cemented how important this simple concept of a dialog between business and technical needs to happen. It’s not just once a quarter or at the beginning of the project. It’s something that should be ongoing. Once every two weeks for a couple hours seems pretty balanced to me. Ideally I’d see a release planning party that covers all the top features that will make up the release. High level estimates and prioritizing occur and the stories get shuffled into iterations. After that point you have IPMs to hone the scheduled stories until the release is finished. I’ve seen it work and I’m totally sold, especially after seeing it not work.

blog comments powered by Disqus