Teams

• with mixed roles
  • analysts, architects, designers, testers, writers, ...
• with mixed personalities
  • shy, dominating, leader, follower, neat freak, slob, data nerd, night person, day person, problem solver, problem finder, ...

• The two least successful 394 teams in one quarter were the most skilled.
• The most successful teams in several quarters were the least skilled.
• The Benefits of Functioning Teams
• The Costs of Dysfunctional Teams

• The last lines of The Agile Samurai

  Whenever you are wondering whether you are doing things the "agile way," instead ask yourself two questions:

  • Are we delivering something of value every week?
  • Are we striving to continuously improve?

  If you can answer yes to both those questions, you're being agile.

• Weekly self and team retrospection process
• Every team has forms for self review and team review, and a "Data Viewer" spreadsheet with the responses for the current week and for the term.
  • Links to forms on Canvas
• The major factor in your team grade.

• A few members do all the hard coding
• Some members do almost no coding
• Some members have no idea how the app works
• Some members dominate every discussion
• Most members believe the #1 myth about teams (next slide)

• The purpose of a team is to split up work.
• When you split up the work, you
  • lose a shared vision
  • make everyone a potential bottleneck
  • make everyone defensive of their work
  • make your Bus Factor = 1

Divide and conquer is what you do to the problem, not the team.

• To gang up on problems -- show no mercy!
• Create and share one vision
• Minimize work-in-progress
• Apply multiple views, skills and perspectives
• Back each other up
• Teach each other
• Have fun!

• A jelled team is one that is more than the sum of its parts. [Peopleware, 1999]
• Signs of a jelled team:
  • low turnover
  • team identity
  • team pride
  • joint ownership
  • having fun

• Speed kills! Don't focus on just the fastest way to get code written
• Never program alone. Swarm and pair.
• Training by pairing
• Weekly team retrospectives

• Invest an hour in getting to know each other beyond name and major:
  • When I like work (night owl, early bird, ...)
  • How I attack a problem (dive in, study the terrain, ...)
  • What I value (politeness, frankness, listening, leading, ...)
  • Where I want to be (developer at startup, big company coder, grad school, ...
• See the Team Resources page on Canvas for some tools.

• Integrate development with learning
• Use classic pair programming with driver and navigator
  • Driver: someone who will learn the most from this task
  • Navigator: someone who knows the most about this task

• Every week
• Do it at the start of the meeting
• Timebox
• Identify and then analyze metrics that matter , e.g.,
  • Buggy code, low productivity, ...
  • Bad bus factor, bottlenecks, ...
  • Low team morale

• NO SILOS (The Agile Samurai, Chapter 2)
  • Divide and conquer is not your friend
• Swarm / mob / pair
• When soloing, slack / group.me the team when and what you're about to work on something

• Trust
  • You can let them know whenever you mess up.
• Respect
  • You respect your team member differences.
• Responsibility
  • Every problem is your problem.

• Try harder
  • Whatever caused the problem before will cause the problem again
• Make a big change
  • A brand new process is probably worse than the old one
• Add more process
  • This is how software development got in trouble in the first place
• You need to be SMART

Thanks to Hakim El Hattab for RevealJS