Many companies define positions by a list of “Roles, Responsibilities, Accountability and Authority.” The RRAA concept is that every individual needs to have RRAA defined for them so everyone knows what each person is supposed to do. This supports the common focus on individuals as “resources.” (Funny how companies talk about the importance of teamwork but create structures and schedules that deal only with people as individual “resources.” But that’s another blog entry.)
A common “resource” on a traditional development team is the Team Lead. This is one of the positions that change or disappear after the transition to Scrum. Naturally, introducing Scrum into a company seems to bring many questions about the Team Lead. “Who do we go to with questions?” “Who owns the technology?” “You mean the Team Lead goes away!? How can that work?”
The primary focus of value in Scrum is on the team, not individuals. So how does the value of a Team Lead get provided by a Scrum team?
In one company there were several discussions with project managers and management about the Team Lead position. Mostly, they thought it was necessary for a Scrum team to have one person as Team Lead. A definition of the Team Lead’s Roles, Responsibilities, Accountability and Authority was created. We had some difficulty communicating how the value of the Team Lead is not lost in Scrum. Here is the definition of the Team Lead after mapping it to the team:
| RRAA | Traditional | Scrum |
|---|---|---|
| Roles | Technical point of contact | Team (cross trained) |
| Team management | Team (peer commitment) | |
| Responsibilities | Assuring cost goal | Product Owner |
| Assuring technical requirements goal | Product Owner | |
| Assuring schedules met | Release Plan and Sprints | |
| Voice of sanity to company | Team | |
| Personnel scheduling and time management | Team membership and Sprints | |
| Accountability | Discover and escalate impediments | Team Members (technical impediments), Product Owner (product impediments), Scrum Master (Team performance impediments) |
| Escalate negotiation if original goals not achievable | Product Owner | |
| Authority | Manage engineering problems | Team |
| Direct team member activities | Sprint Plan |
A read straight down through the Traditional column is interesting. Imagine one person required to do that. One person. I would not want to be that person! Can one person do all those things effectively?
Team Value
Lets check each of the traditional values as provided by Scrum:
- Technical point of contact: Because everyone on the team collaborates consistently, the entire team ends up cross trained on the entire product. When technical questions or discussions arise it’s likely that anyone on the team is aware of the status, technology and progress. Your “bus number” goes up!
- Team management: Scrum banishes command and control by placing management with the team. Peer pressure of a good kind is created during the daily meeting and planning meetings. Commitment to peers in an environment of trust is a powerful motivator.
- Assuring cost goal: The return on investment (ROI) of a product is the focus of the Product Owner. Scrum defines the schedule and costs as fixed. The Product Owner assures the cost goal by guiding the team to build the highest business value parts first.
- Assuring technical requirements goal: With the help of the developers on the team, the Product Owner maintains the Product Backlog. This focuses the teams efforts on the customer value and steers the team to technical solutions that meet the value. The Product Owner may not be technically knowledgeable. But with good story definitions and Sprint Reviews (or Demos) he knows when the story is complete.
- Assuring schedules met: Time spent adjusting Gnatt charts and project road maps that change every other day is no longer needed. With sprint length defined, the dates for a potential release are already decided. The Release Plan is adjusted every sprint to match current progress. Schedules are nearly automatic.
- Voice of sanity to company: Transparency and visibility of a project are hallmarks of a good Scrum team. All the indicators on the team board, story point velocity, estimates, team planning sessions and retrospectives provide a clear view of reasonableness or insanity to the entire company. The power of retrospectives to uncover unrealistic expectations or company impediments cannot be over-stated.
- Personnel scheduling and time management: This is completely automatic in a Scrum team. People know what they are working on because they are on a team, focused and motivated to complete a Sprint Backlog. Enforcing the rule of protecting the Sprint means time management is easy. If it’s not in the Sprint Backlog, don’t spend time on it.
- Discover and escalate impediments: Scrum defines specific moments where all members of the team are expected to bring up impediments. The daily meeting format includes discussion of impediments by each member. Sprint Retrospectives create a safe environment for larger and deeper difficulties to come up. The Scrum Master and Product Owner are expected to have difficult conversations with management and others when needed.
- Escalate negotiation if original goals not achievable: If a failure of the project is coming, it tends to become visible very early in a Scrum team. All the indicators already discussed above with “Voice of sanity” reveal unrealistic expectations right away. The Product Owner is in the point position to bring this up to the company and knows by daily interaction with the team that it is coming.
- Manage engineering problems: The daily meeting is the place where process or infrastructure problems usually surface. The team talks about them, asks about them and watches for them every day.
- Direct team member activities: In Scrum the Sprint Backlog, as derived from the Product Backlog, directs what the team needs to accomplish. The team then designs the activities or tasks needed to accomplish their committed work.
A well functioning Scrum team has the best leader it can get: The Team! Leadership made more powerful by investing it in the whole team.
I hate scrum’s “team-based” leadership. I work in that environment and it means you have to play politics for every damn thing.
Some of us want to be managers and leaders BECAUSE we want that pressure and responsibility.
If you’re not that kind of person, don’t get into management.
Thanks for the clear statement.
There is an interesting balance that must be struck in every team. It is a balance between clear leadership and open collaboration. If the lead or manager directs too much, collaboration suffers. If the team is simply allowed to do whatever they want, direction suffers. The problem is that, once you hand such power and responsibility to one individual, it is very easy to kill collaboration. Scrum attempts to balance this strong tendency for control and choking off collaboration by investing much of the decision power in the team.
If you are in an environment of high politics, the team has gone too far the other way. In other words, every team member must be willing to trust the other team members and allow them to do it their way. And the Product Owner and managers must make sure the team understands the direction and goals of the product so they have a direction to go together. Playing politics all the time is a dysfunction.
I made a sequel post to this one about lessons learned during a Scrum simulation: http://blog.dayleyagile.com/2010/05/13/dynamic-scrum-team-leadership/