An EarthVectors developer’s life
I was inspired by Lisa Crispin’s post, A DAY IN THE LIFE: TESTING ON THE TRACKER TEAM, and wanted to share how we work on the EarthVectors development team.
While engaged with ATHN, a non-profit serving the hemophilia and thrombosis community I was a part of the small 6-person development team located in Denver, CO. We previously worked with Pivotal Labs, and we are lucky enough to share space with them as well as the Pivotal Tracker team. We get some amazing perks.
In fact, we start our day with catered breakfast.
After breakfast, a cowbell rings signaling us that it’s time for Pivotal standup where we get to meet new people, share helps, interestings, and events with each other. I love being involved in Pivotal standup. We often hear things about technologies that we would otherwise have no exposure to, especially given that we are such a small team. It’s amazing how much you can pick up just from overhearing other people’s problems and solutions.
Next, we head to our EarthVectors standup, where the six of us join a meeting with the remote portion of the technical team. Standup is a time to briefly share what we did yesterday, but mostly talk about anything interesting or surprising that came up. It’s also a time to share design decisions we made and get input from the rest of the team. We have ad-hoc “dev meetings” throughout the day to help make design decisions as well to foster joint ownership of the code.
Because we work in pairs, standup is presented as what “we” did, “we” discovered, “we” would like input on. It’s a subtle but amazingly effective way to build a team and ownership of the code and product.
Something we do a little differently is IPM (iteration planning meeting). Instead of a formal, scheduled meeting to review stories, we do it as needed. After standup is a good time to do a checkpoint and make sure we all have enough work to do. If not, we discuss and estimate enough stories to make sure we keep the flow going during the day. We only have three point sizes, and some of them don’t count.
We estimate stories as 0, 1, 2 or 3. But a 0 and a 3 are exceptions. Most stories are 1’s or 2’s. We don’t argue about point sizes for very long, we just make sure everyone has the same understanding on level of effort, complexity, and unknowns, and then reach a consensus between a 1 or 2. In the end, we know that the points sizes are just estimates. Accuracy is not the end goal. Splitting a story that’s either bigger than a 2 or that would be easier to deliver in pieces is common. This helps us get feedback as quickly as possible. Yesterday we split two stories. Although their point sizes didn’t change, we divided them into different slices so that we could deliver the most complicated part first. We could then make sure it looks and works correctly. Subsequently we can deliver the next story that just adds more of the same type of logic.
Speaking of iterations… we have them, technically. I think our Pivotal Tracker project is setup for weekly iterations starting each Monday. But it really doesn’t impact how we work. Velocity tracking is just for rough planning purposes. We don’t commit to any stories or numbers of stories in any given timeframe. We estimate stories. Our PO uses those estimates to plan releases, and we release whenever it makes sense. If there is a critical deadline, we work together with our PO to figure out the best way to prioritize those stories first. Functionality is pruned if required. The biggest goal is visibility. If a story is estimated at a 1 and we realize it is more complex than we thought, we have a conversation. That story could be split further, the complexity could be removed, or a simpler way suggested.
After standup, we have a habit of walking across the street to a nearby Metropolis coffee. It inspires jealousy in other teams, but there is something about taking a few minutes to connect with each other before we dig into our workday in earnest. Difficult problems from the previous day are often resolved on this walk.
When we return, we have a quick discussion about the pairs for the day. We work in pairs all the time (except when someone’s out). Rotation is a balance between keeping someone on the “stream” that has context and filling our dance card for the week. We try to make sure we all are exposed to every part of the system. The pairs are mixed up to keep fresh ideas flowing and maintain balance within the force. Streams are feature sets that group stories together. Since there are six of us, and we work in pairs, there are three streams going at any given time. Sometimes, two pairs will jump on the same stream to get it done sooner. Usually, each stream is separate and this allows us to avoid merge conflicts and inter-pair dependencies. We’re all working on the same system, but different vertical slices of functionality.
With pairs decided, we get to work. Mihir and I paired today on a new feature that David and I worked on yesterday. Yesterday, David shared context with me, and today I passed that along to Mihir. Tomorrow, I expect Mihir will stay on that stream to share context with someone new while I join someone else and pickup context from another stream. This is how we avoid silos, jointly own all the code, and pass context of new ways to do things to each other. It’s amazing.
Throughout the day, whenever a pair feels they could use more input, they ping the entire team. We sit at open pairing workstations, so an impromptu dev meeting involves finishing your current thought and swiveling your chair to form a circle. We’ve somehow managed to create an egoless environment where everyone values and wants input from everyone else. Today, Lew and Joe pinged the whole team to share tips about the rspec upgrade they were working on.
We usually play ping-pong once or twice during the day. It’s a great way to take a break, especially when stuck on a hard problem. Although it’s hard to tear yourself away, usually one of us will be thinking clearly enough to suggest a pong break. We almost always come back with a better plan of attack, even if that plan is to call a dev meeting for help.
When lunchtime comes around, sometimes we grab food and find a conference room to watch an episode of something interesting on Netflix. We informally reserve Fridays for team lunch out — a good way to connect and unwind.
In the afternoon, it’s back to work! We use TDD to design and develop. Finding better ways to design code and test it are frequent dev meeting conversations. When to stub? What to cover at a unit-level vs. a higher-level test? We’re constantly making new “rules” (my word, others will dislike that word choice) that we try out and revisit often. We’re not afraid to experiment, but we make sure we’re doing it as a team. We’ve posted our team values if you want to know more.
That’s our typical day, but I may not have described the fun very well. If Andrew’s not cracking us up, then we’re poking fun at each other or ourselves. It’s definitely a balance we’ve achieved between having fun and producing a ton of high quality work. We do both really well.
