Apr 14

Agile Atlanta – 4/11 meeting notes

I was the speaker at the April 11th meeting, but instead of lecturing, I thought it would be more interesting to have a roundtable discussion on the following topics:

  • Are backlogs waste?
  • Who owns Scrum?
  • What are good metrics for agile projects

We had a pretty good turnout, and some interesting ideas for future meetings – specifically a discussion of how people vary the practices of the agile methodologies for their own organization.

Are Backlogs Waste?

This was brought up on the Scrum development Yahoo group.  The general consensus locally was “no, of course not”, so I felt obliged to take the contrary position to get some discussion going.  Lots of good pro-backlog points were made:

  • If you have more ideas than you can handle, you need to write them down
  • Backlogs represent a “warm blanket” for the customer
  • Backlogs are a critical buffer/shield for development, to keep them from getting interrupted (You want that feature?  We’ll put it in the backlog)
  • Some think the name is bad – instead of calling it a “backlog”, call it “Planned Features” (Jira does this, apparently)

Some anti-backlog points:

  • If the backlog grows beyond some point, it becomes ridiculous, and undermines morale
  • Customers may become cynical or jaded if their needs are buried in the middle of a huge backlog
  • Providing estimates and tracking complexity on a large backlog is waste if those items will never realistically be worked on
  • A large backlog can be intimidating to the team and to the customer.  If it’s intimidating, it probably isn’t agile

The lukewarm consensus was that a backlog needs to be segmented informally into “likely to be worked on” stuff and “unlikely to be worked on” stuff, to help mitigate the waste.

Who owns Scrum?

I specificaly used Scrum for the discussion, but the problem could just as easily be applied to XP.  The main point of debate was “Should Scrum (or XP) be controlled by a single person or a small group, or should it be left alone to be freely interpreted”.

  • Someone suggested that Scrum and XP be turned over to ISO for formal standardization, to a bunch of laughs.
  • Some feel that RUP’s strong ownership actually stifled it, and kept it from being applied more broadly
  • Someone pointed out that by tweaking the process individually, we are demonstrating that it isn’t really owned
  • This caused a further discussion on whether ownership meant “no changes allowed” or more broadly, “no one else can call what they do Scrum”
  • Someone raised formal certification – like ScrumMaster certification – is it a good thing?  I personally think it is – it gives more “heft” to the opinions of people who are certified, versus people who “read a book” on XP and then declare themselves experts (as an example).  Formal certification can’t really happen without ownership.

The best Agile Metrics?

We discussed the attributes of good metrics – they are hard to manipulate, they are timely, they are correlated to the task at hand and they are consistent over time.

  1. Running, Tested Features
    • This is Ron Jeffries’ concept, and it is fairly hard to manipulate (assuming the person who decides which features are in an iteration is independent), but it isn’t very timely.  It is very well correlated to the task at hand, but it is only moderate on consistency over time
  2. Story points
    • Easily manipulable, but very timely and well correlated.  It does suffer from conceptual drift – what was complex a year ago may be easy now
  3. Sales
    • Wonderfully hard to manipulate, very consistent over time, but neither timely nor easy to correlate with the task on hand.
  4. Function Points
    • Fairly easy to manipulate, difficult to maintain consistency – new technology will change the complexity of a given solution.  Fairly well correlated to the task at hand.  One person felt that feature points over the course of a Release (multiple iterations) was valuable, but over the course of a single iteration was not.

Some good points were made vis-a-vis what metrics are for:

  • To measure how your team is performing vs. other teams
  • To measure how your team is performing vs. its own history
  • To measure the impact of changes to the environment – for example, if we turn the heat up to 78 degrees, does that make things better or worse?  If we give everyone offices, does it make things better or worse.  Until we can answer these questions, intangible metrics will always lose out to tangible ones (like the cost of the office or the money saved by raising the thermostat)

Other metric concepts that were thrown out:

  • Features into QA and out of QA (identify bottlenecks)
  • Number of times a bug goes through the “opened, solved, reopened” cycle
  • Incomplete features at the end of a sprint
  • Requirements churn
  • Number of tests for the Iteration

My own suspicion is that there is no one true metric.  We need several metrics, rigorously measured over time to get a sense of the scope of the problem.  That’s not a very satisfactory answer, but it’s the best I have right now.

Wrap up

The group seemed to really enjoy this format, suggested we do more of these in the future.  I used a 20 minute timer to manage scope for the three parts of the discussion, which seemed to help quite a bit.  It was suggested that we bring up topics for future roundtable discussions on the mailing list, and that we should create a “backlog” of roundtable topics when speakers weren’t readily available.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>