"Using Working SW As The Measure Of Progress Is Narcissistic...." How Do You Measure The Value Of Agile Instead?

Hi all,

My colleague and friend Mike Gualtieri wrote a really interesting blog the other day titled "Agile Software Is A Cop-Out; Here's What's Next." While I am not going to discuss the great conclusions and "next practices" of software (SW) development Mike suggests in that blog, I do want to focus on the assumption he makes about using working SW as a measurement of Agile.

I am currently researching that area and investigating how organizations actually measure the value of Agile SW development (business and IT value). And I am finding that, while organizations aim to deliver working SW, they also define value metrics to measure progress and much more:

  • Cycle time (e.g., from concept to production);
  • Business value (from number of times a feature is used by clients to impact on sales revenue, etc.);
  • Productivity metrics (such as burndown velocity, number of features deployed versus estimated); and last but not least
  • Quality metrics (such as defects per sprint/release, etc.).
Read more

ITIL: What Constitutes Success?

Is it a blog? Is it a musing (that’s not “amusing”)? Or is it just a cheap attempt to pick the brains of others smarter than myself? Does it matter? Can I do anything other than ask questions?

My point (or at least my line of thinking while I plan a couple of ITIL-related Forrester reports) is that we spend a lot of time talking about what to do (or more likely what not to do) when "adopting ITIL," but how often do we talk about whether we have been successful in applying the concepts of ITIL, the processes, and the enabling technology for business benefit?

Maybe it is because we quote the mantra that “ITIL is a journey” and we can’t see a point in time where we can stop and reflect on our achievements (or lack of)? Maybe we segue too quickly from the ITIL-technology adoption project into the firefighting realities of real-world IT service management? Whatever the potential barriers to taking stock, where is that statement that describes what we have achieved and our relative level of success?

Looking at this logically (fatal mistake, I know), assuming (potentially a big assumption) that there was a business case for the “ITIL adoption project” where is the post implementation review (PIR)? Where can we look to see the realization of business benefits (I deliberately didn’t say “IT benefits” BTW)? I’m trying not to be cynical but, even if we forget the formalities of a PIR, how many I&O organizations can quantify the benefits achieved through ITIL adoption? More importantly what has been achieved relative to the potential for achievement? Where did we get to in our desired-future-state?

Read more

IT Service Management Metrics: Advice And 10 Top Tips

Earlier this week, I attended the Hornbill User Group (or "HUG" as it is affectionately known) to listen to Malcolm Fry, IT service management (ITSM) legend and author of "ITIL Lite," talk about ITSM metrics in the context of ITIL 2011.

There is no doubt that metrics have long been a topic of interest, concern, and debate for ITSM practitioners (I wrote a piece a few years ago that is still the most popular item on my old blog site by a huge margin), and IMO I&O organizations struggle with the area due to a number of reasons:

  • I&O is not entirely sure what it is doing (in terms of metrics) and why.
  • We often measure what is easy to measure rather than what we should measure.
  • I&O can easily fall into the trap of focusing on IT metrics rather than business-focused metrics.
  • I&O organizations often have too many metrics as opposed to a select few (often led by the abundance of reports and metrics provided by the ITSM tool or tools of choice).
  • There is no structure or context between metrics (these can be stuck in silos rather than being “end-to-end”).
  • Metrics are commonly viewed as an output in their own right rather than as an input into business conversations about services or improvement activity.
Read more

100% Uptime, Always-On, Always-Available Services, And Other Tall Tales

We live in a time when customers expect services to be delivered non-stop, without interruption, 24x7x365. Need proof? Just look at the outrage this week stemming from RIM's 3+ day BlackBerry service/outage impairment. Yes, this was an unusually long and widespread disruption, but it seems like every week there is a new example of a service disruption whipping social networks and blogs into a frenzy, whether it's Bank of America, Target, or Amazon. I'm not criticizing those who use social media outlets to voice their dissatisfaction over service levels (I've even taken part in it, complaining on Twitter about Netflix streaming being down on a Friday night when I wanted to stream a movie), but pointing out that now more than ever infrastructure and operations professionals need to rethink how they deliver services to both their internal and external customers.

Read more