As a PM, Is your team Optimised for Value?

As IT project managers we like our metrics that define how well our project is performing. But what are the metrics that really matter?

Our principle role is to ensure that a contract deliverable is delivered and signed off, that our commercials are in order and that we don’t end up in a legal quagmire with our now ex-client. Like many of you, I have experienced projects that went off the rails and needed a herculean effort to drag a result over the line, and often we celebrated what a great job we did to deliver a result. These type of projects are all too common and usually embraced within an organisation that “hero worships” their people. Never again - heroes are for the big screen, in real life we need consistent and measurable development processes that can be sustained for months or years.

I have been creating and running scrum based software teams for over 10 years now. Following true SCRUM processes, the results are awesome. What I have observed over that period are motivated developers who enjoy coming into work, software releases with few defects and good working software. What happens too often however is that when we transition from “project to BAU” we see good team processes breakdown and a subsequent decline quality and increase in ongoing maintenance and operational costs. How to do we prevent this, how do we preserve the processes that deliver good value engineering? My hypothesis is that we need to measure agile maturity and ensure that if we have to hand over process that we can identify the agile maturity level needed to match that of our project teams.

So, I set out to prove that an Agile Maturity assessment was what we needed to one, prove that we were doing high maturity agile and two, that our client’s internal agile maturity needed to lift to match that of the teams handing over process. I am right of course, I just can't back up my hypothesis with recent supporting research. However…

Where that research is leading is towards the Agile Fluency model. While it looks like a maturity model from a distance, once you look into the model it is very different model. There are key measures that we can use to guide teams to better fluency, for example how long it takes for a code change to move from developed to in production, how often software is released to production, how often a production software release is rolled back.

As an agile project manager, we need to discuss with our teams how to achieve shortening the path to production, releasing more often, and we need to facilitate the business defining the value gained through these measures. When we have a “C level” executive at a showcase confirming the value of work delivered, and discussing what feature enhancements are next in line for development, I know we are nailing it.

References:

Diana Larsen

Thoughtworks