Optimising Team Boundaries For Iteration Is Fundamental To Agile
Nowadays, agile is a hugely ambiguous term. I still cringe when I see or hear the word and I have an agile jar at home where I must deposit a small sum of money each time I say it. However, I think we can all agree that agile’s heartbeats are it’s iterations. Doing things in short cycles to gather feedback and act with insight.
Accordingly, the structure of teams within your organisation and their responsibility has to be conducive to iteration. In my experience it is a fundamental necessity for truly benefiting from agile and continuous delivery.
But many never reach this depth of understanding. They stall at the scrums, the stand ups and the superficial, without realising that the core of the organisation must be optimised for iteration as well.
Self-contained teams with ownership of complete vertical strips of business functionality is the new normal. Teams unburdened from dependencies on other teams with a clear path ahead for relentless iteration.
Dependencies Between Teams Are An Impediment To Iteration
As a software developer, I have suffered the pains of my team being dependant on another team. Our stakeholders are chasing us for this new feature that will make us the next Apple, but we’re dependant on another team to provide some functionality before we can deliver ours.
Unfortunately, that team’s stakeholders are aggressively jockeying them to build a different killer feature which will also turn the company into the next Apple. So they care little about what’s important to us. In agile lingo, this is a blocker. It is preventing iteration.
Even when the other team is ready to engage with you, you still have to expend time and effort coming to a shared agreement of a solution that suits you both. And then you both have to implement your changes and integrate them.
The costs of these collaborative overheads are massively detrimental to overall lead time & overall efficiency. If your teams are inextricably coupled to other teams and there is a constant collaborative overhead, it could be costing you thousands of wasted people hours per year (and numerous knock-on effects).
Instead, structure your teams and give them enough responsibility and ownership so that there are few dependencies between them. Decision making is faster and time spent waiting on others is diminished.
An Example Of Team Structures Prohibitive Of Iteration
The most common pattern I see in organisation structures that stifle iteration is the horizontal layering of specialities. The BAs, designers, frontend developers, backend developers, DBAs, all have their own silo that crunches through work in batches.
Most use cases in a system flow through many or all of these layers, with each layer needing to coordinate with the next. As a developer, it’s frustrating to live in this world where you have to fight to get anything done. But the overall costs to the business of this inefficiency just make me wince.
General example of horizontal layering that occurs in tech companies
Teams new to agile typically flatten just a few of the layers. Often they bring the product team, designers and frontend developers together. This is a good step and improves the ability to iterate.
Teams new to agile often flatten a few layers and stop there
But that’s where many teams stop. Leaving core layers in tact that continue to stifle iteration when a decision or a change spans their boundary.
For some teams this manifests as not flattening layers at the top of the chain. Not embedding the types of people who help define the product like Business Analysts and Subject Matter Experts. For others it’s at the lower end, such as the backend team or the DBAs who implement a chunk of the solution.
Even teams who have built cross-functional scrum teams and are doing their fortnightly sprint are still held back by this structure. The tiny little user-facing part of the system is developed using agile, but beneath the shallow cosmetics, the iteration anchors are still firmly planted.
Autonomous, Self-Contained Teams
Instead of layerings by speciality, the modern agile approach is to group people by feature, product or business capability. Cross-functional teams who collectively specialise in a specific area of the business problem domain.
Importantly, the technical boundary of these teams mirrors their boundary within the organisation. They have the responsibility of a specific business capability, and they own all of the technology needed to build it.
Teams now control their own destiny and the entire organisation benefits. They can turn around small feature requests in under one day. And they can deliver any piece of work efficiently because there are few collaborative overheads.
This is what we mean by optimising for iteration and it’s nothing new. Amazon started this party over ten years ago and the industry has slowly been catching up since. It’s quickly become the new normal (search around for articles on netflix, spotify team structure for many examples).
If a team is constantly having to depend on other teams for all of their work, generally this is a sign that something is seriously wrong.
How To Get Here
Changing the core of an organisation — its culture and philosophy of developing software — can be an immense and tiring effort. I certainly don’t claim to have the secret formula. But as a minimum, most people I talk to agree that the absolute minimum is management buy in and strong technical leadership that properly understands agile and continuous delivery.
Often there will be resistance. It’s hard to break apart traditional command and control structures. People will be worried because they have a lot to lose — especially their power. Many developers I know have incredible war stories about battles over technical ownership and resistance to change.
I don’t have answers to these problems because they are hard. But I do have a little game you can play that will set you on the path to thinking in verticals:
Pick an important transaction of your product or service and follow it through the system. Look at the people and parts of the system it touches. Then draw an imaginary boundary around all them. Now imagine the cost of communicating and the speed of decision making within the boundary is negligible.
Now it’s time to make it happen and stop needlessly wasting so much money. Good luck.
