A new home for my blog

I've moved my blog! I'm leaving Agile Advocate where it is for now, but all my new posts will be at Propero Solutions.

Jira and GreenHopper for agile project management

I previously blogged about using Jira with some open source tools for managing agile projects, and concluded that it was not a great solution - without GreenHopper. I've been using the latest version of Jira with the GreenHopper agile plugin extensively now, and I like it. It is lacking some features, which I'll describe later, but here is an overview of the main functionality.

The first thing I like is the Planning Board view, which is aimed at Product Owners who spend lots of time ranking and re-ranking backlog items. The GreenHopper planning board allows you to drag and drop items to either change their rank or to move them from the backlog into a particular iteration or sprint (version, in Jira lingo).

Above: dragging a user story from the backlog to a sprint. (Click image to see it full-size.)

For the development team, GreenHopper's Task Board view is just that - it simulates the physical task board that so many co-located teams use. It's easy to drag the virtual cards to columns to update their status, just like you would do with a physical board. Very nice. It also does something you can't quite do with sticky notes; double click to see more information, or click on the item ID to see all the detail.

Above: The Task Board in summary view mode (Click image to see it full-size.)

Above: See more of the task board without scrolling - the List view (Click image to see it full-size.)

Above: Dragging a card from "To Do" to "In Progress"

Above: Double click to see this expanded view of any card on the board.

An advantage of GreenHopper over sticky notes on the wall is that your burn down charts are calculated automatically: in hours, number of items, and story points. The screen images below show these. The red line is the ideal burn down and the green line is the actual.

Above: Burn down in hours (Click image to see it full-size.)

Are you a bleeding-edge adopter of kanban? GreenHopper is decent for that. The columns on your kanban board are customizable, so you can create any columns you want. You can also set a WIP limit for each column. You can't, however, set up horizontal "swim lanes" for different service level agreements (SLAs), such as a row for items that need to be expedited.

Above: The column turns red when the WIP limit is exceeded

The Jira dashboard also offers a reasonable approximation of the cumulative flow diagram (CFD) that replaces burn downs in a lean / kanban process. It does show items created vs. resolved, but it doesn't graph items in-progress. The chart also counts sub-tasks as items, which you may not want.

Above: Almost a cumulative flow diagram. Close, but no cigar.

GreenHopper is an add-in to Jira, so you still get all of the Jira functionality unchanged. Like Jira itself, GreenHopper is extensively configurable; almost annoyingly so because there are so many options it's hard to know what to do with them. Fortunately the default configuration is reasonable, although there are some setup steps required to enable item ranking, which is so fundamental that it should have been done out-of-the-box.

What is it lacking?

1. If you're a large organization with a portfolio of inter-related projects, Jira + GH doesn't do much to show you the big picture across multiple projects.
2. Although you have a hierarchy of versions, such as a release containing multiple sprints (described here), it doesn't do much; the planning board simply indicates that one version is a "master" of the other. GreenHopper doesn't offer a timeline view showing the version hierarchy.
   
3. You can create a hierarchy of backlog items, for example to have large-scale epics that contain many user stories, as described here. However, this feature isn't enabled by default and requires an adminstrator to configure it. As an alternative, or in addition to the "epic" feature, you can create associations between items for this purpose, but there is no easy way to visualize the relationships. There is free task hierarchy plug-in that will show the hierarchy, but only for one top-level item at a time. 
   

Overall, especially for smaller teams without portfolio management needs, I give the tool high marks.

Definition of Ready (DoR)

All good agile teams have a Definition of Done (DoD) - the common set of criteria that every feature must meet before it's considered complete. I wrote about the DoD previously in this post. But what about a Definition of Ready? How do you know when your backlog items are ready for the team to accept them?

Serge Beaumont spoke on this topic among others at the 2009 Scrum Gathering in Munich in his presentation Practical Tools for the Product Owner: Focus, Value, Flow. He describes the Definition of Ready as a negotiation between the Product Owner and the team, where the team ultimately decides if a backlog item (user story) is defined well enough for the team to estimate and implement. His checklist for the DoR for backlog items includes:

• Why? Business Value
• What? Outcome vision
• How? Implementation strategy & cost
• Does the backlog have enough items for 1 and half to 2 sprints?
• Is the size (granularity) of the backlog items acceptable?

I would personally aim for a smaller number of items in the "ready" state; 2 sprints worth of items increases the risk that time will be spent analyzing items that end up in the trash heap.

Serge also advocates using a kanban board with 4 phases to track the readiness of backlog items:

• New
• Preparing (going through analysis)
• Ready
• In sprint

