DevOps, Digital Transformation

For many of the organizations I speak with, DevOps very much forms a key part of their technology roadmaps throughout 2017-8. Some are making great strides by way of introducing automated delivery pipelines from development through to production. Invariably, however, there are others who often state the following: “DevOps is certainly an area of focus, but we are struggling with how to change from concept to fully fledged strategic transformation”. Needless to say, mechanisms for change are often the most useful methods to industrialise DevOps on an enterprise scale. I spoke fleetingly about these in my last post, so thought it prudent to share some of my practical industry experiences to date.

What follows is by no means a complete list of change techniques. Needless to say, I have tried to move away from the usual ‘start small, run a pilot, then slowly increase your engagement with other teams’ recommendation. I have merely stated some personal change techniques I have found useful to date in helping customers on their respective DevOps transformations, by really focusing on “How?”.

Value Stream Mapping

The value stream mapping technique originated from the manufacturing industry and utilizes lean principles to establish a ‘value versus waste’ model. Essentially, value stream mapping helps to breakdown a product delivery process into smaller steps and handover points, in order to help calculate efficiency rates across the software delivery lifecycle (SDLC). By capturing the end-to-end delivery flow with indicative business metrics, organizations can rapidly identify areas which are optimally structured, whilst bottlenecks can be quickly identified and resolved.

To effectively build a value stream map, resources from both the business and the IT function (development, test and operations) should be involved. This can help establish trust between all parties and will actually contribute to stronger working relationships across teams that have traditionally been isolated. Furthermore, it will help illustrate the cost and time attributed to each stage of the delivery pipeline, whilst also capturing the lead time between each stage.

Evidently, this exercise can be challenging and requires open dialogue in order to address the proverbial ‘elephant in the room’ issue. Needless to say, this is a powerful mechanism to help illustrate the need for DevOps driven change. Particularly at a time when organisations face stiffer competition in the digital marketplace, where time to market is key for business success.

Stop-Start-Keep

Stop, Start, Keep is an interactive, time-boxed exercise which focuses on past events to explore methods of introducing positive, DevOps-related change. The exercise solicits feedback across people, process and technology by asking resources to openly provide insight into things they would like to stop, keep or start doing, in order to make the DevOps transformation more successful. This activity can be used both at the start of a DevOps transformation and during its execution in order to provide continuous improvement opportunities. The sum of the activity aims to increase collaboration and minimize delivery constraints and can be a helpful aid to creating a more transparent culture for sharing knowledge in your organization.

Frequent Retrospectives and Continuous Improvement

Retrospectives are a fundamental underpinning of the agile manifesto and, for many organizations, serve as a means of avoiding the onset of blockers from reoccurring as part of the application delivery process. In the case of DevOps transformations, retrospectives can be used at logical points of a change to investigate what has been good, what has added business value and what requires further attention, in order to optimize that change. Much like a two week sprint, the retrospective should be time boxed, include key stakeholders involved in the transformation and must be responsible for delivering action points which can be fed into a plan for improvement.

100 Days, 100 Changes

I must admit to a bit of plagiarism here! The ‘100 days, 100 changes”’concept was taught to me by a former line manager, Phil Starrett. In essence, it is a mechanism to build quick wins and aid change momentum across large scale enterprise organisations. When we consider change programmes, they often focus on business drivers across the cost, time and quality conundrum. This is very much the same for the ‘100 days, 100 changes’ concept, whereby organisations are required to engage with their employees and vendors in order to solicit their feedback on areas which are working well, and those which aren’t working well across the SDLC.

From this activity, a number of improvement targets are established to help aid faster, more efficient change. The changes can range from softer working practices like introducing agile stand-ups to more tangible business drivers like deploying code ten times a day across the route to production. A change could even be to provide complementary fruit in the office! It can be anything to help augment the culture of change in a positive fashion that will provide business value.

The changes can be small, medium, large or technology-, process- or culture-related. The ultimate aim is to be able to look back over the 100 days and demonstrate true business value as a byproduct of bringing colleagues together to work towards 100 common goals.

Furthermore, because resources are consulted about the transformation initiative being executed, they feel more responsible for delivering the change as result of an enhanced sense of ownership. Indeed, ‘100 Days, 100 changes’ can be extrapolated to reflect 200, 300 and 400 days/changes, in order to progressively scale a DevOps change initiative.

Incremental Gains

During the London Olympics in 2012, I was intrigued after reading an interview with Sir Dave Brailsford, the former head of performance for British Cycling. He spoke openly about marginal gains, a theory which is now very well-known across sporting culture. The principle behind it is that if you improve in every variable underpinning or influencing your performance by just 1% then cumulatively you get a significant performance improvement. If we were to apply this to a DevOps transformation initiative, an organization could identify ten key principles across the SDLC by which they intended to introduce 1% performance improvements. The sum of which would be over a 10% qualitative gain for the business (the ‘interest’ compounds over time).

Essentially, by illustrating these marginal gains senior stakeholders are able to provide tangible data to support their DevOps transformations. This helps bring even the most battle hardened resources into alignment their visions and helps establish a stronger collective as part of the DevOps transformation. Ultimately, the 1% gain is a minimal target and once it has been achieved for each measurement, the target is then to hit a 2% improvement, followed by 3%, then 4% etc. Marginal gains help build momentum whilst the improvement metrics are more palatable for senior stakeholders to sign-up to and hang their personal reputation against.

In Closing: Keep It Simple!

As I mentioned, this list of change techniques is by no means complete and they won’t be fit for purpose for every organization. However, they have helped many of the customers I have worked with to date when embarking on their DevOps journeys. If I could sum up my own personal experiences, it is absolutely key to ensure your change messaging is simple. The challenges faced by most organizations are invariably the same when trying to deliver change and in essence, the principle values for communicating change should remain un-changed.

Namely:

  • What are you changing?

  • Why are you changing?

  • How are you going to perform the change?

  • Which axis of people, process & technology will be impacted?

  • How will cost, time & quality be affected?

  • What does the change mean for the business and the people within it?

If you have any questions or comments, please feel free to post them below. Personally, I would be keen to hear about any other change techniques which have been used at other organizations, to drive forward enterprise scale DevOps transformations.

  • Ben Saunders

    Client Principal

    Ben is a highly motivated, professional consultant with a proven track record of delivery across the financial services, media, retail and energy sectors. Having managed project teams of up to 30 resources, with budgets of £5m, he has forged a reputation as a driven and focused professional with exceptional leadership skills, paired with significant experience of communicating with C-Level executives, at a strategic level.

    More Articles by Ben