Scrum Team

• The fundamental unit of Scrum, a small team of people
• typically, 10 or fewer people
• It is a small cohesive unit of professionals with all the necessary skills focused on one objective at a time, the Product Goal
• small enough to be able to work together effectively, and large enough to ensure all the skills needed are present
• responsible for all product-related activities
• accountable for creating a valuable, useful Increment every Sprint
• The Scrum Team collectively owns the DoD (now a commitment), that ensures that the Increment is usable
• Characteristics
  • cross-functional: the members have all the skills necessary to create value each Sprint
  • self-managing: they internally decide who does what, when, and how
  • structured and empowered by the organization to manage their own work
  • there are no sub-teams or hierarchies
• long ship metaphor
  • PO – The Captain - The Product Backlog is the steering oar
    • choose the direction and navigate the ship, use their experience and understanding of the conditions to steer. Storms are expected, constant adjustments
    • The captain has the authority to steer the ship, and the duty of care to the rest of the crew to find the best destination for them
  • D – The Crew
    • man the oars and row the ship, or manage the sail: responsible for keeping the ship moving
  • SM - The Bosun
    • someone who ensures the right things happen on the ship. Help everyone know what their role is, get the ship rigged for the weather, when to ship oars and bang the drum to row in time, etc
  • Visualizing this:
    • Without Developers, there is no progress.
    • Without a Product Owner, the journey lacks direction and focus
    • Without a Scrum Master, the hidden dangers can halt the journey
    • As a full team, the destination is arrived at through focused effort
• Can a person occupy multiple roles? potential impact of having multiple accountabilities:
  • Will they go to where they are most needed?
    • the person will focus on what they get the most satisfaction from, leaning towards the activities that they like the most
  • How will people know what accountability they are holding?
  • disrupt the smooth running of the team
  • The common effect is that neither accountability is served effectively, or one of the accountabilities is not serviced at all
  • The key here is that there is clarity inside and outside the team who is holding the accountability
  • Product Owner and a Developer
    • The ship is not steered as they are rowing, or the ship will go slowly as they are steering not rowing
  • Scrum Master and a Developer
    • oars clash as they are not banging the drum, or the ship loses momentum
  • Product Owner and Scrum Master
    • conflict of interest affects the team and the product. natural tension between product and framework
  • Serving many teams
    • one person to serve multiple teams in all accountabilities. time share across teams it is challenging to be fair to all the teams, the team that is making the most noise that gets the attention - that may not be the team with the greatest need
    • spend most of their time swimming between ships – or the ships have to slow down so that they can climb from one ship to another
  • When the storm hits...
    • you need all hands-on deck, Every member of the crew needs to perform their duties effectively in order to keep the ship afloat
    • storm is the unexpected events in product delivery. When happens, without having the people committed and focused to deliver on their accountabilities then the unexpected may capsize the product - ending it or pushing it off course
  • Where the metaphor breaks down…
    • PO needs to trust the team within a Sprint and let them focus on achieving the Sprint Goal – this is unlikely in a long ship
    • PO should allow the Developers to self-organize in the way they deliver the Sprint Goal:
      • The Developers have the freedom to adapt the architecture and shape of the Product to ensure that the product is useable (previously releasable)
