Developer Pairings within Bounded Contexts on Full Stack Teams
17 December, 2018
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.
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.
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.
Marian Kamenistak, VP of Engineering at Mews, explains why EMs shouldn’t be measuring the output of a team or individual engineers, but the outcome of the whole team.
VP of Engineering at Mews
Shelly Bezanson, Director of Release at Thoughtexchange, discusses how early engagement through the Product Council coupled with a set of six key principles can help improve communication between different teams.
Director of Release at Thoughtexchange
David La France, VP of Engineering at Kenna Security, explains how to merge two teams with different cultures, technology and operating modes.
David La France
VP Engineering at Synack
David La France, VP of Engineering at Kenna Security, explains how managers can level up their skills and scale in their roles by learning to work less, but smarter.
David La France
VP Engineering at Synack
Anoosh Mostowfipour, Founder at ReferralsLink, recounts his experience developing and implementing operational software that helped him achieve the much-desired transparency and improve coordination and collaboration across the company.
Founder at ReferralsLink
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.