04. Agile Team Management

Servant Leadership

• Empathy: understand and share feelings of team members/stakeholders
• Awareness: aware of impacts of their decisions/behavior
• Community: maintains a feeling of membership
• Persuasion: dialogue instead of coercion or commanding
• Conceptualization: focus on the big picture; trust in your team for daily tasks
• Growth: develop everyone’s skills

The scrum master should help, not direct, their team:

• Drop the ego
• Act fairly towards all team members
• Should be confident and humble
• Be accessible

Archetype of a Scrum Master

The scrum master should empower communication:

• Between team members and stakeholders
• Between engineering and marketing
• Inside the team

They also need to protect the team when necessary; act as a shield to ensure the team can be successful.

They should refrain from jumping into technical details:

• Trust in the team
• Do not rescue team members too quickly
• Avoid technical discussions during planning

Team Organization

• Recognize everyone as an individual while ensuring there is collaboration within the team.
• Everyone is a developer and does everything
  • Work on different parts of the system
• Have some specializations; work on your core technical competencies, but also be competent in other fields:
  • Ensure there is continuous knowledge transfer
    • This ensures your team is resilient to unexpected losses
    • Bus factor: what’s the smallest number of people that can get hit by a bus before your the project fails due to lack of knowledge/experience
  • Developers should work outside their comfort zone

Agenda

Sprint planning:

• Ensure everyone knows their availability
  • People may be working on other projects
  • Check all deadlines for other courses
• Interruptions, team communication etc. is time consuming

Create an agenda:

• Don’t rely on memory alone
• Put all deadlines on the agenda
• Bring it to all planning sessions
• Make non-negotiable times clear at the beginning of the project
  • Times where you will not reply even if the server is on fire

Changes

The sprint plan should be protected: decisions were made with the PO and should not be changed on a whim.

Stakeholders may come at any time and ask for:

• Small cosmetic changes; superficial makeup
• New functional changes; stories that should be estimated and planned

The developer must know the threshold between the two and communicate with the stakeholders:

• Ask if the added makeup worth it
• Decide whether the story can be added to the developer’s buffer

Issues and Bugs

Issues: problem identified before a review at the latest.

Bug: problem discovered at the earliest during later regression tests; these must be added to the backlog.

High priority bugs may be taken into account during the current sprint. This requires discussion with the PO (as items are being re-prioritized).

If direct communication is used instead of formal reports, ensure reproduction steps are communicated.

Impediments

• Long meetings: stick to essential stakeholders; keep them time-boxed
• Illness: don’t come, plz
• Broken builds: especially with CI/CD, this becomes the top priority and interrupts the whole team
• Tools: if you don’t have the right tools you can’t develop
• Third parties: consider alternatives or work-arounds
• Scope creep: review stories and tasks thoroughly to reduce the amount of creep
• Unreliable PO: can’t get rid of them, so form strategies to deal with them
• Team problems: use retrospectives and involve the scrum master as soon as possible. Don’t let the problem grow
• External incentives: plan around clubs and other life priorities/responsibilities

Record traces of all issues for sprint reviews and retrospectives so that the team can learn from it if you face the issue again. See [https://xkcd.com/979/](Wisdom of the Ancients)

Bad Behavior Patterns

• Taking over everyone’s jobs
• Command: controlling everyone’s jobs
• Public blaming and shaming
• Siloing: specializing into one aspect; low bus factor
• Poor code quality practices

Reactive behaviors:

• Fear: failure is an option
• Pressure: adding more buggy features on top of a poorly-built base
• Experiment: run spikes when necessary
• Urgency: fire-fighting is exhausting