Creating High Performing Agile Teams

Written by Janet Kim, Danny Chung & Esther Sportello — October 2018

Over the past year and half I’ve had the pleasure and honor of leading (without authority) a kick-ass development team. We started with an idea, created a low fidelity prototype, and ultimately launch an MVP into pilot, building it ground up. The foundation of the team was built on trust and respect which lead to high performance and having some fun along the way. We wanted to share some of our best practices in hopes that they could be helpful to your team.

One of our designers, Janet Kim, led the charge in synthesizing the tangible practices and norms we developed, which are included here.Thanks Janet!

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

The Hubble team (our top secret, but not really, code name) fostered a collaborative, fun, and safe team culture, we genuinely enjoyed working together. Here’s a photo of us at a team Fun Day, celebrating hitting a product milestone by going on a tour of the Secrets of Coney Island:

Before I share the actual practices, I want to explain the motivation behind them. The Hubble team made fostering a great team culture a priority, equal to building a successful product. Our pod had the following goals:

1. Create a safe environment where all team members could work efficiently and effectively.
2. Give team members opportunities to continue to grow in their areas of interest.

With that lens, the team continually experimented with different ways of working. Below are the practices that stuck and contributed to our success as a team.

Standup . . . and Post-Standup

Almost every day at 10am in room 4013, the team met for Standup. The room was reserved for 30 minutes. Despite the fact that team members were co-located, standups were the primary forum for the continuous thread of communication for our team.

• First ~15 minutes: Each member briefly shared with the team any blockers, yesterday’s accomplishments, and plan for the day.
• Minutes 16–30 (if needed): We called this Post-Standup. Time to discuss any topic raised during standup for a deeper dive (which we recorded on the whiteboard). This could be asking for an explanation or clarification or gaining consensus involving 2 or more team members. Team members were not required to stay if the Post-Standup topics were not relevant to them.
• Keeping it short: If a team member started to get into a longer discussion or went off topic (which often happened Monday mornings), other team members were encouraged to interrupt by saying the word “cucumber.” Cucumber became a non-aggressive way to keep us on track and make sure standup was short and sweet.

What we loved about these twists on traditional standup:

Beginning standup with blockers quickly made others aware of where assistance was needed most and which areas were prime for pair programing or team swarming.

Post-standup gave every team member the time and space to ask questions and gain a full understanding of the work they and others were delivering.

Our team leveraged the Kanban working style. When we hit work in progress (WIP) limits, individuals waiting to get their tasks approved could use Post-Standup time to volunteer to pair with others.

Often topics that got “cucumbered” would end up on the whiteboard as a Post-Standup topic. It became a quick and easy trigger for us to identify what areas needed more discussion.

Collaboration

We are all here to learn from each other, each bringing a unique skill to the table. As such we placed a ton of emphasis on collaboration doing it as often as possible.

• Kanban and pair programming: For context, at the point when the team was the largest, there were eight code contributing team members. At first, the Kanban WIP limit set in JIRA was a nuisance to some developers. There would be times that an individual finished the body of work (s)he picked up but couldn’t move onto the next task because we were at the WIP limit. However, once we got into a flow, what first seemed like a hindrance ultimately fostered a hyper-collaborative environment. When engineers hit WIP limits, they would begin pairing and thus transfer knowledge across the full stack, ultimately making the team more fungible as a result.
• Designer/Developer pairing: Rather than adding detailed specs to mockups, which is extremely time consuming and redundant when there is a design system with specific components, the designer provided visual design mockups in InVision to the developer, who used the design system components to implement the designs. Once the developer felt confident, the designer and developer paired to ensure that the designs were implemented correctly. The key was pairing before sharing the work QA or Product for final review.
• Shoulder Testing: After we lost our QA Engineer to another project, we did two things to make sure our code remained high quality. First, the whole team got trained on testing best practices and learned what it meant to put our “testing hats” on. Engineers incorporated the testing best practices they learned into their code review practices. Second, engineers got into the habit of calling product or design over to make sure things were good at a glance before final product review (see the “Designer/Developer pairing” section above). In hindsight, we should have started these practices even while our QA Engineer was on the team because they improved quality, collaboration, and would have freed up the QA Engineer’s time for higher-value work.

