Wednesday, February 22, 2012

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

Wednesday, February 15, 2012

Agile's perspective on failure

In the fall of 2011 I did some research regarding agile and failure for a presentation at Much Ado About Agile 2011 in Vancouver. The research was focused by a blog post by Philippe Kruchten describing some of the agile elephants. He listed "commercial interests censoring failure" and "using Elitism as a defense (against failure)" as two of the elephants. I consulted my brother-in-law Dr. Jason Ediger who is a psychologist to learn a bit more about the psychology of failure. After a brief explanation of what agile is, he responded with this:

"The assumption of failure is built into the agile process. The traditional method is built on the presupposition that we can plan failure out of the process. We don't have to test for it because we've taken everything into account. Agile assumes that humans are going to fail. By it's very nature, agile can't ignore (or censure) failure. If the accusation is that agile suppresses failures, then by definition - that is not agile. If agile is done properly then it can't* fail because it tests for failure all along. If you suppress failure, you guarantee it. Agile has a different perspective on failure. It doesn't see failures as catastrophic, but as expected. That difference in perspective allows us to celebrate failure rather than suppress it."

Pretty interesting comment don't you think?

Agile tests for failure all along in order to succeed. We aren't hoping for, or even planning on failure, but we do test for it regularly by delivering frequently, having daily stand-ups, keeping project status visible, etc. We do all this so that we can discover and react to our failures quickly in order to succeed.

Subscribe to Winnipeg Agilist by Email

Friday, February 10, 2012

Agile is simple but not easy: advice for agile beginners


As we prepared for yesterday's user story mapping session at Agile Winnipeg, Jon Labun and I reflected on agile stories that we've been a part of or heard about. A common theme emerged - agile is simple but not easy. We touched on this in the presentation and argued that user story mapping should be a central part of your agile practices in order to make many things 'easier'. Many agile stories start off well with organizations and teams wanting to give agile a try, but then fail to put in the investment to understand what being agile is about. The teams assume that agile is simple but lack the knowledge of how all the pieces fit together and end up running a project that is just an agile facade - agile words on the surface, but traditional methods (or no methods) underneath. It isn't the fault of agile that the projects end up in trouble or fail. 

Some common problems:
  • Unending backlogs that are hard to visualize and prioritize
  • Definitions of done that don't include testing & deployment
  • 20 page requirements documents for one user story
  • Incorrectly assuming that agile means 'no planning'
  • Planning at the task level vs. the story level
  • Testing after development is done rather than throughout the project.
  • Out of control scope
  • Out of control change management
  • Never ending projects
  • Significant quality issues
  • etc
If you are beginning your agile journey then welcome to the club! It can be a lot of fun and very rewarding. But please, please, don't start without gaining some knowledge first. The agile community has a good head start on you and can help you through some initial hurdles to make your 'simple' journey a little easier. Please do read some articles and books, listen to podcasts etc, but your best learning will come from interactions and conversations with others who are further along the journey. Here are two important pieces of advice for you:

1) Find your local user group and support it with your attendance. Bring real questions and ask the group to help you find some answers. If you are in Winnipeg, visit www.agilewinnipeg.com. If you are elsewhere, consult the Agile Alliance's list of local user groups.

2) Attend conferences. Many of the successful agile teams I know point to ideas and practices they learned at conferences as crucial steps in their organization's agile journey. But don't expect to only 'attend' sessions - plan to interact with the audience and speakers during the sessions and also over lunch, dinner, drinks, or even indoor sky diving. There are several great conferences you can attend, but I'll highlight one in my region - PrairieDeveloper Conference in Calgary, Alberta from March 12-15. Regardless of your location, this is a can't miss conference with 80 sessions + full day workshops. See you there?

To paraphrase Mike Cohn, the agile community has helped me up my game - now up yours.

* P.S. Prairie Developer Conference is more than just agile of course, bring your whole team, your IT pros, your managers, etc.