I'll be adding the DoR as a standard part of my Scrum implementations.

SourceMonitor for .NET code quality metrics

A tip of the hat to Paul Rayner for recommending SourceMonitor for .NET code quality metrics. I gave this freeware tool a spin today on a C# project I'm working on for a large client, and was very happy. It's easy to use and within a few minutes I had it installed and ran the analysis on the whole project, gathering these metrics for the whole solution, and for each C# file within the solution:

• number of statements
• methods per class
• calls per method
• statements per method
• average and maximum complexity
• average and maximum block depth (number of levels of indentation/curly braces)

This is a great tool to quickly find potential problem spots within the solution, so you can identify the components that would likely benefit the most from some refactoring and additional testing.

Agile vs. Waterfall: The NetFlix analogy

The following is a fable to compare traditional waterfall projects to agile/lean projects...

---

Announcing my new movie rental service, NetPix! Here's how it works.

• You get 60 movies each year, delivered on DVD in the mail.
• When you first sign up, choose 60 movies you want. When you finish choosing your movies, we'll confirm that it's really the list you want.
• Over the next 12 months, NetPix will tirelessly collect your 60 DVDs, and at the end of the year, we'll deliver all 60 movies to your home!
• Price: $60 per year (just $5 per month!)
  

The fine print:

• DVDs will be delivered 12 months after you complete and confirm your list of 60 movies. 
  
• After confirming your movie list, any changes you make to the list in the first 6 months will incur a charge of $2 per movie. 
• Any changes in your movie list during months 7-12 will result in a charge of $3 per movie, and a delivery delay of 1 month per movie changed. (We have to lock down the list at some time, after all!)

---

Now suppose I order, say "Weekend at Bernie's", both I and II, on the advice of my high school buddy, Steve. A year later, I watch "Weekend at Bernie's" (the first one), and I hate it! Steve usually has good taste, so I trusted him, but he must have been smoking crack when he recommended this one. I don't even wanna watch "Weekend at Bernie's 2", but I already paid for it and it's sitting in a cardboard box next to my DVD player. Damn!

And to top it off, eight months into the year the studio released a remastered, Director's cut, collector's edition of my all-time favorite movie "Blazing Saddles", with never-before-seen outtakes! If I want that it'll cost me an extra $3 (5% more) and I'll have to wait an extra month for all of my DVDs! Double damn!

Would you buy this? "No," you say? Well why not? This is the way software customers have been buying software for decades! Customers have to figure out everything we want before we even start working on it, and they can't change their minds later without paying dearly for it!

Alas, much to the chagrin of NetPix, along comes an upstart disruptor, NetFlix! Now customers can get the features (DVDs) they want every month instead of waiting a year! And they can change their priorities (movie list) at any time! And they can watch "Weekend at Bernie's I" before deciding if they want to invest 90 irrecoverable minutes of their lives watching the sequal. The demise of NetPix is written on the wall!

More tips for better retrospectives

At last night's Agile Denver meeting, I facilitated an open space discussion and one of the topics was conducting more effective retrospective meetings. The group had some great insights and advice that I'd like to share here. Thanks to everyone who participated!

1. Rotate responsibility for facilitating the retrospective. Get fresh perspectives and creative ideas. Don't let it get stale.
2. Hold your retrospective over a happy hour.
3. Read Agile Retrospectives by Esther Derby and Diana Larsen
4. Instead of asking "what were the problems", ask "what could we have done better."
5. Follow through with an action plan. If you have lots of improvements, rank them and work on the top priority issue.
6. Have a virtual buyer/seller transaction at the end of your iteration to determine if stakeholders are willing to "pay" for what you delivered.
7. Do shorter iterations - fewer issues to discuss
8. Set the stage with expectation that it's not about blaming. Participants must describe the effect of the problem, not the person they believe caused the problem.
9. Take collective team ownership over problems. It's the team's job to help every person on the team.
10. Start the meeting by having participants write issues on cards, then post them on a wall and group them. This can effectively elicit input from shy people who are hesitant to speak in a group.
11. Ask creative questions, like "if this iteration were a car, what model would it be?"
12. Keep a retrospective board where team members can at any time write down issues they want to discuss in the retro.
13. Is there an elephant in the room that nobody wants to talk about? If so, get it out!
14. End on a positive note. Everyone must say one positive thing.
    

Open source agile project management tools

I authored a comparison of five open source agile project management tools: Agilefant, IceScrum, Agilo, eXPlainPMT, and XPlanner. The article is posted on Open Logic's Wazi site. I welcome your feedback!