Agile Chartering - an Agile Documentation Alternative

Last spring I wrote two posts about agile documentation (Part 1: Introduction and Part 2: Guiding Questions) and asked you to consider this statement: 

"A document isn’t the only vehicle for expressing or transferring good thinking and ideas."

Recently I coached a team that was converting an application from VB6 to VB.Net. One of the challenges of the project was to agree upon and define the rules for when to fix the old code, when to just get it working, when to re-write whole sections, etc. One method to gain agreement on this approach could be to schedule a series of meetings and write up the conversion rules and strategies in the project charter document. Here is what we did instead:

Using a variation of the silent brainstorming technique we spent about 20 minutes creating a light weight conversion manifesto we could all agree upon. As you can see, we had some fun when we named the groups. The manifesto was 'documented' using an easel pad, post-its and sharpies. We placed it on the wall in the team room and referenced it often throughout the project. Situations we could not have documented up front surfaced during the project and were discussed quickly while referencing the post-its. This light weight manifesto served as a great vehicle for expressing our good thinking and ideas.

A meeting and a word document could have accomplished this as well, but not in the same amount of time, with the same effectiveness, or with the same mirth. In addition this is a great team building experience for teams that already have enough experience with long meetings and longer documents.

For more ideas on how to streamline your project chartering, take a look at this new book by Diana Larsen and Ainsley Nies: Liftoff: Launching Agile Teams and Projects

---

FYI - here is a quick explanation of the manifesto:

Image Via ThunderBoxRoad.com

"Hold your nose, just get it working!": Yes, the existing legacy code isn't beautiful, but it works and the users are happy with the functionality. We focused on delivering the functionality as is without any modifications unless absolutely necessary. (see “If you have to pass gas, fess up”). This included ignoring existing known issues and defects.

"If you have to pass gas, fess up": In the rare occasion that code or design must be changed, you must discuss and gain agreement with the team before doing so. Any issues or resolutions that come up must be shared with the team.

“Don’t paint the outhouse”: We are going to be making changes to the application after we deploy the .Net version so there is no need for a fresh coat of paint at this time. No UI "clean-up" is allowed except for minor formatting issues and we won't do any re-factoring unless absolutely necessary.

“You can’t get out of the mob unless you get out of the city”: We used VB Migration partner to do the initial conversion to VB.Net. The tool was a big help to speed up the project but some of the converted code is a little ugly and the team wanted to dive in and fix it all right away. If we were to focus on fixing the ugly code now it would not deliver value to the user – just less ugly code. So we put our focus first on converting the code and getting it live (i.e. getting out of the city) so that we could leave the mob behind in later projects as we replaced parts of the system.

Subscribe to Winnipeg Agilist by Email