In the previous article, we looked at underlying core values and setting principles to help create the right environment in which a good effective agile engineering culture can grow. In this article, we will look at how you can apply these to really build
a great engineering culture.
You need to coach a team
Like many people I have long followed and played in many a team sport. There are so many aspects of sport that promote being part of a successful team, not just a successful sports team, but a highly productive, successful team within the workplace. I personally
have learnt much more about agile concepts, what it means to be part of a team, even how to deal with personal agendas by playing basketball than I have working within the financial services sector.
In sports every team has a coach. Football teams have many coaches, basketball teams have coaches, volleyball teams have coaches, my list could go on and on. Coaches bring with them different talents, different experiences and different beliefs; however,
all have the same drive, how to best get performance out of the team. Your engineering teams are no different.
Values and principles maybe the foundations of your engineering culture, the principles that guide your engineering teams, but there are other key building blocks that you need to really drive performance. Because of this, an engineering team is just the
same as any sporting team, it needs a coach to help get the best out of them as individuals, and the best out of them as a collective.
Each coach needs to bring with them certain tools to help teams succeed, but these tools can be very common across all your teams. Because of this, I personally like coaches to set 'mottos' that the team abides by. Now, following our concept of “principles
are greater than practices” not all “mottos” should be the same for each team, however, there can be a core that all teams abide and follow. Here are a few I have found to be useful when dealing with engineering teams (and the personalities within them):
- Leave your ego at the door
- Do the right thing
- Team first
- No politics
Your agile engineering coach can install these in the team members and no doubt others. The great thing here is that these “mottos” are simply building blocks upon your core principles, aimed at ensuring individuals really buy into and believe in the culture.
Chapters, Charters, Guilds…Its about shared knowledge, not control
One of the common issues I have heard within financial services is that agile engineering lacks central control. If for example you apply principles over specific practices, then you will have engineering teams working in different ways, so how do you control
them? How do you ensure they are building the right things, working in a way you can trust, meeting the standards you hope to set? It’s not just financial services that suffers with these topics, many IT departments struggle to reconcile these concepts of
consistency with flexibility. The issue becomes one of control many believe, however, it really is about shared knowledge and alignment.
For example, how do you as a CIO/COO/CTO know that Quality Assurance (QA) efforts are consistent, that the QA performed on product released by one team was of the same standard, followed the same patterns as that of a different team? How do we get that level
of comfort and confidence when each QA is in their own team working as part of that team and not as part of a QA department? The answer is shared knowledge and enforcing cross team relationships for specific issues. There are many ways of achieving this, but
the most common is using a 'Chapter' and 'Guild'.
Chapters / Charters
Chapters and Charters are very similar, however I personally prefer the use of a Charter to a Chapter. I prefer Charter because of its historical definition, Charters wield great power and freedom, so I prefer that word. For me it is more aligned with accountability.
At the end of the day they are pretty much the same. The shared concept is that a charter/chapter will:
- Set guiding principles
- Set specific practices
- Set specific standards
- Set specific methods
Now this may seem to go against the concept of principles over practices, but it really doesn’t. Here we have a grouping of skilled individuals that are applying their skill in a consistent fashion based on shared learning, shared understanding and shared
desire to do the right thing. This means that though the individuals within the charter may work within very different teams, the skills they bring to that team, the practices, standards, and their methods are largely consistent. This means a charter is ensuring
you have that consistency and control across distributed teams, teams that could work in very different methods.
Guilds
These are far less formal, they do not have 'power' as such, they are not accountable or expected to meet certain standards, rather guilds are about knowledge sharing and wider training. Individuals in teams often belong to a single Charter, however, they
may be part of many different guilds, guilds that share knowledge and provide training on areas that that individual finds interesting but doesn’t deal with on a day-to-day basis, nor form part of their expected skill set.
While a Charter may have a 'lead', Guild leads are more aligned to being evangelists and mentors, they do not form some form of reporting line.
The following diagram is from Spotify. It shows clearly how Spotify implements a formal Chapter across each of their teams, in their case termed 'squad'. While the Chapters are clearly structured, you can see the less structured nature of a Guild in action.
Reflection…
So far in this agile series we have looked at the relationship between software concepts, concepts such as 'cohesion' and how that can be applied to thinking about engineering departments and teams. We have looked at how core values and principles can help
drive the right mindsets and form the foundations of a solid agile engineering culture. In this article we have looked at how to embed that culture, how coaches can add key building blocks to help individuals work well within teams. We have looked at how the
introduction of Charters and Guilds provide alignment, standardisation, and consistency in key skillset areas within teams. All of this is leading to, in theory, a highly productive agile engineering culture, one that can be highly productive and successful.
However, before we get into specifics of how this all fits together and can work beautifully within regulated business, we must look at how we keep highly intelligent people motivated.
In the next article we will look at some of the challenges of keeping engineers motivated, an aspect that is almost always overlooked / ignored.