Had the pleasure of hanging out at Pivotal Labs last Monday. Been a longtime fan of Tracker -> http://www.pivotaltracker.com/testimonials (scroll to bottom).
Dan and I went to learn more about how they pair program (they only pair), best practices and how to get ninja with tracker. Notes from our jam session with Rob Mee (Pivotal CEO and Founder) below.
Morning in the life of a PivotPivots (what they call team members) start their days at 9am with a catered breakfast and company stand up. Awesome! Not your traditional, what did you do yesterday stand-up, cause that would be hugely ineffective, but a what have you discovered that's new / cool, what are you having trouble or need help with, kind of stand-up. They blog these morning standups.
Afterwards Pivot's break into their teams and do a more traditional stand-up.
Be like Da VinciAll Pivots are full stack capable i.e. front end all the way to backend dev. Allows them to on-board, off-board Pivots with client work relatively easily because anyone can work on any project with any other partner.
I think this kind of flexibility is also crucial for startups. Rob talked about how development in the 90's used to get split up Backend vs. Frontend which became a standard practice. The reality is: separating teams base on vertical slices of product is a lot more productive.
Optimal team sizeWhen you have a pair, they're effectively 1 brian, 1 problem solving machine. As soon as you add another pair, you jump to 6 brains / 6 problem solving teams. The productivity gain is massive and once you jump to 3 pairs then communication starts to hinder productivity, therefore it's best to have teams of 4 or 2 pairs.
Best way to pair remotelyRob shared one of his secrets (not much of a secret anymore) when it comes to effective remote pairing it's based on Einstein's quantum entanglement theory, forealz.
If 2 people are going to pair remotely, first bring them together for a week or two. Then when you separate them they'll figure out how best to recreate the IRL dynamic remotely.
Startup take aways
- Have morning standups for whole company around breakfast (9am); forces developers to eat a good breakfast and have productive mornings
- Have teams hold short standup after company standup
- Hire developers that can go all the way, startups are too young and there's too much shit to get done, with people who specialize
- Break teams into functional slices
- 2 pairs are better than 1 is better than 3
- If you're gonna pair remotely, first bring the pair together IRL
Big thank you to Rob for his time.