What we learned about collaborating often:

For Kanban pair programming to work, product and tech leads need to be fastidious about pre-prioritizing before grooming and every team member needs to be engaged during grooming as work isn’t preassigned. The expectation is everyone is able to jump into any task at anytime.

Pair programming worked best when one party was, ideally, a domain expert, and the other was learning opposed to both people being unsure about what to do and trying to solve the problem together in real time.

WIP limits reduced the amount of tasks in flight at any one time as well as reducing context switching. After the adjustment period the team grew to embrace.

All forms of pairing gave the individuals to swiftly address any additional tweaks reducing the number of times a task got passed back and forth between teammates, which lead to increased velocity.

Meetings & Ceremonies

Product AND Individual Goal Setting: The Team discussed quarterly product objectives as well as desired individual team learnings during planning. We then aligned those to individual learning goals to product objectives and set clear expectations on which we were going to prioritize now vs later. This helped the team coalesce on technology and architecture decisions as well as help individuals find ways to acquire new skills. It also encouraged individuals to think about their learning objectives and express them with the team.

Retrospectives: We held retros about once a month, religiously. NEVER skip retro. When things get crazy or timelines condensed it’s easy to pause retro routines, however this is the time they are probably needed the most. We used two methods.

• Method 1 — Effective Things: The team would list things that happened since the last retro that made them either happy, sad, or ambivalent.
• Method 2 — Engines & Anchors (good for release retros): The team would list engines (things that contributed to success, collaboration, or happiness) and anchors (impediments), focusing on the whole delivery timeline.

With both methods it’s important to remember to focus on positives rather than just focusing on fixing problems, we also highlighted and celebrated successes. We want to continue the great work and best practices just as much as we want to fix things that aren’t working.We followed a similar format with both methods.

• 5 min of silent topic generation: Silent generation of topics on post-it notes worked best to give everyone an equal voice. After the time was up, we took turns presenting our topics to the rest of the team.
• Cluster topics & vote
• Discuss topics: We would time box each topic to about 5 minutes or go through them lean coffee style. However we didn’t let time control the meeting, if there was a rich discussion happening we would continue on that topic until completion. Often times that meant we didn’t discuss every topic grouping, and that was ok.
• Follow up: As applicable, we ended each retro with action items to be done by the appropriate parties in the week following. We documented takeaways in a GitHub project board after each retrospective so that we had a digital record of what we had discussed. We started every retro reviewing action items from the previous retro and evaluate whether we committed to doing what we said we would and whether it was effective.

Debt Accumulation Tracking: We acknowledged when we were taking on tech and design debt and kept track of it in a GitHub project board. We allotted 20% of the teams capacity to addressing the debt. As items from the GitHub debt board were prioritized, we groomed them along with the functional requirements and move them into JIRA. This allowed us to keep a good handle on the debt and not let it accumulate.

Celebrating Successes: I made it a priority to celebrate successes big and small. This came in different forms:

1. Day to day: We would give each other kudos in Slack, during standup, and bubbled up the bigger wins to our team’s All Hands meetings.
2. Spot Awards: For special recognition when going above and beyond, we would send each other a Spot Awards. This is an internal peer to peer incentive program here at Capital One. For example, when a teammate stopped his work and helped design conduct user research, he received a spot award.
3. Team Fun Days: When we hit a significant milestone, we would have a Team Fun Day. Team Fun Day activities included group meditation at Inscape, Escape Room, bowling, and aforementioned Secrets of Coney Island tour.

There isn’t a one size fits all model, and every team needs to find the routines that work best for them. We found out what worked best for us by trying different things, rejecting what didn’t work. If any of the practices I mentioned sound interesting to you, I encourage you to try them out with your team. Finally, these sorts of best practices only work when a team understands the underlying goal and commits to adhering to them.

Shout out to Hubble team members, past and present, who all contributed to making Hubble Bubble a safe and fun space!