Great dev teams share small bites off of small plates.
by Scott Connerly
[if you prefer videos to reading: https://youtu.be/Dyc_v4GYUMU]
I’m gonna share what we’ve cooked up as the practical tactics for iteration and collaboration to make team awesome sauce.
I can’t help but write about food, even when it’s really about tech. Please bear with my meat-aphors. Also, I’m not in the least bit of Spanish heritage, I’m merely hungry for tapas.
We Work Iteratively
Minimum Viable Products are valuable.
We shouldn’t try to make paella right out of the gate. Paella has SO many ingredients and takes SO long to simmer down properly, not to mention can be made SO many different ways. Our clients are hungry now, so let’s first serve them up a smoked chorizo and cheese plate, then some patatas bravas, and then a plate of croquetas de jamón. Similarly, MVPs (Minimum Viable Products) are great, partially because of how quickly you can serve them up.
When I say MVPs, I mean really stripped down, bare-bones, sometimes ugly, barely useful features that make product owners hunger for another pass at it. Do enough of these and you’ll earn the right to make these into v2’s and v5’s (paella).
MVPs are valuable to customers, because they can finally do that workflow they’ve been waiting for months to do. Even if it’s just a nibble of it.
MVPs are valuable to other departments in the organization, because there are usually SO many competing priorities (delicious, delicious tapas) on a roadmap (menu). Roadmaps are full of a wide variety of things sales needs, things customers need, tech debt that needs to be paid down, not to mention strategic new features leadership needs. By sampling several small dishes, we can keep everyone well fed and satisfied.
MVPs are valuable to product management because when we deliver that bare bones first version of the feature, the users tell us if they like the taste or not. Their feedback helps us design the next dish. We may think a sharing feature would be most useful, but the clients may resoundingly tell us a privacy flag would be most useful, and they have a sharing allergy!
Tickets and PRs should be bite-sized.
Ideally, a ticket can be completed in one day (or less). If a ticket is taking more than two or three days, you bit off more than you can chew. Stop now, spawn child tickets, and do a pull request (PR) with what you’ve got. Not every ticket can be a 1-point ticket, but it’s a good goal.
A ticket is a checkpoint on the road to a feature. Not every ticket results in a story or workflow; many tickets just create building blocks. CRUD is rarely all in one ticket.
PRs should aim to be under 250 lines long [1]. SmartBear did a study that at 400 lines of changes or less, a PR can be effectively reviewed in under an hour [2, p87]. The study doesn’t specify if a +200 -100 line change counts as a 100 line change, 200, or 300, but I like to only count lines added.
Frequently deploying to production is a great thing.
Delivering food to the table shouldn’t be scary, it should be small, easy, routine and frequent. More frequent means smaller amount of changes. Smaller changes means lower risk. Lower risk is great! Also, the number of team-disrupting hot-fixes drops to zero, because even if you have an urgent deploy, it’s second nature.
Food not on the table provides value to no-one. Think of it like compound interest, and every deploy to prod is another deposit in the savings account. The value grows slowly over time, and is always delicious.
Similarly…
An epic should be deliverable at most any time business calls for it.
Features are added iteratively (and production deployed) as time allows.
For example, at first, new data models might have only 3 columns: id, created, and modified. Deploy that. Next, you might add a Title and Description and the ability to edit it(and test and deploy that). Then you might add [tiny feature 1] (and test and deploy that). You then make it through halfway through [killer workflow 2], but business priorities change, and your focus has to change. No problem, users already have [tiny feature 1] and love it! Yes, branch #2 dies on the vine. And that sucks. But at least the rest of the work is already in use!
We Work Collaboratively
Pairing and PRs are Essential.
Have you ever worked in a restaurant? Waitstaff, hosts, and the kitchen all totally have got each others’ backs, clear the way for each other, and pitch in when needed. Similarly, unblocking your engineering teammates is pretty much the most important thing ever. Nobody should ever feel like they’re going it alone.
Pairing and PRs (Pull Requests) are more than bug prevention, they are an opportunity to learn. PRs with requested changes should initiate a pairing session. Pairing’s also great because sometimes its like a chef / sous-chef relationship.
Both proactive pairings and PR pairings should be time-boxed. Use the Pomodoro technique for your time-boxing if it’s helpful (which, you can guess, I love is named after the tomato-shaped kitchen timer).
Keep git clean.
Git is our kitchen. Keep the kitchen clean. We can’t just leave raw meat laying around at our station. Clean up after yourself. Commits should be pushed up to origin frequently, ideally no less than daily. Stashes older than a day should be deleted or committed.
Also if something happens (the fryer catches on fire?), others can pick up where you left off (those carrots aren’t gonna chop themselves).
Git history shouldn’t be re-written. The team wants see the approaches you’ve tried, even if they didn’t pan out. Git history also gives visibility to the effort you’re putting in.
Tapas are Life
My wife and I were lucky enough to have an excellent honeymoon in Barcelona. We’d never been to Spain and were excited. Our first dinner in town, we went to a place, didn’t really understand the menu, didn’t discuss it enough, and harriedly ordered what turned out to be a sampler platter. It was meh. It was REALLY expensive. We walked away very unsatisfied. Dinner agility fail. We learned our lesson, and every place we ate for the rest of the trip, we ordered patatas bravas, while we decided what we wanted next. Iterative and collaborative. Delicious.
Come work with us :D
