Enterprise DevOps guardrails and future of PMO
In the last couple of articles (part 1, part 2), I briefly touched on how DevOps has become the cornerstone of cloud modernisation and building high-performing organisations. This article dives deeper into the world of DevOps with a particular focus on how to maintain successful DevOps practices.
Regardless of the maturity state, you will hear the term ‘guardrails’ a lot in the industry. These guardrails pertain to the various applications of DevOps, such as:
Continuous Delivery
- DevOps as a Way of working for the team — Next-gen Agile
Continuous Integration
- Quality Engineering and testing base practice pathway
Continuous Deployments
- Autonomous deployments up to production with no manual intervention
What do I mean by guardrails?
Scaling up any operation creates a number of unique people and process challenges; scaling DevOps is no different. Hence, the stories such as Toyota production lines rolling out lean manufacturing principles and IKEA innovating distributions are big success stories purely due to the scale of the rollout. Setting up fit for purpose governance around such transformation should never be underestimated.
The goal is to create a light level of autonomy, intellectual stimulation from work, and a safety-culture around the teams to operate. Organisational guardrails help you to set up this governance and to know what good looks like. Some examples of practices are as below:
- Centre of excellence
When you build a new set of capabilities into an enterprise, starting with a centre of excellence helps to distribute and demonstrate the value of this new capability. It’s an operating model that affords you to build and then scale up to all other teams. Good examples of this are Experience Design and Customer Experience Teams, who operate as an organisation’s centre of excellence for gathering insights and providing value to other teams.
- Cross functional teams
Technology delivery teams traditionally tend to set up cross-functional teams with Full stack engineers, QA Engineers, Business Analysts, etc., yet do not include other critical business functions such as Sales and Marketing, People and Capability, etc. Allowing other disciplines to homogenously interact with your Delivery team will increase the level of collaboration and result in growing a high-performing culture. You can see this being used for greater effect in regulatory environments where groups such as Risk, Compliance, and Security have embedded into the same team mindset and share common goals.
- Federated teams
The federated operating model is commonly used across Architecture groups, CX Team members, and Security specials, as a focused group that services multiple delivery units or teams. Working in this operating model is a great way to influence the team culture and to build new capabilities into the targeted team. However, the challenge is to find the champions who can work in this model as individuals need to be superstars, yet fit in and gel well with teams to drive them toward success.
- Few other technology examples
While how your teams operate is the key enabler to successfully adopting DevOps, there are several other technology examples that also aid teams. API Playbooks, Enterprise coding standards, Style guides, Quality engineering scorecards are some of the frequently used examples. If you looking for a publicly accessible example, BBC GEL (https://www.bbc.co.uk/gel) and Westpac’s design guide (https://gel.westpacgroup.com.au/) are good starting points.
Once you have your guardrails in place, what helps next is to show your teams what good looks like so they know where they need to go.
What does success look like?
With any of these guardrail practices in place, the next step is to understand how your organisation is performing — keeping in mind that you might not get an accurate assessment of this if you are only using your organisation as the baseline of your progress (i.e. how far you’ve come).
As explained in my previous write-up (here), when it comes to DevOPs, there is a clear-cut definition of a high-performing team. Creating the feedback loop and visual clues around team performance helps a team to benchmark against other teams and teams outside the organisation.
Below are some of the concepts that I use to help teams understand how they are performing compared to others. The goal is to encourage certain behaviours and create healthy competition between the teams to drive a high-performance culture.
Most of the success measurements such as Deployment Frequency, Lead time to change, etc., is based on the definition of high-performing teams. This certainly comes with some cultural and change management challenges for teams adopting to DevOps way of working. Therefore, having the right support structure and training in place is equally important.
As teams start to travel within the guardrails and gain momentum, the next thing to worry about is how you achieve operational and delivery excellence.
Next-gen Digital PMO
The role of Project Manager and Project Management Officer has endured multiple reincarnations. With the introduction of Agile ways of working, roles such as Scrum Master” and Product owner took over some of the Project Management responsibilities. However, the principles and the value of Project Management prevail untouched to date.
Following are a couple of examples I’ve used within teams trying to automate the core principles of Project Management:
- Measure Scope
- Measure Budget
- Measure Quality
- Measure Time
- Keep track of the risks and actions
With DevOps, we have started to keep track of the “Type of work” we spent time on:
- Business Projects
- Internal Projects
- Changes and Updates
- Unplanned work
This really helps to tie it back to the High-performing teams goal you have set, given you can tie these measurements back to the high-performing team definition and characteristics. For example, research shows that high-performing teams tend to spend less and less time on the “unplanned work” bucket and spend more time on planning and delivering value.
If you have a team spending too much time on unplanned work, it’s a good indication and evidence of how that team is performing.
Conclusion
From my experience, as you take your cloud jump and start adopting up the DevOps ways of working, there are three main areas that really solidify your journey:
- Having guardrails in place makes sure there are safety mechanisms embedded into your organisation to create fail-safe culture.
- Establishing what success looks like sets the direction and vision for the team to kick-off their continuous improvement journey.
- Implementing operational excellence through next-pen PMO concepts helps you to make sure that your team is focusing on what matters most.
While I really enjoy taking organisations and teams along on this modernisation journey, the most rewarding part of it is seeing the exponential jump in productivity once they have come out the other side. I’m really looking forward to sharing my final piece in this series. Stay tuned.
