Our Thinking
Technology Governance at Kainos
22 March 2017 | Posted by Peter Campbell

Does your organisation have technology governance? Does it allow you to be a growing, dynamic organisation? Or is it focused on compliance not delivery? We want to share how we think about technology governance within Digital Services at Kainos.

Most of us will be familiar with “governance”. Organisations have corporate governance because they needs rules and processes to function, particularly when company directors have legal responsibilities and liability. In the UK this results in an elected Board of Directors who regulate its behaviour.

Many organisations also have formalised project governance. This is an attempt to govern the actions and decisions of major projects. The shape of this project governance is typically a series of boards when decisions are made (or pushed up). This shape of governance is of course suited to waterfall projects — it is completely unsuitable for agile software delivery.*

The reason for this is that agile delivery is centred on delivering working software early to users and iterating on this. Teams need to be responsible for delivering software to users. If it doesn’t get to the users or isn’t working this is an issue for the teams. And so teams must be empowered to make decisions to deliver. If not then they cannot be agile.

This topic is worthy of its own post in the future to explore how project governance needs to be adapted from PRINCE2 thinking to work for agile delivery. But for now I want to talk about technology governance.

Technology governance is often adopted by organisations in a similar way to project governance. Multiple boards are setup that decide on a recommended technology or design. Architects will present to these boards to get advice or authority to proceed. In larger organisations these can grow to ridiculously large sizes: boards with 25–50 members. And many descend into technology talking shops because that is what hordes of architects like to do.

But again this way of working is not aligned to an organisation that delivers early. And this is not how we choose to govern technology decisions.

Within Digital Services we work with our customers to build software that delivers value and meet user needs. Our multi-disciplinary teams work with many different customers with diverse technology contexts. Much of our digital work is ground-breaking for customers and uses latest thinking to continuously deliver software. We work in an environment with high change.

The Governance Pyramid summarises our approach to technology governance. On the ground we rely on empowered teams to deliver. And our teams share openly allowing peer-review. Meanwhile we are developing Capabilities and Communities of Practice to collaborate and develop best practice across teams. On top we have accountable persons who define our shared principles and senior architects who provide external assurance.

Trusting People over Process

This is a core principle from the Agile Manifesto. And it applies directly to our governance. Every year we spend time searching for the best engineers and designers. We take on large numbers of graduates and apprentices that grow up through the organisation. Our staff are supported to learn and grow with both internal content and external training.

Given all this we want our people to think and innovate. It will be their creativity that finds new ways of working, develops new patterns and explores new technologies. With good execution this creativity will result in success for our customers and for Kainos.

So we expect to trust our staff to make the right decisions. We haven’t created an all-knowing technology playbook that makes decisions for them. Instead we’re spending time iterating a pre-flight team checklist for each role. This is why we invest so much to find and retain the best engineers, designers and managers.

This isn’t to say we don’t have processes. We do.

Principles over Homogeneity

Our teams share similar principles. These principles mean that we view good software in a similar way. Our intent is to deliver value to users by designing software that is as simple as possible that meets their needs.

When we come to recruit architects and engineers we are open about the type of people we’re looking for. These are people that think about users and software the way we do.

But what we don’t try and do is homogenise technologies, design and products. We don’t have some of the things that other organisations do:

  • A pre-approved list of technologies that teams must use. Experienced engineers and architects are free to choose the best technologies for the context they are working within — based on customer policy.
  • Exclusive relationships with vendors so that must recommend a single product. Teams are free to recommend the right product — commercial or open source — for the context they are working within.
  • A board to approve designs. Experienced team members are trusted to decide on how the software they are building should be constructed.

Technology Assurance

So how do we know that teams are making the right technology choices? And how can we see if they are applying the guidelines well? Well as we said this is primarily by trusting people not by compliance processes.

But we manage this risk by assuring what teams are doing. This takes a number of forms:

  1. We have an open-by-default culture and encourage teams to publish their designs as Open Design Proposals. This allows peer-governance and collaboration.
  2. Assurance by a solution architect attached to the project who works with the teams.
  3. Assurance by visits from one of our senior architects.

Visits

During these visits our most senior architects will check-in with teams to understand their decisions and design choices. This cannot be a check of every decision. Instead we will select based on risk-factors such as projects moving from alpha to beta or for major technical decisions such as hosting.

We are still developing the way we do this external assurance — today this can range from:

  • a conversation between architects.
  • a day visit to speak with the team. We have started to translate this into risks that can be given to the team to action. It can be shared with customers too.
  • a multi-day visit that might report back on engineering and ways of working across teams.
  • a code-level review that looks at the state of the code produced by the teams.

It’s important to note that our assurance is not a big scary thing. It is designed to help teams by celebrating good choices and highlighting change where there are risks. It shouldn’t be seen as a technology performance metric but as important advice from experienced eyes.

Peer Governance

We also improve governance by encouraging peer-review.

This happens naturally when people mix from different teams and disciplines. This can happen over Slack or over lunch back in the office on a Friday.

Communities of Practice, Capabilities and Teams

Communities of Practice, Capabilities and Teams

We’re trying this year to put more effort into tending this natural peer-governance process. A little structure and ownership makes a big difference.

Capabilities

We have identified capabilities we believe are important to delivering working software to production and given a single person ownership of that capability.

These capabilities are grouped around:

  1. Engineering for development. Given the size of engineering, it also includes sub-capabilities such as QA.
  2. WebOps for deployment, infrastructure, monitoring and operations.
  3. Performance for system performance.
  4. Security including application, infrastructure and operational security.
  5. Data for data science and analytics.

Communities of Practice

We encourage people to create communities of practice to share learning around areas that matter to them, for example development approaches, tooling, practices, machine learning and so on.

One example of a mature community of practice is our Technology Leaders group. You can read more about how we run our technology leader community.

Teams

Capabilities and communities will both inform and take direction from what is learned by our delivery teams who implement the architecture, use the tooling and write the code.

Our intention is that the technology communities and capabilities will drive up innovation and increase peer-governance for each discipline.

Effective feedback loops between teams, capabilities and communities help to make sure that learning that informs peer-governance is by design, rather than by evolution.

Without these distinct voices and effective feedback loops you run the risk of reverting to an (ivory tower) review board approach that has lost touch with reality.

This is how we approach technology governance. We recommend you re-think your technology governance if you’re an agile organisation with waterfall governance.


If you’d like to build great software with Kainos, please find out more here.

This post originally appeared on Medium. 


* this is why Dan North calls many projects water-scrum-fall because the agile bit is sandwiched between waterfall governance and processes.

No comments
Leave a Comment