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 that quarter and some others were the least skilled.

• 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.

• A few people did all the hard coding
• Some people did almost no coding
• Some people have no idea how much of the app works
• Almost no one knows who anyone else is beyond their name and email
• Some people are clearly more skilled than other people
• Some people are always late to meetings
• Some people dominate every discussion
• Most people believe the #1 myth about teams

• 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
  • encourage "my code" attitudes
  • maximize work-in-progress
    • 4 tasks 25% done => nothing ready to test
  • make your Bus Factor = 1
  • minimize learning and growth

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

• Every week
• Identify and then analyze metrics that matter , e.g.,
  • Buggy code, low productivity, ...
  • Bad bus factor, bottlenecks, ...
  • Low team morale
• The only practice commonly associated with agile considered essential.

• The class team review tools:
  • Self reflect on your contributions, shared with your team
  • Summarize and evaluate your team mate contributions for the week, using the self-reviews and data collected by the team

• NO SILOS (The Agile Samurai, Chapter 2)
  • Divide and conquer is not your friend
• Swarm
• If you plan to code solo, message the team in advance
• If you see such a message, volunteer to help
• Use Facebook, Twitter, group.me or whatever works for low-effort easy communication

• 5 Ways to Build Relationships in Product Development Teams
• Drucker Exercise
• 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, ...

• Integrate development with learning
• Pick developers for a task based on learning needs
• If pairing:
  • Driver = learner
  • Navigator = teacher

• Trust
  • You trust your team so well, you let them know when you're really lost, or when you really mess up.
• Respect
  • You respect each team member and value their contribution, not in spite of how they differ from you, but because of how they differ.
• Responsibility
  • You see the success of the project and the team as your responsibility. Every problem is your problem.

• 100 hours
  • Time you have for this class
• 10,000 hours
  • Time to become expert in anything

• "Never let a good crisis go to waste."
• Problems are opportunities
  • Don't hide them
  • Study them
  • Root cause analysis
  • 5 Whys
• If your program crashed...
  • ... your code needs better defenses
  • ... your process needs better testing
  • ... your architecture needs harder to mis-code
• Then make small but effective fixes at multiple levels

• When code breaks, does
  • Blaming it help?
  • Running it again, but "harder"?
• You diagnose the cause and change the code.
• Fix team problems the same way

• No problem is a one-time accident.
  • if someone checks in broken code
  • if you deliver the client something they didn't want
  • if someone's late to team meetings
  • ...

• 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