In the transition to agile, one issue some development teams come up against is that their organization has large developer groups that report to a single manager. This poses problems because agile works best with small, self-organizing teams. This was the case on my most recent team, but we were able to solve the potential trouble by creating smaller groups, which we named code factories.

Code factories differ from more common feature teams because the teams stay together for more than just the duration of development for a single feature; they are assembled around a specific product and stick with that product as long as it exists. If that product goes away or no longer needs the same level of attention, the teams will either be assigned a new product or take on a portion of another code factory's work. In the latter situation, the team remains an independent, self-organizing entity; the new work would fall into the existing sprint structure and be a part of its velocity, just like any other story in the backlog.

My team supported several different products for one uber product owner. The uber product owner was involved in each and every decision. She had control over every product line supported by the development group, she was the one selecting the stories played in each sprint, and she was present for all end-of-sprint review sessions. If someone on the business side wanted their particular product line to have a story played (in the old, pre-code-factory system), they had to convince the uber product owner that it was worth her spending the time or points on that story.

In this environment, it was difficult for the developers to take on new stories because they were not always for the same product. This increased the time required to complete each story due to the need to refamiliarize themselves with the product they were working on.

The organization recognized these problems and decided to run an experiment. There was a new product the business sponsors wanted to create, and this was the perfect opportunity to try something different.

They chose a new product owner to lead the new product line, and a new development team was created, with half the people coming from existing teams and the other half being new hires. The development team had its own ScrumMaster, business analyst, and quality tester who were placed directly with the developers. This team was given the task of creating the new product's first phase. After that, the future of the team would depend on how well the experiment went.

Over the first few months, it was clear that the new model was a huge success. The team was able to complete more work in a much faster manner than the original team was able to. While the value of points often varies slightly between development teams, the new team was able to complete more story points per sprint than the original group, with roughly a third of the developers.

There was a sense of ownership in the developers that was much stronger than the original team, and the connection between the development team and the product owner was more dynamic and active. All the developers still reported to the same manager, but that manager didn't get involved with the day-to-day operations of the team. The ScrumMaster handled that aspect, making sure the team stuck to the principles and guidelines of the original team, along with any new ones they adopted during their regular end-of-sprint retrospective meetings. The ScrumMaster was also responsible for providing regular status updates to the business during the sprint. The business analyst ensured that there was an active dialog with the business team and worked to make sure there were always stories in the team's backlog.

Both the development group and the business team were very impressed by the improvement in the process by having a dedicated development team on this new product. The team knew the product in much greater detail and was able to anticipate issues during grooming that would not have been noticed before. There was also a strong bond of trust between the product owner and the developers, which allowed them to work together more closely than the original group.

Since the experiment was a success, the original group has begun splitting off new code factories for each of its existing product lines. Each code factory has its own developers, business analysts, and quality testers, and ScrumMasters are responsible for two to three code factories. Each code factory also has a technical lead who ensures that technical standards of the development team are being followed, as well as works to remove any technical blockers and mentor new team members in the specifics of that code factory.

In order to address burnout, there's also a plan to slowly rotate developers through the code factories. Every few months one developer will be taken out of the factory and replaced with a developer from a different factory, giving the team an opportunity to practice adding new team members and losing existing team members. It also means that standards and practices one code factory implements will be spread throughout the full group over time, ensuring that all factories have an opportunity to learn from each other.

As for the uber product owner, she oversees the new product owners for each code factory to ensure that the decisions they’re making align with the organization’s vision. She provides mentoring to new product owners to help them quickly come up to speed on their new responsibilities and continues to act as product owner for a small number of code factories, but her direct responsibilities have lessened overall. Consequently, she can focus on her own work more and provider quicker feedback to the code factories she’s directly responsible for.

No one solution is perfect, but code factories seemed to provide my team with the flexibility it needed to meet the needs of its business sponsors while following the structure of the organizational hierarchy.