Don’t Justify Agile Based on Productivity (revisit)

Kallokain wrote a rebuttal to my post questioning the value of productivity metrics to justify agile.

In a recent article Ken Judy takes the stand that agile software development should not be adopted on the grounds of higher productivity. The reason for that, Judy claims, is that there are better ways to justify adopting agile than with hard numbers.
I can sympatize, because I have worked in my share of software development projects where the measurements did more harm than good. Nevertheless, I believe Judy is wrong in this instance. Most organizations measure the wrong thing. That does not imply that measuring is bad in itself. (read the post)

Just to be clear, my objection is not that agile should not be justified by hard numbers but that I haven’t seen a metric for productivity gain specifically that both stood systematic scrutiny and was economically feasible for the average business to collect.

In my experience, measures that are tied to some non-revenue related abstract concept of “productivity” such as lines of code, story points, etc. are more problematic than helpful.

My point about velocity is that it is a measure that should be a feedback system back to the teams and becomes problematic if it is considered some sort of intrinsically meaningful measure that can be reported to senior executives (as in “We completed 20 story points last iteration, 25 this iteration. We’re five story points more efficient!”)

I agree that the ultimate measure of success in business is profit. I understand that any business decision should somehow influence revenue gains or hard dollar cost savings.

The problem with justifying an agile adoption based on revenue gains is there are so many other considerations that attempts to credit any single factor become dubious.

Cost savings need to be real not theoretical. Who did you lay off? How much budget did you give back based on agile adoption? Jeff Sutherland has a paper that does show significant cost savings using Scrum. The subject company was a CMMI-5 organization and there commitment and rigor to measurement was higher than most companies would support and is cost justified based on the government regulations they perform under.

If someone can propose a relevant metric that is economical for a small to medium size business to collect, that can be measured over time in small enough units to show increased performance due to specific process changes, that has some relation to reality that can be meaningfully communicated to senior managers, and doesn’t create more problems than it solves, I will be happy to consider it.

The Day Oxygen Became Extreme

Extreme What? by Justin DonnellyAt the precipice of change, we are getting sentimental here at the Oh! Network.

As a developer joining Oxygen NY in 2001, I entered a code and fix culture under a facade of waterfall planning. I fought arbitrary dates, bloated specifications, and reality-challenged reporting. I acquired a survivalist’s skill for landing valuable projects and picking co-workers who helped carry them to completion.

As team lead, I made myself project manager. I used a risk-managed, iterative approach based on Steven McConnell’s Software Project Survival Guide and Earned Value Planning. We provided transparency, met dates and exceeding expectations.

Still, I had the awful, lonely feeling it was unsustainable. A tiny team, we were isolated from each other. We needed a collaborative practice. We needed to share knowledge, commit to a common way of working, and lift each other past our individual limitations.

I found the following e-mail thread capturing the moment we adopted Extreme Programming (XP). A bit of everyman’s history with a very small ‘h’…


From: Ken Judy
Sent: Tuesday, January 13, 2004 2:40 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: Agile Methodologies

Here are sites for different agile methodologies. Of the five of them, XP is the most exacting. The others are generally light frameworks for ways of developing or managing projects that support the agile manifesto http://agilemanifesto.org/.

XP: http://www.extremeprogramming.org/
Scrum: http://www.controlchaos.com/
Crystal: http://alistair.cockburn.us/crystal/crystal.html
Adaptive Software Development: http://www.jimhighsmith.com/
Feature Driven Dev: http://www.featuredrivendevelopment.com/

— Ken


From: Luke Melia
Sent: Wednesday, January 14, 2004 5:09 PM
To: Ken Judy; Kristofor Selden
Cc: Keith Frank
Subject: RE: teamwork

Hi Ken,

Kris and I spent some time today reviewing the agile process frameworks you sent around and met this afternoon to discuss our planning. We’re going to follow the XP rules and practices for the most part.

http://www.extremeprogramming.org/rules.html

We will likely invest somewhat more effort in up-front detailed requirements in order to support your work-package tracking efforts. In addition, some practices are irrelevant for a team consisting of a single pair of developers. We’ll ignore those and pay close attention to the practice “Fix XP when it breaks” in order to arrive at a set of practices that is effective for us. I’ve read the criticisms of XP that argue it is “all or nothing” but I feel that this approach will work for us.

We’re going to be pair programming and plan to work together 11am – 1pm and 2:30 – 5pm. This will allow us time at the beginning, middle & end of the day to respond to email, etc.

This is all going to start this Friday. On Friday, we’ll do a code review, go over the task breakdown for the SES project and plan for our first milestone, as you suggested. I’m also going to rearrange my desk to make it work better for two people to sit at.

Luke


From: Ken Judy
Sent: Wednesday, January 14, 2004 5:31 PM
To: Luke Melia; Kristofor Selden
Cc: Steve Morgan
Subject: RE: teamwork

Sounds good. Our team is so small that a strong agile approach should work well as long as we manage risks. I’ll look into the “Tracker” role in the XP model to see how to adjust my tools to your approach.

— Ken


From: Ken Judy
Sent: Thursday, January 15, 2004 10:33 AM
To: Luke Melia; Kristofor Selden
Subject: RE: teamwork

Hi,

Please go ahead and block out 11:00am-1pm and 2:30-5pm in your calendars as “busy”. I’ll send out an e-mail to IS all so they know what’s up. Feel free to decline any meeting requests at your discretion and let me know of anything in your calendars you need me to cover for you on.

We will need to start the morning “standup” meetings so that we keep focus on the project and one of the things we’ll need to address is how to best use Michele as owner.

— Ken