Silver Stripe Blog

Scrum prescribes this little ceremony at the end of the sprint called “the demo.” The idea of the demo is to show the stakeholders what was built during the sprint. What can be wrong with that?

Continue reading ‘Questioning the end of sprint demo’ »

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?

A few days ago, the hard disk on my laptop crashed. I called up tech support and asked them to replace it. A technician came down and changed the hard disk and then proceeded to reinstall the operating system using the recovery disk provided by the manufacturer. Unfortunately the disk was scratched so the reinstall could not complete. Now instead of replacing the disk, the technician asked me to contact tech support and someone else will come down and provide a new disk. Knowing that the OS would have to be reinstalled, and something might happen, why didn’t he have a backup disk with him? So I have to make another call to tech support.

Executives see the rising number of calls and try to cut corners to manage it quicker, leading to.. even more calls. A broken process itself contributing to increasing the demand.

Thats failure demand.

So what does this have to do with agile teams?

Continue reading ‘Why agile teams need to understand failure demand’ »