Developer Pairings within Bounded Contexts on Full Stack Teams

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.

"Forming teams along the same business boundaries made it easy to see the ideal approaches to the system architecture and features."

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."