Teams

The Secret to Success

Teams Make Most Software

  • with mixed roles
    • analysts, architects, designers, testers, writers, ...
  • with mixed personalities
    • shy, dominating, leaders, followers, neat freaks, data nerds, problem solver problem finder, ...

Teams Make or Break the Project

Team Development is Central to Agile

  • 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.
  • Myths and Misunderstandings about Agile Teams

Team Assessment: CATME

What's Wrong with Your Team

  • 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

Number #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
    • establish different, often contradictory, priorities
    • make your Bus Factor = 1
    • maximize work-in-progress
      • 5 tasks 50% done = 0% ready to test
Divide and conquer is what you do to the problem, not the team.

What Teams Are For

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

The Secret to Success: Jelled Teams

  • 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

Incremental Agile Team Development

  • Speed kills! Don't focus on just the fastest way to get code written
  • Never program alone. Swarm and pair.
  • Invest time at early meetings to become more than names: Drucker Exercise
  • Training by pairing
  • Weekly team retrospectives

Building the Team

Training by Pairing

  • Integrate development with learning
  • How to choose a programming pair for a task
    • Driver: someone who will learn the most from this task
    • Navigator: someone who knows the most about this task

Retrospectives

  • Every week
  • Do it at the start of the meeting
  • Timebox
  • Identify key issues, e.g.,
    • Low bus factors
    • Low bonding experiences
    • Issues with quality, productivity, ...
  • Also review metrics on previous attempts to improve

Best Practices

  • NO SILOS (The Agile Samurai, Chapter 2)
    • Divide and conquer is not your friend
  • Pair and swarm
  • Tell the team when and what you're about to work on
  • Join someone, at least via Skype or chat or Google+ Hangout..., to work with or alongside them
  • Use Facebook, Twitter, group.me or whatever works for low-effort easy communication

The Three Essentials to Jelling

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

Team Development Takes Time

How to Invest Your Effort

Team ProjectClient Project
Invest about 50% in team
Invest about 20% in team

How to Improve

  • "Never let a good crisis go to waste."
  • Problems are opportunities
  • 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

Jelling by Process Repair

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

Bad Repairs

  • 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

The Challenge for Big Teams

Jelling Big Teams

  • Small teams (3 or 4) are easy to jell
    • More than enough high priority work to do
    • Just swarm all the time
  • Bigger teams (5 or more) are hard
    • Big swarms generate make-work to keep everyone busy
    • Big swarms lead to multiple conversations, missed communication
    • Big teams tend to collapse into a core subteam and observers
    • Big teams are very susceptible to over-achievers

A Pitfall

Voting

  • Voting is rarely the right way to resolve conflicts
  • Voting only works if no one cares about the result
  • Ergo, someone cares
    • Identify what the concerns are
    • Identify how to determine if the concerns are serious
    • Identify what would address the concerns and when to implement