Megateam Vs. The Codenado

Working on a large team can be crazy. "Why are we wasting all of our time in meetings?" "Who wants to respond to this email from the client?" "Will bringing this new person onboard slow us down so we miss our deadline?" "Whose turn is it to make sure the build goes out to the client this week?" "Why are we doing the same things over and over and not getting any better?"

At Detroit Labs, one of our largest project teams consists of 20 people - a designer, QA, Android and iOS developers, and a delivery lead - yet we all manage to work as a cohesive group and have fun doing it. We’ll talk about how we manage to keep small team performance and agility while gaining advantages of scale. From hiring to onboarding, keeping work flowing, QAed, and delivered, even how we choose our music, we’ll share our experiences about what keeps the Megateam going strong.

Transcript

2. Who Are We? Anne Cahalan Developer, Knitter, Cocktail Enthusiast Chris Trevarthen Developer, Runner, Record Collector Kyle Ofori Developer, Reader, Concerned Citizen Will Hinchman Developer, Jerk, Layabout
3. What We’re Going to Cover • Our Team Make Up • Team Culture • Advantages/Disadvantages • Our Process • Estimation • Pairing • Challenges
4. Why Megateam? • Most teams at Detroit Labs are 5-6 people • Megateam is currently 18 people • It was also the first large team in Detroit Labs history
5. Team Makeup “People… what a bunch of bastards.” - Roy Trenneman
6. What’s a good team made of?
7. DEVELOPERS! • 7 Android Developers • 7 iOS Developers • Builds the thing
8. Delivery Lead • Just one. • Handles the client facing stuff • Keeps the team on track • Deals with the Agile gooeyness Any comment on how 15 developers with just one DL/ Designer/QA plays out? #megateam
9. Quality Assurance • 1 or more as needed • Managing testing • Making test cases • Managing automated testing • Everyone is responsible for testing, though.
10. Design • 1 or more, as needed • UI/UX • Asset Creation • Making everything look great
11. Product Owner • Nice, if you can get it. • Handles feature decisions. • Preferably, just one (more on that later).
12. CULTURE
13. Culture • Labs has a culture, and makes a big deal of it • MegaTeam’s culture exists within the context of Labs’ culture, but is its own thing as well • Some of these are things we do on purpose, some things just started organically
14. Labs Culture Free of kings - Be transparent - Be a chef, not a waiter - Make it count - Real apps ship - Work together, play together
15. Hiring at Labs • Resume • Getting to know you • Cultural Interview • Tech Interview • What we look for
16. Colocation • We all sit together • Actually, take up most of the 5th floor workspace • Communication is easier • The mini-meeting • Less interruption in some ways • More interruption in others
17. Counter Strike • Team building activity • A way to blow off steam • Even those of us who don’t play can root for a team
18. blah blah blah
19. Sometimes you just need to shoot your coworkers in the face. It happens.
20. Bootcamp • Labs offers 2x weekly bootcamp • 2/3 Megateam participation • Shared experience of pain is good for the team
21. Music
22. Dojo • Lab time project • Crowdsourced playlist • Everyone contributes, at the same time • Dojo Logo Could emphasize how this is a fairly equitable solution for an 18-person team, since we have differences in preferences? #megateam
23. Retro START DOING KEEP DOING STOP DOING
24. Retro • Meet once a week to review • Out of the office - no distractions • No business until beer I imagine drive-bys would have gotten worse and worse as the team got larger, with people distractible by different things… #megateam
25. ADVANTAGES & DISADVANTAGES
26. Communication • Communication is important. • This is not great for those who don’t like people
27. Team Roles
28. Team Roles
29. Vacation Time • You can always take a vacation when you need one • Just give your teammates advance notice
30. Vacation Time
31. Hack Time • Fridays are Hack Days • This applies just as well on a big team • You can even join up with teammates to hack • We stagger hack days to keep capacity up through the week
32. Sick Days It happens.
33. Sick Days • On a big team, there will be people to help out if you are out of commission • Unfortunately, sickness moves around quickly
34. Onboarding • Our app is never really finished • New folks join at any stage of development • Onboarding experiences vary based on when you join team
35. Onboarding • We use a team manual to help with onboarding • Also have a project wiki
36. Onboarding • Challenges include: • Communicating best time/best way for new team member to take on challenges • Pairing and/or mentorship • Realizing what we may not have documented
37. Pairing
38. Why pair?
39. Preventing keyboard hogs
40. Ping pong
41. Switch up pairs
42. If all else fails…
43. Remote pairing
44. Pairing: Phew!
45. Process
46. How the magic happens Sufficiently advanced technology…
47. What do I do? • Sprint Planning • Card wall • Swim lanes • Columns for Backlog through to Done • WIP limits • Stand Up
48. How do I do it? • Forking • Feature branches • Code reviews/pull requests
49. When is it done? • Definition of done: • Unit tests pass locally • Analytics added • No new warnings • Screenshot & testing steps in the PR • PR has been peer-reviewed • Passed QA
50. What does it mean? • Big & Visible charts • Burndowns • Number of days left in sprint
51. Automation
52. Automation • Challenges include: • CI failures leading to false test failures • ownership
53. Estimation sucks.
54. Waterfalls. Don’t chase them.
55. Invite the entire team
56. Planning poker
57. Time box estimation sessions
58. Go as high level as you can
59. Challenges “Only a fool fights in a burning house.” - Old Klingon Proverb
60. You’ve been presented us at our best. That’s not reality.
61. Sometimes… things get rough.
62. Multiple Product Owners • Decisions by committee. • Prioritization is a fight.
63. Velocity - Scope • Sometimes, low velocity or changing scope just happen. • Although, they’re more likely a symptom of a deeper issue.
64. Communication • The biggest, most important part of working on a team. • Communication breakdown is very, very bad and very, very easy. • Try your best to keep lines of communication open. Another point—big teams mean more people/groups of people to gripe with instead of taking your concern to the person you need to talk to? #megateam
65. Rogue Work • Making sure all work is visible. • No one is an island, need team buy in on architectural direction. • Every decision made effects the team as a whole. TALK THROUGH THINGS.
66. Interpersonal • People are people. Sometimes they’re annoying, wrong, etc. • Telling people the truth, although hard, is usually the best route. • But! Don’t invalidate others feelings. • Try to re-frame your perspective - “Every villain is the hero of their own story” PS - Y’all iOS folks have been doing a beautiful job of communication, if you ask me. There have been problems, but there are also now many solutions. Don’t put this in the presentation.
67. Intrapersonal • Bottling up your issues is not going to fix them. • Again, communication is key. • Make sure there’s a safe space to communicate issues. I.E. Retrospective or Feedback sessions.
68. Questions?
69. Tweet at us! Anne Cahalan @northofnormal Chris Trevarthen @malusman Kyle Ofori @KyleOfori Will Hinchman @hinchable