Silver Stripe Blog

In my talk at Agile Bengaluru, I asked “What is velocity? What does velocity measure? Is it useful?”

What is velocity?

Everyone was united on this – velocity is the aggregate of story points (or any estimate unit you use) completed in the sprint.

What does velocity measure?

I got a bunch of answers for this

• Velocity measures the amount of work (capacity) you can do in a sprint
• Velocity measures the amount of value delivered in the sprint
• Velocity measures the productivity of the team

Continue reading ‘Is velocity a useful metric?’ »

This is the presentation I gave at Agile Bengaluru 2010 this past weekend. It describes the journey moving from ad-hoc development to an agile process and how we then adapted it to a more Kanban like process. The bad news is that you can’t really make out much with just the slides as the commentary is not there. The good news is that the session was recorded, so I’ll post it up once the recording is made available. In the meantime, here is the presentation.

I was recently reading the Aberdeen research report on The Value of “Agile” in a Distributed Environment (My thoughts on the report in another post). As I read the report I had a nagging feeling that a lot of people doing agile are missing the forest for the trees. Then I came across this definition of agile which confirmed my fears

Definition: Agile

The agile process for software product development is a philosophy and a collection of rigid procedures that enable a self-organized team of engineers to develop rapidly, and manage scope changes, functional and performance issues efficiently. Composed of a series of short “sprints” each punctuated by a functioning deliverable work product and including a daily stand-up meeting – a “scrum” – involving the entire team, agile delivers measurable results to project management frequently. A backlog of function (or story) points is maintained by the Scrum Master who produces a daily “burn-down” report to mark the progress of the team.

I’ve highlighted a few parts of the definition that are particularly troublesome.

• Rigid Procedures – Since when has agile been about rigid procedures?
• Manage scope changes – This term gives the impression that agile limits the amount of scope change, when in fact scope change is welcomed and is used as a leverage to deliver a better product
• Function points – Agile teams don’t track function points at all
• Maintained by the Scrum Master – The backlog is not maintained by the scrum master at all
• “Burn Down” report – The burndown is an indicator for the team to self organize, not a “report” for management to “mark the progress of the team”

What I see in this definition is all the values that are considered important in traditional PM translated into agile practices. Terms like “rigid procedures”, “manage scope”, “function points”, “mark the progress of the team”, these are terms that are important for a waterfall process.

But all this is missing the forest for the trees. In the bigger picture, the whole goal of software project management has been shifting over the past few years, from tracking tasks to delivering value.

Where do I see in the definition about “delivering continuous value”, “improving RoI”, “collaboration” and “increasing customer satisfaction”?

This is the big change in software development. People have been doing iterations and standups for decades. The single biggest development that agile brought to the table is to enable project managers to move away from thinking only about time and budget and start talking about the value side of the equation.

Yet, when I meet teams that claim to be “agile” all they can talk about is time and budget. They talk about managing the agile team, tracking the progress, measuring the burndown chart. Missing in the conversation is anything to do with improving RoI, or delivering better value.

If I ask most agile teams for their definition, chances are I would get a definition similar to the one above.

Are agile companies missing the forest for the trees?