Continuous Delivery is the promise on which DevOps too often fails to deliver. The extreme programming movement started 20 years ago with the explicit goal to improve software quality through a “just-in-time” concept for software development, also known as agile development. But still, according to last year’s edition of the often quoted Standish CHAOS report only 29% of software projects deliver on-time and on-budget.¹ What can we learn from this?

1. Presentation of conclusions from the 2016 Standish CHAOS report Standish report presentation

Lesson learned from many years of Standish reports offer some obvious conclusions.

• Winning hand – these are the software project characteristics which reach a success level amounting to 81% in the 2016 Standish CHAOS report. Their characteristics:
  • Small projects
  • Agile methods
  • Skilled teams
• Losing hand – these are the software projects running the greatest risks with a failure rate of 64%:
  • Large projects
  • Waterfall methods
  • Unskilled teams

So the recommendation is clear. The DevOps movement is on the right track.

But agile development is not enough – learn from dog agility

Picture published based on Wikimedia Commons license. For details about the copyright owner, see  Golden Retriever agility teeter.

No roadmap, no performance

On the agile dog course it becomes obvious that a dog cannot find the track by itself. In agile software development, the importance of the handler’s role sometimes seems to be forgotten. Neglected product management is a common reason for project failures. Indeed, in many software engineering environments, a principal uncertainty exists with regard to product management.

Agile came about to enable software developers to adapt to changing requirements. Rather than making detailed plans up front, like in old waterfall models, agile development promised to have the ability to adapt, to onboard new feature requirements, if not on-the-fly, so at least “on-the-sprint”. In a DevOps culture, aiming at delivering a potential new release on a daily basis, the focus on the ability to adapt is even stronger.

With agile, the old style product manager with long-term plans detailed out in Market Requirements Documents (MRD) and Product Requirement Documents (PRD) went out of fashion. In some engineering organizations this created a cultural gap. There is a common misunderstanding, that agile somehow makes roadmap planning redundant, that we just change the roadmap and its vision with every sprint iteration. Yet, experience has proven that without an understanding of overall objectives, DevOps brings no value. In the Standish report, the skills of the executive sponsors of a project, and the strategy and roadmap owners, is a key factor that is often the difference between success and failure.

Hierarchy of objectives

A hierarchy of objectives sets the priorities for each daily prioritization of tasks:

• The strategy defines overall vision(s) and objective(s)
• A product roadmap outlines high-level goals for upcoming product versions aligned with the strategic vision
• A release plan juggles the three factors that can be altered to meet goals: time (=planned release date), budget (=resources), and the feature scope. If your feature scope is too large, you can move the release date or try to add resources (budget) to get more done in a shorter time. In planning upcoming sprint backlogs, the product owner calibrates these factors over and over in relation roadmap goals.
• Sprint backlog: This is where the product owner puts the prioritized tasks for the DevOps team to focus on.

While this may seem obvious and simple, real-world software projects often fail to establish and communicate this hierarchy of objectives. As a result, DevOps teams risk running astray like agile dogs without a handler.

DevOps needs more

DevOps also adds further requirements on managerial control. For instance, in your DevOps vision, you have to take Delivery & Support into account. For one, agile teams need agile infrastructures, which we have written about in our ITSM section. But furthermore, your application lifecycle management must embed the support chain, from 1st line, to 2nd line and 3rd line. This also impacts your DevOps organization.

At Data Ductus, we find these topics highly interesting. We are always happy to share our experiences with others. If you are interested, don’t hesitate to get in touch with us.  All dogs are welcome!