• How Many Scrum Teams Should You Be On?
  • Developer, using scrum, 4-week Sprints, working 40 hours per week, attending to all meetings and PBR
  • Concern:
    • Developer told me that he doesn’t have a lot of free time, almost no free time, most of his time: meetings and trying to remember what he’s supposed to be doing
    • “Why does Scrum have so many meetings?"
  • Numbers per sprint of 4 weeks

    • Total working time 160h

    • Scrum events 20h

      • Sprint Planning 8h
      • Sprint Review 4h
      • Sprint Retrospective 3h
      • Daily Scrums 5h (15m*20)

    • Product backlog refinement 16h (10% of 160h)

    • NOTE

      • time-boxed, so could be shorter, this this is the maximum amount of time in Scrum events
      • time-boxes are normally scaled down proportionately for shorter Sprints

    • BUT…

      • “Yeah, but that’s only if someone is on one Scrum team. No one at our company does that.”

    • how much time is spent in Scrum events when someone is on multiple Scrum teams?

      N of teams	h per sprint	h events	h PBR	H left (capacity)	% meetings	% work time left
      1	160	20	16	124	22,5	77,5
      2	160	40	32	88	45	55
      3	160	60	48	52	67,5	32,5
      4	160	80	64	16	90	10
      5	160	100	80	-20

      • AND we are not including OTHER MEETNGS they may have, & wasted time in context switching
      • This case, Developer was on 3 teams…
      • not working at a sustainable pace (160h per sprint) or not able to fully participate as a team member
  • But what about Product Owners and Scrum Masters?
    • Product Owners and Scrum Masters do not have to attend Daily Scrums, so that cuts out some time. But even though they often participate as their Scrum teams can find it beneficial
    • scaled Scrum:
      • Depending on how is scaled and how many teams are working on one product, a Product Owner could serve as Product Owner while being on many Scrum teams
      • Scrum Masters: Scrum teams may share many impediments across those layers of service, so a Scrum Master could achieve “economies of scale” by being on multiple Scrum teams. But limit their opportunity to actually spend time with their teams. And if they do spend time with their teams, they are losing time that could be spent resolving impediments
  • Conclusion
    • if you want to strive for productivity and allow people to focus, Scrum team members should probably only be on one team
    • While Scrum does not prevent from having members of multiple teams, taken into account loss in productivity from context switching and time in meetings especially for Developers
• How Do the 3 Scrum Roles Promote Self-Organization?
  • The accountability of each role complements the accountability of the other roles. Hence, collaboration between these roles is the key to success
• What is the best way to organize 100 developers into Scrum Teams and ensure that they select the correct PBIs?
  • Scrum master…
    • only has the authority to ensure that the Scrum Team follows the rules of Scrum…
    • …If not immediately compliant, then working toward compliance increasingly and consistently (transparency of the increment surpasses most development teams skills and tooling initially)
    • has not authority to tell the development team or the product owner how to do their job The Scrum Master can coach, teach, establish learning situations, enter Socratic dialogue, and parent
    • However, they weren’t given the authority to manage the other members of the Scrum Team
  • The correct answer: let the developers organize themselves into Scrum Teams
  • The Scrum Master may…
    • remind them that all need to have the cross-functional skills on each ST to build a done increment
    • remind them that all 100 people must be engaged meaningfully and that mentoring is expected
    • have the lead developers lead a discussion about the software and architecture to be worked on, with the underlying dependencies
    • have the Product Owner discuss the intricacies of the Product Backlog
    • remind them that they have to deliver one integrated, tested increment at the end of the Sprint
  • If the Scrum Master organizes the Scrum Teams and parses out the Product Backlog
    • the developers are constrained by the intelligence and knowledge of the Scrum Master
    • Imagine the arrogance of a Scrum Master who believes that he/she knows how developers should organize better than the people themselves. This Scrum Master often has the thought in his/her mind that to be sure, he/she must control the situation; after all, they think that they are in charge (they think)
  • If the developers organize themselves into Scrum Teams
    • we are engaging the intelligence of all 100 developers
    • if they organize sub optimally, they can correct and continually adjust team membership as they find out more. A learning organization. Bottom-up intelligence
  • writer: I once arbitrarily put them into STs and then told them to fix my mistakes by reorganizing
• Equality - accountabilities in Scrum
  • All of these accountabilities (previously known as "roles") are needed in a Scrum Team. And all equally important to be successful.
  • Often these roles are not used effectively. Some dysfunctions:
  • Not all roles exist
    • All roles within Scrum are there for a reason and cannot be left out
    • Leaving out one of the roles will cripple your product and is not called Scrum:
    • Leaving out the Product Owner
      • the important work of the Product Owner is left entirely to Developers
      • Leaving them the accountability of producing a high-quality releasable product, stakeholder management, release management, maintaining vision and roadmap, etc.
      • imagine what this will do to the effectiveness of Developers & progress having no focus at all
      • The focus of the PO is to maximize the value of the product resulting from the work of the Scrum Team and therefore deserves it's own role
    • Leaving out the Developers
    • Leaving out the Scrum Master
  • Roles are combined
  • Hierarchy exists between people in one Scrum Team
  • Conclusion
  • Closing