Encouraging good communication within a team is one of Agile’s key areas of success. From daily stand-ups to pair programming, refinement and retrospective meetings, working in an open and collaborative way is a core tenet of Agile, whichever framework or methodology you subscribe to.
No hierarchy?
Many Agile approaches attempt to instigate flat organisational structures, where everyone on a team is (theoretically) on equal terms. You’ll also encounter evangelists using somewhat counter-productive phrases, such as “no more managers” or “remove all hierarchy” or similar calls promoting the abolition of traditional reporting structures.
In reality, you’ll find that the world (and by extension, all our work) is inherently hierarchical. Even a typical Scrum team has an implicit hierarchy in the form of the Product Owner. Sure, they don’t manage the team in the traditional sense – and in more mature Agile teams, they won’t be dictating what is included in each sprint – but they do have some authority. They get to choose this feature over that, set work priorities, time-box development activity and more – they’re just not micro-managing the technical development.
Scrum of Scrums
When there is more than one team, one approach to coordinate their efforts is the Scrum of Scrums:
With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams. These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.
The team member from each team attending the Scrum of Scrums is generally known as the team’s “ambassador”. Interestingly, the role that attends this meeting is not fixed (it could be the Scrum Master, Product Owner or one of the technical contributors). This leaves three important issues:
- What is the agenda and knowledge of the attendee – business and technical roles often have conflicting priorities (and an Agile coach / Scrum Master may not understand either).
- When there is inevitably some conflict between teams (priority, dependencies, solution architecture etc.), who is ultimately responsible for making those decisions?
- Whose responsibility is it to maintain an overall product direction for the teams? What controls are in place to ensure the Scrum of Scrums team is able to reach a (consistent) consensus?
Network approach to communication
In Setchu, instead of using the Scrum of Scrums technique, it uses a predefined two-tier hierarchy. Multiple Agile feature teams are accountable to a single control team (made up of a Product Owner and Product Architect on equal standing):
Teams (and any member thereof) are strongly encouraged to communicate informally and often, in a network manner, between each other to resolve minor issues and dependencies. There’s no hierarchy between the feature teams, but they are expected to try to reach decisions both sides are comfortable with, for most day-to-day interactions. Whenever that’s not possible or when a discussion highlights a wider concern, the issue is bubbled up to their (mutual) control team:
The control team is able to offer guidance and make decisions that are in the best interests of the overall product. As this team is a split between business and technical concerns, it is able to provide balanced solutions (and assess the wider impact) to their feature teams.
In this model, each team has clear ownership of its responsibility (and authority). When there is any ambiguity, there is a well-defined, central authority present to resolve the conflict – who are also ultimately accountable for the success of the product.
Setchu - Agile at Scale 