A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
Prudential Corporation Asia
DevOps - It's not about the Technology : Lessons from the Frontline
Matthew Taloni
As the wave of digital transformation sweeps across most industries and businesses, so too does the need to transform the way we work. Transformation programmes are seldom easy, particularly in traditional businesses where processes and behaviours are entrenched. Implementing DevOps needs to be considered an organisational change program; it needs to be managed with the rigour and discipline of any other significant investment; and it needs pervasive, cross-functional support in order to be successful.
DevOps means more than just tooling, or establishing an automated Continuous Development pipeline. Before embarking on your own program it’s certainly worth considering what DevOps means within the context of your organisation. Whilst the ability to take code from a developer’s machine and have it running on customers’ iPhones with the click of button is most certainly technically achievable – it’s the myriad of longstanding organisational nuances that have the potential to trip you up.
Am I running a project, programme.......... or managing a product?
Most, if not all traditional organisations follow onerous project selection and investment processes.
Said projects are usually well defined, with a clearly articulated beginning and end. This approach served us well, particularly in the days when project teams were formed, “big bang” deliveries were made, and on-going support was then “thrown over the fence” for Ops teams to manage in BAU.
The problem in the DevOps world is that teams can’t be project based, they need to be product aligned. The beginning and end points become a little more opaque. The team that builds the product is the team that runsthe product. Furthermore, in much the same way as we want our development to be iterative and delivered frequently, we need our funding to be equally as dynamic.
Let’s explore this with a hypothetical example:
The scenario : ACME Ltd approves project Skywalker in its annual budgeting process to the tune of $5m for delivery in 2019. Skywalker will deliver a revamped robo-advisor app. The features (scope)of the product are locked down in accordance with fixed price contracting practices. This will be the first project to leverage the shiny new CI/CD tools and agile methodologies.
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.
