DevOps - It's not about the Technology : Lessons from the Frontline

The problem : the market was actually asking for these changes 9 months ago. By the time ACME wrote the approval paper, generated sufficient internal support, articulated the requirements to an extent where they could estimate the cost of the entire project, and had waited foran annual budget cycle to complete, a competitor had deployed their Minimum Viable Product (MVP), consulted the market for feedback and already pushed their first major release. Furthermore, from the outset the development of ACME’s app will be constrained by rigid definition and funding parameters in a way that’s far more “old school” than DevOps.

The lesson : Whilst ACME had the right tools at their disposal, it will still take 12 months to get from inception to MVP because the funding and approval processes are still aligned to old world methods.

Reporting lines can become a straight-jacket

DevOps teams need to be formed around a product, not an organisational hierarchy. In 1967, Melvin Conway stipulated that “organisations which design systems ... are constrained to produce designs which are copies of the communication structures of these organisations.” Given that we traditionally built and managed systems along multi-tiered architectures (App – App server – Database – Infrastructure) it would be easy to mount a strong argument in his favour. This, however, would be considered a DevOps anti-pattern. The team responsible for the product needs the skills and resources necessary to build and maintain that product. This would include Product Owner/s, Business and Technical Analysts, Software Architects, Engineers, Operations and Security Teams, a Scrum Master, Testers, DBAs, etc..

As you can likely infer, this involves people who are employed in different parts of the organisation, from Sales, Engineering, Operations, Infrastructure, Quality Assurance, PMO, Finance, and so on. Again, the challenge is to break out from these traditional structural constraints in support of the product.

To add to this, in most traditional organisations, individual business unit KPIs are not usuallywell aligned to product delivery. In the shorter term, day to day priorities are managed by department heads, and again, these may not always align.

The Good, The Bad, and The (Possibly) Ugly

The Good - Consider again our colleagues at ACME. Their diligent engineers have spent the last two weeks implementing the user stories selected for completion in the sprint. Code is being continuously integrated to the master branch, automated tests are passing and the application is repeatably being built and deployed to the test environment.

The Bad –Unfortunately, the product owner is working on another project and has been unavailable for the last two weeks. All of the business testers have been tied up with their “day jobs” and have been unable to validate any of the new features developed. The BA has been asked to get involved on the alpha project as that is three months behind schedule and needs some senior guidance.

The Result - No backlog grooming has been conducted. The team is unsure of priorities for the next sprint and unclear on a number of the requirements awaiting delivery. Development of new features will be held up or delayed until resourcing challenges have been resolved.

Once again, whilst the tooling and working practices of the engineering team may facilitate intra-day deployments, organisational reporting lines, competing priorities, personal agendas and individual relationships can all work to completely negate pipeline automation.

Tell me more

We’re really just scratching the surface of what a DevOps initiative means. As a start you are going to have to look at the maturity of your agile methods, because implementing a DevOps program in an organisation that has yet to embrace agile or test automation seems superfluous.

What does DevOps mean for Project Working Groups, Project Steering Committees, Architecture Review Councils and Release Readiness Boards?

And so on…

As I said at the outset – DevOps is certainly not just about the technology. The success or failure of the initiative will be determined by the willingness of the organisation to accept and implement change, not how fast Docker containers can be deployed.