Scrum: The Role of the Development Team

There are three roles in Scrum: Product Owner, Scrum Master, and Development Team.  Collectively, they form a Scrum Team.  I recently became a certified Professional Scrum Developer (PSD I).  I support Scrum because I have seen the shockingly horrible results of being forced to violate just about all of its tenants simultaneously.  I understand by the pain of experience.  Given that, I feel like it is a good time to summarize what I know about the Development Team role in Scrum in order to help other understand it more fully.

As a side note, RIP Tom Petty.  Great musician!  “I Won’t Back Down” either.

Development Team

  • Each person on the development team has only the title Developer.
    • This promotes respect (a Scrum value) by countering the ego generated by pretentious titles.
    • This promotes cross-functional teams by not assigning people specific roles like Architect, Web Developer, Database Administrator, or QA Tester.
    • You may think this is a trifle, but when pay is linked to title and people start asserting titles for which the rest of the team does not feel they are qualified, serious division and political strife occurs.
  • Is self-organizing (has autonomy).
    • Autonomy, mastery, and purpose are prime motivators above the carrot/stick level.
    • This respects the immense talent that software development professionals have.  Micromanaging such talent is like telling your doctor how to do surgery.  It’s absurdly foolish!  Yet it happens every day in poorly managed organizations.
  • Does not include the Product Owner and the Scrum Master.
    • Unless they are acting in hybrid roles (which is a very bad idea).
  • Ideally consists of 3 to 9 developers.  I believe the sweet spot is 7.
    • Less than that, and it is almost impossible to have the cross-functional skills and raw firepower necessary to build a meaningful increment of software within a sprint.
    • More than that, and subteams naturally form which undermines team unity.
    • More than that, and exponential communication overhead becomes too costly.
  • Controls the sprint backlog.  Decides how much to pull from the product backlog each sprint.
    • No one (not even the meddling, micromanaging CEO) can push work onto the sprint backlog.  Well, at least they don’t in an organization that is actually agile (rather than just claiming to be in company e-mails riddled with other lies and false promises).
    • Neither the Product Owner nor the Scrum Master can push product backlog items into the sprint backlog.  Nor can they tell the Development Team how to translate those requirements into development tasks.
  • Performs all estimates.
    • No one (not even the horrible CEO pulling fantasy deadlines out of his ass) can estimate the work to be done.  Even then, estimates are not contractual commitments to whip the peons with.  It is offensive, disrespectful, and completely ignorant for upper management to employ such tactics.
  • Is dedicated to a single project.
    • One of the Scrum principles is commitment.  If every person on your team is assigned to multiple projects, there is no commitment to any specific project.  This won’t stop the unethical, manipulative, evil CEO from beating you with the 1 project that failed even when 4 succeeded.  Being evil, he was setting you up as a scapegoat from the beginning.
  • Is collectively responsible for all development work needed to create the next software increment.
    • While one person may be the lead on a task, the team is still responsible.  This prevents team members from taking the attitude of “Well, my work is done, so I won’t be blamed if the project fails” and “I only have to not be in last place when being chased by a tiger.”
  • Collectively owns the code.
    • Man, I have seen some people get angry when someone messes up “their” code.  On my first real job, I accidentally messed up some esoteric bit in some Java code while trying to fix it and got banished to the IT room for a year.  Just for changing one line of code!  A trivial, easily-corrected problem that did not even escape into production.  Complete alpha-developer, ultra-territorial, ego-fueled, disrespectful bullshit.
  • Is cross-functional.
    • If the Development Team does not collectively have sufficient skills to produce a working increment of software, it can’t do Scrum.  This explains the hype surrounding “full stack” developers lately.
    • Skill redundancy protects against single-person bottlenecks.
      • You don’t want to be dead in the water just because your only firmware developer is on extended, indefinite leave (due to being death-marched by the CEO over Christmas).
      • Everyone needs to be able to fix the damn build.
    • In software development, the cost of context switching and context hand-offs is EXTREMELY HIGH!  The more vertical end-to-end work a single person or team can do, the better.
      • Think of it this way.  Your 400m relay team consists of Usain Bolt clones.  However, the cost of passing the baton is 1 minute.  If I, with zero athletic ability, run alone against your superstar 10x team, I will crush you into the dust every time.
      • The moral: Heroics and alleged 10x superstars do not scale in software development.  You are better off with a well-managed team of solid developers that have breadth of skill working at a sustainable pace.
  • Works at a pace that is sustainable forever.
    • Death marches are always a sign of bad management.  Always.  It’s better to 20-mile march as per Great by Choice, one of the many enlightening books I have read that helped shape my software development philosophy.
  • Has respect for each other.
    • Without respect, trust will erode which leads to transparency eroding which leads to action on false information (lack of awareness) which leads to failure.  This seems like something Yoda might say.
    • If a team member is really lacking in skills and not improving, has no commitment to following your software development practice, or has been consistently disrespectful to others, fire them immediately.  Trust me: Do not wait a single day.  It does not matter what technical skills they have.  Letting this kind of situation fester destroys the morale of the rest of the team.
  • Self-reports progress daily by burn down charts or some other publicly visible mechanism.
    • At my last job, my brother actually rigged automatic generation of sprint progress by counting checked-off “grains of sand” subtasks put into each GitHub issue.  It was great!   Before that, we had a project manager with no software experiences (our CEO justified this by the obtuse assertion that “there is no difference in doing project management for building a bridge vs. creating software”) intrusively asking us to guess percent complete for everything.  This was stupid–meaningless numbers were being reported and then altered by a person who did not understand any of the tasks.  After generating accurate progress metrics,  upper management stupidly decided they were not accurate (time proved that they totally were) and ignored them (mainly because they proved that their deadlines pulled out of thin air were complete fantasy).
    • Empirical process control is based on transparency, inspection, and adaptation.  The example above shows that transparency alone is useless if the information provided is ignored or actively suppressed.  Unethical, dishonest, incompetent CEOs try to cover up the truth so that they can lie to customers instead of working with them to create real value (merely extracting revenue via lies without creating real value is criminal–it’s called fraud).
  • Should be collocated in the same physical room if possible.
    • Yes, multinational work is more and more a reality these days.  Still, it is horribly ineffective and should be avoided whenever possible.
    • Since in-person, face-to-face communication is the ultimate (as Agile asserts), telecommuting should be used sparingly.
  • Holds the daily scrum.
    • Neither the Product Owner nor the Scrum Master is required to be here.  Nor do they run it.  Nor is the Development Team status reporting to them or anyone else in this meeting.
    • This is supposed to be a short (15 minutes maximum) meeting mainly to coordinate work and identify impediments.  The point is to inspect and adapt the daily work items to increase the odds of accomplishing the sprint goal.
    • This is not supposed to be a posturing meeting where people blow smoke or try to appear busier than others to justify their existence.
    • This is not the time for deep problem solving and lengthy technical tangents.
    • When working with remotely split teams, some virtual water cooler chat needs to happen to reduce the alienation of the remote team members.
    • This should be held at the same time and place every day to eliminate coordination costs.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s