Ops Driven Dev
In The Agile Flywheel, colleague Ray Riescher describes how velocity in dev drove corresponding velocity in ops:
Scrum set the flywheel in motion and caused the rest of the IT process life cycle to respond. ITIL’s processes still form the solid core of service support and we’ve improved the processes’ capability to handle intense work velocity. The organization adapted by developing unprecedented speed in the ability to deliver production fixes and to solve root cause problems with agility.
From what I gleaned yesterday in the O’Reilly Velocity conference I believe the tables are turning. Ops, or at least web ops, will soon drive development.
The reason for my saying so is quite simple: the breadth and depth of forthcoming web analytics unveiled in the conference. This is not “just” about Google making website performance part of their ranking algorithm. Everything related to web performance will soon be analyzed mercilessly under the “make the web faster” mantra. Dev will need to respond to analytics from operations with an unprecedented speed. For most practical purposes analytics run in ops will dictate the speed for dev.
The phenomenon actually goes beyond performance aspects. To be able to implement changes quickly, dev will need to be very good in ensuring the quality of fast changes. While quality has many dimensions to it, the most applicable one is test coverage. There is no way to change the code quickly without a comprehensive automated test suite.
The first step toward dev meeting the required speed is described in the post How to Initiate a Devops Project:
For a devops project, start by establishing the technical debt of the software to be released to operations. By so doing you build the foundations for collaboration between development and operations through shared data. In the devops context, the technical debt data form the basis for the creation and grooming of a unified backlog which includes various user stories from operations.
I would actually go one step further and suggest including technical debt criteria in the release process. The code is not accepted unless the technical debt per line of code is below a certain pre-set level such as $2. The criteria, of course, can be refined to include specific criteria for the various components of technical debt such as coverage, complexity or duplication. For example, unit test coverage in excess of 70% could be established as a technical debt criterion.
Once such release criteria are established, the metaphorical flywheel starts turning in an opposite direction to that described in The Agile Flywheel. With technical debt criteria embedded in the release process, the most straightforward way for dev to meet these criteria is to use the very same criteria as integral part of the build process. The scheme for so doing in given in the following chart:
One last recommendation: don’t wait till Velocity 2011 to start on the path described above. Velocity 2010 already provides plenty of actionable insights to warrant starting now. Just take a look at the web site.
The Agile Executive 
Israel,
I’ve only encountered DevOps as a mechanism for getting rid of IT Operations: conceptually, I move the whole business application configuration into the source code and use continuous integration and continuous deployment to remove the need for buying/managing hardware and packaged software.
Isn’t the ‘operations’ providing the analytics business operations?
Tim
Tim Coote
June 28, 2010 at 8:15 am
Hi Tim:
Thanks for your comment. My view of IT and IT Operations seems to more expansive than the one you hint at. I primarily view IT through the Business Service Management “lens.” The line between dev and ops might change some, but the need for business service management is invariant.
In the context of this perspective, one of the things that ops provide is the business analytics as you indicate in your comment.
Best,
Israel
Israel Gat
June 28, 2010 at 12:21 pm
Hi Israel
Thanks for that clarification. Does that mean that in your model what I’d call business operations (in my world that would be departments like Sales and it would have over-arching frameworks like order-to-cash to drive its behaviour) should be using ITIL concepts and identifying relevant Configuration Items, etc?
I certainly agree very strongly that IT needs to keep a much better focus on the business focus of what it delivers and how much it costs, but that seems to be a serious challenge for the folk at the end of the supply chain. For example the guys running the storage systems, who provide a service to the DB guys who provide a service to the apps guys who provide a service for the business.
Maybe your model has a much closer integration of IT and business – which makes conceptual sense and would break down some of the expensive technology silos, but has historically been very expensive to deliver. Or maybe it’s just a relabelling of job title under the COO 🙂
cheers
Tim
ps nice blogs, just found them yesterday when I was looking for some supporting data on the costs of different Agile techniques. I should have thought that you’d be interested in the same space as me.
Tim Coote
June 28, 2010 at 1:10 pm
Hi Tim:
I tend to differentiate between organization and governance. Both are, of course, important. Having said that, what counts at the end of the day is the outcome that a few organizations jointly produce. The organizational structure and the way they interact need to serve the outcome objectives.
Let me give an example which takes us away from the strong passions around dev vis-a-vis ops. Consider the interaction between development and field training. Dev might have successfully released a product, but it does not really serve its business purpose until the field is enabled. The velocities of the two organizations need to be aligned. If they are not, the desired business outcome will not be achieved.
Going back to my original post (“Ops Driven Dev”) in this thread, where the ops organization reports is not terribly important. What is important is the analytics produced to improve the product. Both the analytics and the concomitant action items taken in dev are about making the business outcome happen.
Best,
Israel
israelgat
June 29, 2010 at 7:49 am
Thanks, Israel. That makes much more sense.
Tim Coote
June 29, 2010 at 9:31 am
[…] itself in lively discussions about the number of deploys per day. Comments such as the following reply to my post Ops Driven Dev were typical: Conceptually, I move the whole business application […]
Technical Debt Meets Continuous Deployment « The Agile Executive
July 1, 2010 at 5:50 am