Megateam vs Code-nado: Lessons Learned While Working on a Large Team

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
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). UP NEXT - ANNE & CULTURE
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 I wanted to start with the culture we are inside of—the company culture. Labs makes a big deal about our culture, it’s a thing we always think about and are aware of. Some general buzzwords we put on our website about it, but basically we value independence, transparency, our flat structure, and teamwork.
15. Hiring at Labs • Resume • Getting to know you • Cultural Interview • Tech Interview • What we look for We don’t want to see resumes, we send out a GTKY. It’s more like the thing you fill out on match.com than a job application. What have you failed at/show us some code…what are you passionate about, what kind of books do you read. Everyone reads, everyone votes, lots of comments and discussion. Anyone in the company can participate in the cultural interviews. And whatever position you are applying for, we have one not-that-thing person in your technical interview to see how well you can explain to a non-peer what you are doing. Even our non-tech roles have a cultural and a tech interview. In the DL tech interviews, you get fake mustaches. We’re looking for people we want to work with, people who are interesting and will add something more than just pressing the right buttons to Labs. I use the lunchroom test.
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 Labs offers a twice-weekly bootcamp lead by a personal trainer, and 2/3 of MegaTeam participate. It's pretty cool--the way it's structured, I am about as wiped out at Chris here is, and he runs marathons. While it's great that we encourage each other to push ourselves to hold a plank for another 30 seconds, there's another factor at work. A 2014 study from Univ. of New South Wales showed that shared experiences of pain increases group solidarity and boosts cooperation.
21. Music Everybody likes to listen to music while you work, right? Helps you concentrate, drowns out the rest of the office. We've actually got a turntable and a jambox as part of our team area. Chris has a huge record collection, so do some other teammates. If it gets too quiet, someone hops up and puts on a record. Or, if we're not being hipsters about it, someone will plug into the speaker and run a pandora station.
22. Dojo • Lab time project • Crowdsourced playlist • Everyone contributes, at the same time • Dojo Logo In fact, a couple of our devs came up with and Labs built and released an app called Dojo that allows a group to create a collaborative playlist. We'll hook up a phone to the jambox, post the room # in hipchat, and everyone on the team gets to play DJ. That's all nice, but it has a very practical affect: we are hardly ever wearing headphones. It happens, but it's not the norm. Which means we are always available to each other for questions or to bounce ideas off of.
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 think this is maybe the most important thing we do. Our weekly retro is held at Detroit Beer Company, around the block from our office, over beers and snacks. It gets us out of the office so we can completely focus on the retro--no drive-bys pulling people out for just one second; no laptops; Also, we have a rule: no business until everyone has a drink. This gives us a little bit of time to talk to something NOT work. UP NEXT - KYLE & ADVANTAGES
25. ADVANTAGES & DISADVANTAGES Getting on, staying on, taking off (temporarily)
26. Communication • Communication is important. • This is not great for those who don’t like people Communication is really important in our project. There are lots of different things going on in the app, different people take on pieces that could potentially overlap or at least influence one another. Chances are high that you will have to keep in contact with someone else to get your work done.
27. Team Roles There’s a lot of work to be done, so we try to spread the responsibility around. That’s why we have team roles. Roles range from just checking the number of cards to be done in each category to attending meetings with clients and being tasked with solving additional platform-related problems — Retro Ranger: lead the weekly retro; pay for our bar tab; get reimbursed by DL; enter retro notes and to do's into Basecamp. Cross-Platform Paladin: determine if a cross-platform exploration is needed this week. If so, collect devices and set up for the testing; recruit other team members to participate; collect testing notes & distribute to each platform. Sprint Planning Sorcerer: lead the sprint planning meeting; determine if any cards scheduled for development need further breakdown; highlight blockers; follow up on any to do items generated from the discussion. WIP Limit Warrior: monitor work-in-progress limits; assist or coordinate assistance to Quality Assistance team as needed;
28. Team Roles We also have some additional fun roles in there.
29. Vacation Time • You can always take a vacation when you need one • Just give your teammates advance notice (because we’re a big enough team, others can pick up slack)
30. Vacation Time system to keep track of who is out when, check this before we plan our trips
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 Fridays are hack days: work on whatever you like, learn what you’d like to joining with teammates —> sharing knowledge from client app (will be some times when we’d like to work on Friday)
32. Sick Days It happens. Sick days happen.
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 Sickness moves quickly: we’re a big team in a small space in an open office, so we share lots of things
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 We’ve been working with our client for almost two years, always making changes I joined during a lull in the project, for example, while Anne joined when things were incredibly busy
35. Onboarding • We use a team manual to help with onboarding • Also have a project wiki Team manual = Google doc containing need-to-know information Project wiki on GitHub, with instructions for getting project up and running as well as info about dependencies, code style, testing, etc.
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 1) Again, changes due to where team is in development 2) Varies with incoming developer’s skill level and other developers’ willingness to teach, as well as their work styles 3) Fact of life that not everything will be encoded into law, like the way we work and how we handle pressure, but there are also things that everyone has just gleaned from getting on the project when it was smaller.
37. Pairing Pair programming: 2 devs solving the same problem together at the same time Could be on the same keyboard/mouse Or each have their own keyboard and mouse Multiple monitors can help too
38. Why pair? • Pairing is a great way to transfer knowledge to new team members • Beats the traditional RTFM approach or “jump in and learn to swim” Helps you focus
39. Preventing keyboard hogs Make the more experienced person navigate and the less experienced one drive • New person should be asking a lot of questions - “WHY?"
40. Ping pong • 1) Person A writes a failing test • 2) Person B makes it pass • 3) Person B writes a failing test • 4) Person A makes it pass • 5) Repeat • Works really well if you’re doing TDD already or want to learn how to do TDD because it separates the test from the code
41. Switch up pairs • Switch up pairs frequently ◦ Our team switches pairs as-needed, but there are other options ▪ When the card is done, find someone else who just finished ▪ Works well when all cards are about the same size, but chances are, the pair will be sticking together or waiting around for another pair to free up ▪ When the sprint ends ▪ All of the pairs should be done with their cards if the sprint was planned well ▪ Can give pairs more time together, which could be a good or bad thing depending on personality ▪ Daily - one person stays with the card, and the other one joins a different pair already in progress or on a new card (promiscuous pairing) ▪ Gives a lot more exposure to different parts of the app ▪ Forces someone to teach/explain what was worked on, thereby making sure they know it better, too ▪ Can create churn to bring someone up to speed every day
42. If all else fails…
43. Remote pairing • Detroit Labs is remote-friendly, plus we have an office in Ann Arbor, Detroit but we still need to collaborate with people in real-time • Tools ◦ HipChat has built-in video conferencing ◦ Google Hangouts ◦ Screenhero* (invite only right now) ▪ Easily lets you both type in the host’s app • Same keyboard hog rules apply
44. Pairing: Phew! • Pairing is exhausting - you’re always on - either typing or navigating and hopefully having engaging discussions • Pomodoros are a way of allowing yourself to take a break periodically to refresh/recharge • Named after a tomato-shaped timer the inventor used to track his time • Set a timer/stopwatch ◦ Set the Pomodoro (timer) to 25 minutes ◦ Work on the task until the timer expires; Record with an X ◦ Take a Short Break (5 minutes) ◦ Every four "pomodoros", take a Long Break (10 minutes) • There are lots of apps out there UP NEXT - WILL & CHALLENGES
45. Process
46. How the magic happens Sufficiently advanced technology… All the fuzzy stuff is nice, but how do we actually work? What happens day to day?
47. What do I do? • Sprint Planning • Card wall • Swim lanes • Columns for Backlog through to Done • WIP limits • Stand Up We work in sprints—both in release sprints and weekly sprints. We have a sprint planning meeting where we review the cards that we are pulling from the backlog for open questions, blockers, comps, whatever. We use a digital cardwall (Jira, if you are curious) and have separate swim lanes for iOS, Android, and QA. We also have separate columns for Backlog, Selected for Development, In Progress, PR, QA Ready, In Testing, and finally DONE. We try as much as possible, to work on features in parallel. We put WIP limits on the in progress, pull request, and QA columns. That’s great, but what do I do? Well, we have a daily standup, usually takes 10-15 minutes, where we discuss what’s going on today on the team. We recently changed up how we do it—previously, we would go through each column and review the status of each card, column by column. That worked for a while, but what we found was that individuals were getting a bit lost. So now we do a more traditional, what are you working on style of standup.
48. How do I do it? • Forking • Feature branches • Code reviews/pull requests We use git for version control and to keep from killing each other. Everyone forks the main repo, we build feature branches for the card/task we are working on. When the feature is complete, we open a pull request. On iOS we try to operate on an open one/review one system for PR’s. Other dev’s do a code review, leave comments and questions, and eventually when everyone is satisfied, the code is merged into the master branch. Some advice: don’t take the code review personally. It can be hard, especially if it drags on, but the point is Best Code Possible. This project is almost three years old and has complete turnover of developers. We’re referring it to Code-nado for a reason.
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 We don’t consider a feature “done” until it meets certain criteria. It’s not “done” when we are done coding, or done even when it’s been merged into master. It’s not done until it passes QA. And that means our burndown charts don’t change until a feature has been QA’d. This is a little frustrating, since from the dev pov, it seems like it delays getting “credit” on the burndown chart for work complete…but once a feature/card crosses that line, you can be reasonably certain that you’ve seen the back of it.
50. What does it mean? • Big & Visible charts • Burndowns • Number of days left in sprint Since we are a pretty big team, working on two platforms, it can be kind of hard to see or feel progress. So we make it super visible. At standup every day, we have a bunch of different visuals for our progress—a burndown chart showing progress vs. deadline; a circle graph with cards in each column; a bar chart comparing progress vs. time remaining in the sprint vs. scope change. We just added a chart that shows when we will finish at our current velocity. Everything is big and visible.
51. Automation HipChat: automates roles. one of our developers created a hubot script to shuffle the roles at the beginning of every week. You saw this in the last slide. Crashlytics: automates builds. with so many people committing code, need to ensure changes don’t conflict or break the build Jenkins: automates tests. as soon as we commit work to team repository, we can see if it would fail tests
52. Automation • Challenges include: • CI failures leading to false test failures • ownership CI failures: when there are problems, it takes a long time to fix that takes away from development time. Ownership: one part is, Who will handle issues that fall outside of a specific role? We also need to stay sharp and make sure that we’re not succumbing to a “that’s not my problem” attitude because there are specific roles. UP NEXT - Chris T & Estimation
53. Estimation sucks. Estimation costs money Doesn’t deliver value to the product Estimating everything up front is very waterfall Estimations are often wrong
54. Waterfalls. Don’t chase them. Waterfall: if you haven’t heard of it, you’re probably doing it. Process of development where each stage needs to be complete before the other can begin requirements -> design -> estimation -> development -> testing -> release
55. Invite the entire team ◦ Get any questions answered quickly ▪ If you can have a product owner in the estimation - even better! (We don’t have that) ◦ Unfortunately, estimates are commitments - do not want a select few making all the commitments for the team ◦ Normalize estimates across different experience levels ▪ Get information about parts of the app you don’t know about from people who do (where are the dragons?) ◦ Everyone gets an idea of what we’re trying to build, so that when it comes time to pick up a story, the dev is not completely in the dark ◦ Estimation sucks - share the pain
56. Planning poker • Vote 1 - 10 points by using your fingers ◦ 2 pts = 1 day for 1 dev pair • Only devs vote ◦ Account for time from Dev to Done - including PR/QA time (when we remember) • Everyone gives their vote at the same time (for both platforms) ◦ Gets a little crazy to count • Talk about any outliers - someone has a 5 and someone has a 1, everyone else at 3 - why? • Usually end with a rough average or a little higher to give ourselves some buffer • Why? ◦ First impression/gut feel - if it seems hard or there are unknowns, it will show ◦ No one anchors ◦ Fairly easy to mentally box what you can do in a day vs what would take you a week
57. Time box estimation sessions • Need to assign a time-keeper/someone to move things along • Set a timer for 3 minutes • Punt if we don’t have enough info at the end of the timer • Avoid implementation details • Why? ◦ Estimations cost money/time for the team ◦ They are not fun ◦ Too many meetings already
58. Go as high level as you can • When planning on the work for a quarter, or a year, go very high level ◦ Weeks, not days • As you get closer to the time you’re going to start the work, be more granular
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. - All kinds of things affect velocity and scope, a couple people out sick, good weather, bad weather, slow internet. - Consistently showing changing scope and lowered velocity is probably an indicator of deeper issues, and should not be ignored. This isn’t just the Delivery Leads job, either. Step up and say something.
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.
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”
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. LAST SLIDE - UP NEXT - QUESTIONS?!
68. Questions?
69. Tweet at us! Anne Cahalan @northofnormal Chris Trevarthen @malusman Kyle Ofori @KyleOfori Will Hinchman @hinchable