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.

My Certified Scrum Trainer, Micheal Vizdos (@mvizdos, http://implementingscrum.com), taught in my certification workshop that Scrum Masters spend lots of time starting difficult conversations.  He was so very correct.  By this time I had already started many difficult conversations with leaders and managers about agile and Scrum.  I had faced the CTO and come away with support.  But I worried about talking to this collegue.  I had fear of this engineer because:

• He was very skilled in the craft, with knowledge and the ability to create great software.
• He had a strong personality, able to decide what he wanted and work for it.
• He pulled no punches, stating his opinion with conviction.
• I admired his abilities and work ethic.
• I didn’t know him, personally, very well.

In other words, to face him I had to know what I was talking about and put my beliefs in the line of fire.

One day, with my training ringing in my ears, I asked him why he objected so strongly.  A difficult and rewarding conversation followed.  It was the beginning of understanding, of many more conversations and of working better together. (I’ll write about the content of that conversation another time.)

Shortly after that first conversation, I started reading “Fearless Change: Patterns for Introducing New Ideas.”  The book describes a pattern or method for helping your change efforts by enrolling a “Champion Skeptic” to help.  In a private moment with the objecting engineer I informed him that he was my “Champion Skeptic.”

Surprise: He was skeptical.

Months have passed and our discussions were more helpful than he knows.  He suggested task card improvements, important impediment removal and improved build processes, among other things.  He also blocked some progress in different ways, but that was the skeptic part.  Most important to me, he helped me improve myself.  I was able to present ideas better and improve my arguments for Scrum and agile practices.  He helped me understand deeper his points, and my own.  And we became more friends than just coworkers.

This week he announced that he is leaving the company for other adventures.  The technical loss of his skills to the team and company will be felt for a while.  The loss to me as Scrum and agile evangelist is also significant.  I now need to find another “Champion Skeptic” against which I can hone my skills as change agent.  I’ll need to find someone to talk straight and cut me down to size when my thoughts and ideas fall short.  Oh, I can find people who don’t “believe” in agile, but one who also provides open, truthful conversation is not easy to find.

Who helps you break the echo chamber once in a while, to see what others see?  Who makes you a better agile advocate and practitioner?