Scrum Teams Have A Team Lead

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:

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.