In Scrum, only 3 roles are prescribed; Product Owner, Scrum Master and Developer (Team Member). It suggests that we let go of our traditional roles (and job titles) to form an embedded team, that collaborates and cross-skills.
“All developers are equal, but some developers are more equal than others”
I have spoken to several project and delivery managers who struggle to envisage this approach working in the real world. Their opinion is typically that contrary to Scrum’s idealistic vision, in practice they need to be able to map specialisations (and therefore, roles) into a project team to ensure that the relevant skills and experience are present to set it up for success.
They assert that the hard reality is that not everyone is a “superstar” that is able to generalise (certainly to the standard required) and that Scrum doesn’t work in its purest (or purist) form with team members of varying levels of ability. For example, a dedicated tester may be adept at test-automation, whereas a junior C# developer may lack this experience. Your project will vary in quality and speed of delivery depending on the composition of the team.
I’d be interested to hear how people have addressed (the perception of) this issue and how they try to ensure each of their Scrum teams has the right mix of skills to guarantee success?
Please share your thoughts and experience by posting your comments below. 🙂
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.
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.