Site icon IT World Canada

Putting a number on Agile

Image from Shutterstock.com

Agile management of application development teams and projects can sometimes be a black hole that good intentions disappear into.

It doesn’t help that there are a variety of agile methods.

It’s a lot easier to say, ‘Here’s the goal, here’s the budget, here’s the time frame — just do it.'”

Tom Grant, a senior  consultant with Cutter Consortium’s Agile product and project management practice, noted in a blog that some project teams have found another obstacle: a need to prove to management there’s a measurable value in switching to Agile methods — sort of like return on investment or time to market.

If one was to create sure a measure, it should take into account a number of things and avoid others, he writes in this very enlightening piece.

He sets down eight of them worth thinking about.

One is remembering that the value of Agile methods is not the same as the value of the software Agile teams produce.

“Some of the teams with whom I was working tried to prove the value of adopting Agile to their management by assigning dollar values to stories,” he writes. “Unfortunately, that’s like trying to prove the value of a college education by rating the quality of the books assigned in your courses.”

If management doesn’t know exactly what it wants Agile do to, he adds, arriving at a convincing measure of how much it improved things would be difficult.

Remember too that Agile is a disruptive process that radically changes how software teams work, he writes, so an ROI calculation would be unbelievable.

Read and learn.

Exit mobile version