Information Technology Dark Side

Tate Stuntz is a contributing editor to TechDarkSide.com and manages projects, services and methodologies for fun and profit. He can be reached at tate.stuntz@nimbleconsulting.com.

A while back, at a previous employer, I was very happy to have sold my first explicitly Agile project to a customer. I have to say, it was actually pretty easy. All the business people and project sponsors at the customer were on board right away. What happened next was the brutal part: selling it to my company’s internal methodology police. You see, not only was this my first Agile project (Agile with a capital A), it was the first for our consulting company.

We also had just rolled out our new consulting methodology and all projects had to execute under the new method. The first and most critical deliverable for every project was the Quality Assurance Plan. This was sort of like a RUP development case. The idea was to go through our immense list of deliverables, artifacts, and review cycles and identify how we as the project team were going to implement or execute on each and every line item OR (ominous music) why we thought that particular item did not apply to our project.

Now in all fairness to our method (which I will concede I helped author), at least we had a step like this; where Project Managers get to tailor a method to their project. Additionally, the Quality Manager and Engagement Manager on my project, who had to approve my QA Plan, tried to keep open minds and both worked hard to understand how my seemingly bizarre approach would fulfill all the required “check boxes” in our process. What follows are a few highlights of the check boxes I had to fill and how I satisfied those process requirements using Agile tools and techniques.

Requirements Management (RM) Plan

In sequential shops (which we really were, even though we used RUP artifacts), the RM Plan typically discusses the artifacts and procedures for capturing requirements at the beginning of the project. This included templates for use case models, stakeholder request lists, use cases and supplemental specs - all of which would be completed and baselined during Inception.

I was able to work this out on our project by using Scrum’s Sprint Planning exercise, which I called Iteration Planning to make it sound more “RUP-ish.” First, toward the end of each iteration (Sprint) I sat down with the Product Champion and re-prioritized the project backlog. The updated list went to the project team for estimation and commitment. I helped the team draw a line through the list where the items above the line would be in the next iteration and the items below would go back to the project backlog. The Product Champion got a final copy of the scope the team agreed to deliver for each iteration for final review. This scope list was “baselined” for each iteration and kept visible to everybody. During the iteration we’d work with the end users to detail the requirements for each item on the scope list. We list those out in very brief form in what we called a Use Case Realization document (more on that some other time).

Scott Ambler has a really good general discussion of this concept on his web site.

Change Management (CM) Plan

There’s a lot of stuff that can go into a CM Plan having to do with version control and release notes and things like that, but the real meat of a CM Plan on outsourced projects is the discussion of the Change Request artifact and procedures for updating the project budget and schedule based on a requested change. The great raw nerve that any IT consulting organization always strives to protect is lack of recognition and reward ($) for all the work that bubbles up after the initial scope and budget are supposedly set in stone.

Here’s what I was able to do: I said that we did provide an estimate, but it was based on the customer’s estimation of scope. Because we were not going to do a large, detailed analysis of the customer’s estimated scope, we could not commit to that estimate. However, because we were delivering actual working software each iteration, I would be able to track the actual effort, and thus the actual cost, required to deliver items from the project backlog. I would take this ratio, which of course I called velocity, and factor it against the remaining items on the project backlog. So, after every iteration the customer would get a special addendum to the status report that showed a forecast of the final project budget based on the velocity demonstrated to date and the number of items they had added to the backlog. My reviewers were very uncomfortable with this, but the customer had already agreed to it during the proposal process and so they let me go with it.

Code Reviews

We created a coding standards document, which was quite brief and to the point, and we required each developer to pair program with another developer for at least 2 hours on each use case they were responsible for. Both the owner and the reviewer in the pair had to sign the log. By signing, the reviewer was essentially saying that the primary developer had followed the coding standards doc, adhered to the architecture, and met the needs of the use case spec. No use case was to be moved into test and demonstrated to the end users until it had the code review sign-off.

Everyone griped about doing the sign-off, but nobody griped about doing a little bit of pair programming. In fact, as near as I could tell, all the developers spent more than two hours paired up per use case. So, I’m not sure why they were so irritated at having to sign something saying that they did, in fact, pair up. Anyway, this felt much more efficient to me than old-school Fagan-style inspections and it met the requirement that code reviews not only be done, but be documented somehow. The QA manager wasn’t very happy with a simple signature sheet; she was hoping to see meeting minutes and recommended revisions and acknowledgment that the revisions were implemented and things like that. I basically pleaded with the Engagement Manager and he let me do it my way.

There were some other interesting discussion points, but these were the ones where I really had to put ideas forward that were very different from the conventional wisdom.

Do you have any highlights of selling Agile to a customer or to management?

If you enjoyed this post, make sure you subscribe to my RSS feed!

Stumble it!