4 Steps to Maximize Your DevOps and Agile Results
It still amazes me how, after all the time and effort spent trying to figure out how to manage and execute technology projects, that some fundamental issues still remain. The foremost of these is: did we achieve the business value (when and for how much we said we would). Waterfall wasn’t great at this, Agile got better, now it’s on to DevOps. The problem is that most of us can provide examples where each of these approaches has failed and, even when they haven’t failed, there were still challenges with what the project produced for the business.
In my experience, very few IT projects articulate the measurable business value – or outcomes – that they will produce when completed. If you review project charters (from actual projects, not from text-book examples), you’ll often see that there is only implied business value that is sought to be measured. A typical example: “Improve access to organizational data.” I think there’s value there, but how can I measure the value that it will bring to the business?
But what if there were a way to change how IT practitioners view projects, and what if, simultaneously you had a way to increase your value proposition to the business and be more successful at execution irrespective of whether you use Agile or DevOps or your super secret project approach?
There is. Enter Accountable Care for IT
There’s been a growing trend in healthcare for nearly a decade called “Accountable Care” whereby doctors are incented to produce measurable results or outcomes for aggregated patient populations (this is oversimplified). An example: a primary care practice may see a group of 5000 patients over the age of 55 who have high blood pressure. The practice receives a bonus if the average blood pressure is lowered to normal ranges within a given period of time. The bonus is forfeit if the outcome is not achieved.
This has a few key elements that IT initiatives typically don’t:
- a measurable outcome that produces benefit (blood pressure reduced)
- a time constraint
- an incentive to work smarter, not harder
Now apply this concept to an information technology initiative and imagine a world where the project team is only paid if they achieve the business outcome prescribed. Would they execute the project the same way? How would the business and technology be forced to integrate? What opportunities would it provide for rapid innovation? Would they be more successful?
Where to Start?
You don’t need to change your funding or incentive model to start seeing results. And while any systemic change is difficult to accomplish, there are few simple steps that we’ve started to apply to projects and that have produced rather dramatic results:
- Define the business outcomes that reflect tangible value to the business and can be measured. This should be done with the business sponsor.
- Provide a set of constraints. Typical examples include: time, high-level technology, and security controls. But only provide constraints that are truly constraints and leave the rest for innovation.
- Track progress. There are incremental milestones to achieving the business outcome that should be tracked the way you’d track any initiative. Target incremental outcomes to be achieved in 30, 60 or 90 days and break them down if they’ll take longer.
- Give the team the freedom to make it happen within these constraints. This is where innovation thrives and where we’ve seen remarkable results.
What does this get you?
You get the benefits of agile, and DevOps with a high-degree of accountability.
Teams are able to create and innovate.
You achieve measureable business outcomes.
Work smarter, not harder.
Integrated business and technology achieving business outcomes.
Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.