The Law of the Small Team
Small teams are essential to create a customer-centric company. With self-organising leadership and alignment to the overall product roadmap, they are given the autonomy to decide what to build, how to build it, and how to work together while building it.
Once Engineering have their direction from the Product Roadmap the proposed outcomes may be added to the backlog of work of the relevant cross-functional team.
All outcomes are contrained by the organisation which creates them
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
— Melvin E. Conway, 1967
On the assumption that most products in a service organisation have a technology component, let's think what that means for your IT department.
Conway's Law will almost certainly apply. The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other, and that communication is affected by the ease with which communication is possible.
In a hierarchical, command and control environment, the software interface structure of a system will reflect the social boundaries of the organisation that produced it, and, given that communication is more difficult, the outcome tends towards creation of monolithic code bases. This type of tightly-coupled code rapidly becomes difficult to understand and amend, particularly when the original creators move on.
For some years companies have understood this link between structure and outcomes. Those who pioneered a business model of customer-centricity have had to work out new ways of achieving the outcomes they needed, which often involved re-inventing how people worked together. For example Netflix, Amazon and Spotify structure themselves around multiple small teams, each one with responsibility for a small part of the functionality of the overall product. These teams are given autonomy to own the whole process of the products and services they create, subject to operating with a guiding enterprise architecture.
This autonomy allows the functional capability assigned to one team to evolve and change independently of that of another, resulting in the ability to deliver changes to production faster.
If organisations retain larger sized teams, then larger monolithic systems are the result, which restricts their ability to experiment, adapt, and continually deliver value to the customer.
Hierarchical teams are no longer helpful
How many times have you seen a functional hierarchy such as the one below?
Where is the ‘front door’ for new work? Does it come in through the Project Office? Straight to the Technology Managers aligned to business functions within Technology Solutions? How about asking a favour from one of the Developers? When do you ask Application Support - do Developers only work on new stuff then tip it over the wall into Support? Perhaps a ticket has been raised with Service Desk, but this isn't just a simple fix or a service request, its a significant upgrade in capability....
When there is a consolidated list of all of the things that need doing, how does the IT Director know how to prioritise work, especially when there never seems to be enough resource available? When the business see an opportunity to create a new product, how does it know what to ask IT to stop doing so that it has the capability to work on the new initiative?
Where do Enterprise Architecture and Cyber Security report in? What about the Business PMO?
Year after year, this traditional structure of IT, and its position as a corporate service, means that IT is rarely more than a huge cost to the company, one that is always the constraint to revenue generation, and one to be outsourced when possible.
There is a better way! We start to work in small teams
We implement small teams by moving from functional silos to cross-functional teams and from hierarchical command-and-control to self-organising leadership.
We set up small cross-functional teams who have responsibility for specific features that build into one or more products, and let them operate using agile principles. Each team should be made up of the right number of people with the right skill set to contribute. They should also be 'ring-fenced' in that they belong to that team, and can't suddently be pulled off elsewhere because someone has decided that other work is suddenly become higher priority.
We call these teams ‘Squads’:
Each Squad contains 3 major roles:
- The Product Owner who has responsibility for deciding what work will be done
- The Scrum Master who ensures that the agile ceremonies are followed, removes impediments and coaches the team
- The Engineering Team which is a cross-functional, multi-skilled, self-organized unit, responsible for the creation of, and the quality of, the product.
We stop working like a Capex funded project team and start working like an important operational unit
The first step is to drop any Gantt charts produced by the PMO when the work was proposed and move to two-week Sprints.
This is not easy since the focus shifts from delivery dates to feature content, a concept which takes time to relay across to the Board and other executives.
The second step is to reinforce the fact that this team really does have the autonomy to do the job it wants to do.
This is not easy since disposessed management will try to exert their control over people they still line manage.
The third step is to make sure that the Squad prioritises its backlog of work and makes an intra-team commitment on what they can achieve in the next Sprint. And then they deliver on their promise to each other.
This is not easy since the traditional organisation will still not be able to prioritise what work gets done when, by whom, and team members will be pressured into covering an ex-team-mate's shift or coveted for a particular skill.
Products and Features; Tribes and Squads
Each Squad has a specific remit, with a dedicated Product Owner who will feed them user stories to build. This Squad may be responsible for a particular feature (aka a 'functional building block'), and can work alongside other Squads, within a Tribe which pulls together multiple features into an externally deliverable capability (aka a 'product').
The number of team members in each Squad, and the mix of their specific skills will vary depending on what products the company sells.
Received wisdom is that a Squad is no larger than could be fed with ‘two pizzas’.
Tribes are collections of Squads presided over by a Tribe Leader, who is typically fromn a technology background, and will face-off to the Product Manager.
Tribes bring Squads responsible for aligned features together; whilst the Squad remains autonomous, each may decide what to build, how to build it, and how to work together while building it - although they need to be aligned to the overall product roadmap, and short term goals.
Each Tribe has a Agile Coach who ensures that there is a commonality of approach as the Squads follow agile working practices, advising on protocol as necessary, and providing another voice back to the business on outcomes.
Next:
We look at each of the Three Laws in more detail in separate posts:
David Seacombe
David Seacombe
The activity of a small team is greatly assisted if each unit of work is also small, and has a single, easily ascertained outcome. We dig a little deeper in the Functional Building Block post.
David Seacombe