Software engineering can be a complex subject. It certainly is for Enterprises and it’s no secret that it can quickly become highly complex.

It doesn’t take much: one more integration requirement, automating away a tricky bit of toil, catering for just one more harmless little business requirement… It soon mounts up.

And that’s just the software itself. What about everything we like/want/need to wrap around an application? The SDLC offers a plethora of complexities to overcome and, sometimes, it can all feel a little overwhelming.

Here at Kingfisher, we currently have in excess of 60 scrum teams and ~1100 engineers all contributing to our “Digital estate” and, in addition to that, we are progressing through a Dev(Sec)Ops transformation. Sometimes, I’ll be honest, it feels like we’re on an exponential complexity growth curve.

Don’t get me wrong, Kingfisher is most certainly not alone in this — looking around us, we see this is a common fact — the nature of the beast, if you will, and our experience and training (and Twitter) tells us it is so. This is a big part of what makes a career in software engineering so exciting. But what are we doing to temper this complexity?

Background

As my first post here, I thought it might be useful to provide some context and insight into Kingfisher’s Digital division.

We are currently running four main programmes of work, each one containing a number of “domain teams” (you’d hear the term Product team too but more on that in a later post) providing solutions for their given business domain. Not to mention the teams and systems underpinning all of this business capability. Each domain team is then split into a number of feature teams. At the domain level, there is a governance layer: each domain should have as a minimum:

• a Product Manager,
• a Tech Lead and
• a Delivery Lead

and these roles are helping to bring alignment to our feature teams with our overall strategy and direction.

But there is, as you will know being the well-read professional you are, a lot lot more to it than adding a single layer of governance.

Embarking on our “Digital transformation” several years ago allowed for and bred disparate team growth, more or less promoted a lack of central governance and instead favoured programme autonomy in order to achieve high enough delivery velocity. This worked well and we have achieved an awful lot but we inevitably accrued a lot of (various forms of) debt along the way and at a point in time it all started to slow down again.

Evolution

One of the most recent solutions to tackling our complexity at scale was to put a new role in place — the Principal Software Engineer — of which I am one.

This, again, is not a new or unique solution. It doesn’t take much to discover this is fast becoming (if it isn’t already) a fairly ubiquitous industry role. For us, a PSE sits at the programme level, alongside our Programme Managers and Product leadership. Our role, essentially, is to bring about and maintain a level of consistency within and across our programmes and help define our future direction more cohesively.

One of the first activities we felt it was prudent to conduct was to define our principles to help drive desired behaviours and provide a consistent framework for our department to follow as a whole.

The first version of our principles is now “live” and we are working together to shape our decision making based upon them. They are the first and most fundamental step for our teams to align against, helping to create a common vocabulary and to help steer our roadmap.

The principles themselves are not designed to be revolutionary or controversial. Rather, they reflect a collection of proven best practices, either well established or relatively new. As such, they are both aspirational and a reflection of current activities.

It is also true that they are fairly high in number — 30! — and this a fact we were aware of early on in the formulation process. Ultimately, we settled upon the fact that as a starting point it was better to provide more detail than less. What we’re not wanting to do is “boil the ocean” though a detractor could easily cast that aspersion. Rather they reflect the acknowledgment, and my opening assertion, that software engineering is complex and also that all of our teams are, to varying degrees, siloed from each other and so priorities and focus inevitably differ.

We envisage and hope that over time these principles will change and diminish in number as some of them devolve into our teams’ shared ways of working and natural behaviours.

The next decision we made was to categorise our principles into four logical groupings:

• Organisational
  As a department, Engineering has an obligation to follow and apply our IT strategy. Our Organisational principles should both feed and feed from our Architectural Principles, providing a foundation for our Operational and Implementational Principles.
• Architectural
  Ultimately, Engineering are aligned with our organisation’s architectural principles but, here, we call out some of those principles that carry pertinence.
• Operational
  Led by our organisational and architectural principles, we must ensure we are well equipped to respond quickly to customer and market demands and are offering our customers a reliable experience whilst ensuring we are running in an economical fashion to reduce our impact on both company costs and the natural environment.
• Implementational (I’m pretty sure this is a real word?)
  Building, in turn, on the organisational and architectural principles, how we author and compose our applications must ensure we are delivering quality software solutions at the pace our business requires.

This made sense to us as we are trying to bring unity across the department and, thus, we must face into each aspect of the work we are and will be doing.

We then found we could group each category’s principles to help call out key themes to help highlight why we’ve set each principle.

Finally, to help our teams understand the purpose and benefits of each principle, we have taken inspiration from TOGAF and provided a statement and rationale for each.

Our principles then, without the gory details of our rationales:

I appreciate an image with so much embedded text is not accessible to all and I apologise for that.

We hope these principles provide our teams with a solid foundation upon which they can flourish, and we can support our DIY brands across the UK, Ireland, France, Poland, Romania, Spain and Portugal effectively and help set them up for continuing success.

If you are interested in joining us on our journey, please do check out our careers page.

Thanks for reading!