We've just launched plato for individuals

🔥

login


Google Sign inLinkedIn Sign in

Don't have an account? 

Developer Pairings within Bounded Contexts on Full Stack Teams

Collaboration
Productivity
Reorganization
Scaling Team

17 December, 2018

Courtney Hemphill explains how she restructured a siloed scaling organization into a collaborative and productive team.

Problem

A company that I was working for was rapidly growing and expanding. We were brought in to help with that growth and also to help with the hiring. The team had been scaling up so we provided the collective team with senior leadership and full-stack developers. These developers possessed skills across the spectrum, but of course, they either skewed a little bit more towards the front-end or the back-end. Due to the desire to gain velocity, the team was split into their skill sets that seemed to fit them best. The problem was that the team ended up being quite siloed and so when features, tickets, or stories would come up the team would work on their piece of the pie and then try to implement it to the best of their knowledge, but in isolation of the rest of the team. Even with contract testing there were quite distinct barriers between the various back-end services, the APIs, and the front-end angular client. We, essentially, began to see a lot of friction between the front and back end teams and too much revisiting of code deployed.

Actions taken

We had to convince the business, mainly the head of product which oversees the group, that we needed to shape the teams around bounded contexts relevant to business needs. Given that the business had enough distinct priorities and requirements to meet, forming teams along the same business boundaries made it easy to see the ideal approaches to the system architecture and features. The teams could then take on domains of ownership, for example the billing team and the quoting team, and interactions between the teams became a more natural service provider-consumer dynamic. We covered any skill gaps in the teams by pairing front-end developers with back-end developers, and together they would work on full-stack stories. The team, now organized against the business needs, was able to work in small units, each unit owning stories from the back end data modeling and architecture to the front end integration and customer experience. This allowed the entire group to operate more efficiently, cut down on rework, and reduce the amount of stories in the PR queue.

At the beginning of this reorganization, there was an expected decrease in performance because of the need to isolate and extract out the unique business concepts into separate backlogs and areas of the code. We observed something similar to Conway's law, that the design of the system was reflecting conversation patterns across the teams. So during the transition, the teams were less performant and there was a dip in perceived velocity (stories including bugs delivered). However, as a result of the pairings, we saw a huge drop in bugs and stories created to capture rewrites. So we actually saw a gain of velocity over the next two weeks in regards to functional stories delivered as opposed to bug fixing and rewrites. Additionally, the team members began to learn from one another and we found that we could do pragmatic pairings. Also, because of their new gained knowledge people could actually take on full-stack stories independently from one another and so stories were getting done more quickly over time. It made allocation efficient, as well as the completion and deployment of tickets far easier.

The whole process of restructuring the teams took about three months. In that time we worked on the system to find the boundaries that were suitable. We also initiated some architecture work to ensure that the contract testing between different groups was appropriate. Last was the formulation of the units and the structuring of the team. Included in this structure was independent stand ups for the teams every day with a weekly group meeting showcasing their completed and deployed work, issues that came up, and any questions for QA. After all of the hard work that was put in, it took about three weeks to establish a smoothly run cadence.

Lessons learned

Ensure that you have sound reasoning and a distinct need to go to the business and request a team restructuring around business needs. Get people to first understand and agree to the benefits and why it is better for the company and the customers. Understand the costs and potential hit to velocity. Full time pairing can be hard to get buy in for; but pragmatic pairing at ideal opportunities comes with a wide variety of benefits including skill development, knowledge sharing, and code quality. Explain to them why you're making the shift and show them that the time and money spent on both organizational and architectural structures will be highly effective for the business and for the team in the long run. An interesting byproduct of this process was team happiness. First, because internal communication amongst the team improved. Second, there was a pride of ownership around features that were deployed. People started owning the set of work that they did and the success of that work directly correlated to the success of the team and to that of the business.


Related stories

How to Set Up a Bi-Directional Roadmap
19 October

Fei Xu, Engineering Manager at Square, Inc., explains what are the advantages of a bi-directional roadmap and how to set it up right.

Roadmap
Collaboration
Fei Xu

Fei Xu

Engineering Manager at Square Inc.

How Restructuring Can Help Your Team to Claim Ownership
19 October

Fei Xu, Engineering Manager at Square, Inc., recalls how he approached the restructuring of his team with an intent to have them claim ownership and develop subject matter expertise.

Reorganization
Ownership
Fei Xu

Fei Xu

Engineering Manager at Square Inc.

Introducing Processes for Continuous Improvement
30 September

Peter Berg, Founder and CTO at Forward, recounts how he introduced processes for continuous improvement and thus creating a more psychologically safe working environment.

Impact
Productivity
Coaching / Training / Mentorship
Peter Berg

Peter Berg

Founder / CTO at Forward

The Quick Fix to a Slow Team: A Consultant’s Perspective
30 September

Peter Berg, Founder and CTO at Forward, describes how he helped ramp up a slow-moving team by applying his simple, yet expert approach.

Team processes
Delegate
Productivity
Agile / Scrum
Peter Berg

Peter Berg

Founder / CTO at Forward

Networking for Product Leaders: A Giving Mindset Approach
30 September

Caroline Parnell, previously managed product teams at O2 and Vodafone, emphasizes the importance of networking for product leaders and giving in return some value to her peers.

Personal growth
Collaboration
Impact
Caroline Parnell

Caroline Parnell

Most recently Head of New Product Innovation at Previously O2 and Vodafone

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.