Open source mindset to enable scaling
In order to scale agile, we need to bring several teams on the same page. We need them to share a business and user understanding, a vocabulary, pace, backlog, and emerging architecture. Teams must balance functionalities and architecture, business value and quality, across a common project.
When the number of teams increases, we often end up with teams more specialized on technical components than others. If we don’t, we sometimes have more issues getting a consensus from all teams about what needs to be done how on very sensitive pieces of code. At the end of the day, even if the agile manifesto discourages silos, software engineering is still a craft, and people are better at some stuff than others. The agile manifesto also encourages small teams, so you need to have some kind of borders between them.
So we might create silos… not a good idea. But projects already do it out there, and have success doing it. Have a look at open source projects that do very technical stuff about security, message queuers, databases, servers, and so on. They make components that are far from the final features delivered by projects that integrate them. Only a few people have a final word on what is developed. But in the end, they provide what integrators expect from them, and generally respond quickly enough to requests. You can reliably integrate them in order to provide features. And they build quality. Why does this work?
Because everything is transparent. They have wikis, tutorials, forums, jiras, githubs, they interact with their users, respond to requests, take suggestions into account, and make decisions and roadmaps clear to everyone. You can even get and debug the code, fix it, propose new features implementations, so that they are included in the next release. At the end of day, if the component is useful to the community, a team of a few people have proposals from dozens or hundreds of people.
Now let’s get back to our in-house multi-team project. As input, you have a business backlog. You refine requirements, split them across teams. When assigning them, you come up with direct requirements for core components. While teams study functional requirements (or develop them), they will also come up with requests for core components. At this point, you have 2 solutions:
- either all teams can modify core components while developing functional stories, in which case you need to somehow align architectural decisions taken in several places,
- or a few teams are responsible for core components consistency, in which case you must ensure that they are responsive enough to current and mid-term requirements, with a sustainable pace (sustainable pace includes quality code and just enough development).
To support the 1st option, you need to have the right people organized the right way. It can be tech leads within teams, with hands on, or super-brains above us common mortals. I never believed super-brains are the optimal solution, but apparently some organizations have the right profiles to make it work. And synchronizing tech leads might be difficult if you have too many teams, too much pressure, too many sites, different priorities between teams and so on. Which is why you end up with the 2nd solutions in some contexts.
So why not trying an open source way of working within your organization? Make your source code public to other teams, support them, make sure your PO takes their requirements into account in your backlog, for instance by organizing votes for features requests. And when you see you’re on the same page with other developers, you can even give them the right to check-in some code directly. This may seem obvious and simple to you, dear agilists. But phrasing it as an open source mindset will instantly ring a bell to the nerds you’ll be explaining this. And frameworks, i.e. governance models, already exist out there (apache, eclipse,…).
What do you think?
AAAgile 