Encouraging convergence: Putting a framework around agile team autonomy

The company I work for adopted an agile development approach in 2008. It was before my time here but, as I understand it, they trialled Scrum on a single, important project and then rolled the approach out to other teams when the benefits of an agile approach became clear.

As – rather awesomely – the company believes in pushing responsibility and ownership down to the team level and encouraging people to be undertake challenges as a group, each team became the owners of their agile process and practices by default. On the face of it, this sounds like a good thing, right? It was certainly one of the aspects that attracted me to the company; team ownership and autonomy.

Over the years, development teams have evolved, disbanded and been created. Most of the time, each team has been given full autonomy over how they work. Some successfully optimised their approach for the special characteristics and factors at play on their projects. Some were less successful.

Regardless of the success of these adaptations, what we have ended up with is a collection of teams with disparate approaches to the same mission – creating great software. This freedom has produced some really interesting innovations and we’ve been successful as a company. However, this divergence of approach has caused problems:

• We make the same mistakes repeatedly. For instance, a single team may decide to drop retrospectives (without thinking about how to maintain a continuous improvement initiative) and that turns out to hurt the team down the line. That team learns a lesson and starts doing retrospectives again, but that lesson is unlikely to be passed-on, so inevitably another team repeats the mistake a few months later.
• It takes a relatively long time to spin-up a new team. Each time we start a new project we go back to the drawing board to decide what our approach to software development should be. This takes time and does not necessarily build on best practice.
• Considering we are one company, we find moving people between teams can be difficult, as each move requires people to learn about a new way of working. In management-speak, this harms team liquidity.
• Best practices and good ideas that have worked are, in general, not shared as teams can be resistant to ideas from outside.
• Comparing projects is pretty difficult, so it can be hard to determine if they are struggling and need help, or if they are on track. Measuring progress on each team requires an understanding of exactily how that team works.
• We can find it difficult to collaborate across projects, because we are all different – we have different practices, different cadences and different traditions.

We could solve these problems with strict processes and low-level governance, but that would be a bad thing, right? Ideally, we’d like to avoid this stuff but allow teams the freedom to do what it takes to solve the special problems and issues that are tied to their circumstance – that is, to allow them to ‘inspect and adapt’. Our view is that we should be deliberate about how we run and deliver projects, but not dogmatic.

Therefore the project managers (who are effectively team leaders) in my division decided to develop a set of “working agreements” calling out best practices we have experienced (such as retrospective meetings) and the aims we have (such as delivering frequently) with a view to embedding these in all projects in the division and encouraging consistency.  We tried to identify the right things to do in the general case, to find universally useful practices that would be of benefit in most cases. We did not gather a superset of all the practices across our teams, with a view to homogenize every aspect of how we work.

The idea is that these working agreements form a framework for how we run projects in the division, so that new projects always have a solid starting point and the fundamentals of how we work remain broadly similar.

We have explicitly declared that projects can diverge from these agreements. Certain jobs will have special characteristics or other factors that suggest a different approach. For instance, an exploratory prototyping project is unlikely to require a 6 month roadmap! In these cases, we have agreed that divergences from the agreements should be discussed with our colleagues, so we all understand why they are happening and share new practices.

Furthermore, improvements and optimizations within this framework are encouraged for each project. Following a retrospective, the team may decide it would be advantageous to formally adopt TDD for their next feature. This kind of adaptation needs to be able to happen locally, without the need for consensus across the division’s development department. We want to reflect and embrace what we learn as software development evolves (e.g. the movement towards continuous delivery), so the agreements are a “living document”, open for negotiation and improvement, driven by local optimizations.

Our working agreements have served us well so far and we’ve still learnt new things to evolve our approach. In fact, we’ve recently gone through a review of our agreements and have made some changes to reflect what we now think is best practice for projects in our division. For instance, we have agreed to use a release train technique for continuous delivery planning.

I’ve shared our working agreements in my next post. Please take a look, if you are interested.