Journey to becoming a Product Team

Note: this is a real case study, the names of the organization and key players have been changed/anonymized per their request.

In the late 2000's, a large, traditional Belgian parcel delivery operator had begun experimenting with Agile ways of working for a few of their IT teams. This was not a strategic decision taken from the top of the organization, but rather an initiative from a couple of middle managers in IT who were growing increasingly frustrated with the delivery problems they were experiencing with their teams.

One of the areas experiencing some of the biggest problems within IT was "Tracked Mail". There were approximately 23 people in IT Tracked Mail working on a variety of applications to support all of the services connected to the tracking of deliveries. Within the organization, they serviced primarily two business units:

• Mail Operations (the people running the sorting centers, where the packages get triaged and prepared for delivery)
• Key Accounts (the account managers handling business customers interested in tracked mail services)

Tom was the IT manager responsible for the Tracked Mail deliveries, and he knew things needed to change. He sat down with both business units so they could align on a way forward. First, they aligned on the core problems they were facing:

• Late deliveries and lack of clarity on progress (too many bad surprises)
• Overly complex architecture (too many technologies)
• Buggy applications made production releases a stressful period (>1 month)
• Low team morale

Tom then proceeded to explain his plan to turn things around - he wanted to experiment with Scrum as a way of working. Tom didn't know much about Scrum, but he had heard about it in a conference and had subsequently hired an Agile coach that started helping him understand how he could start changing. This coach helped him explain Scrum to the business units and why it could help them.

The business units were skeptical, but they recognized the problem and didn't have anything better to propose. Also, this was Tom's initiative, so they couldn't be blamed if something went wrong… so they agreed to start a small experiment. No changes on the business side, but the IT teams would start working in Scrum. There would be a Product Owner from IT who would align on priorities and progress with the business units.

A bumpy start

The initial setup for their start with Scrum was rather simple. Since the Tracked Mail teams were delivering value for 2 business units, they wanted to split up the teams in this manner. So they created 2 teams (approx. 11 people p/ team), one focusing on Mail Operations requests, and the other focused on Key Accounts requests. There was one Product Owner (from IT) aligning the priorities of both backlogs with their respective business unit leads. The Agile coach Tom had hired was working as the Scrum Master for the two teams. This team split also made sense technically, since some applications were exclusive to a specific business unit.

To the dismay of Tom and the business stakeholders, the first 2 Sprints (2-week Sprints) of the teams did not go very well from a delivery perspective, as the teams didn't manage to finish many items. It felt like there were more problems now than before.

However, Tom noticed something had started to change. Before they started their first Sprint, the Scrum Master had managed to convince the key business people from both units to attend the first couple of Sprint Retrospectives. At first Tom didn't think this was a good idea, but now he started to understand why. 

Even though they still weren't delivering, the business units were beginning to comprehend the size of the challenge. It's not that they hadn't heard it before, but it was always a bullet point in some PowerPoint slide trying to explain why they were going to be late and over budget. Again. This time they were hearing it face-to-face, directly from the mouths of the developers. And they were confronted with the hard reality that there were no simple solutions. Any illusion the business had that IT was "unprofessional" and just required a little more pressure to pick up the pace had vanished. 

They were faced with highly competent developers who were more than happy to take the opportunity to tell them the facts:

• High technical debt - the Tracked Mail team had been under pressure for over 3 years to deliver quick fixes because the business never wanted to spend enough to have things done properly. On the other hand, the promises of "you guys will have time to do some refactoring later…" never materialized. So now the architecture is messy and they had a lot of legacy code, making future changes even harder to do.
• Poor engineering practices - since they never had enough time or budget to install proper tools and improve engineering practices, they were unable to adopt practices such as continuous integration. Instead they were working on parallel branches and essentially merging all the code during the User Acceptance Test (UAT) period, which of course resulted in all types of bugs.
• Inflexible communication with business - over 30% of the Lead Time of a deliverable was spent on the initial phase of gathering the requirements from the business. There was another internal department called "Solutions" which had been created to ensure alignment across the demands different business units were making of IT. And Solutions would spend 2-3 months in workshops with the business to define clear requirements and what had to be done (without IT). Afterwards IT had to estimate those requirements. And the result of this process was that during UAT bug fixing, when they were discussing a feature with the business, they were frequently finding out that they had misunderstood the actual problem. 
• Accountability but no power - the team felt they were being held accountable for the late deliveries and the quality issues, while at the same time being powerless to actually solve the rootcauses.

There were some tough conversations in those retrospectives, but both sides learned a lot about the other. Tom also began to realize that he had underestimated some of the senior developers in his team. They were quite capable of clearly explaining directly to the business the problems they had, and courageous enough to propose alternatives. And a way forward began to emerge:

• They would have 1 Sprint to work on some new tools they needed to improve their engineering practices. 
• They would have 10% of time every Sprint to invest in improving engineering practices (which the team used to dedicate one person full-time to manage all the tooling and configuration)
• Each business unit would appoint one person to act as their representative during the Sprint to answer questions from the developers or test some new feature (they called this person the "Business Lead")
• Dedicated person from enterprise architecture to work with the team on simplifying the Tracked Mail landscape

This meant that by Sprint 3, the operating model started to change. 

With the closer involvement of the two Business Leads, the IT person with the "Product Owner" title saw that their role began to change. Instead of being the only one giving feedback to the team on the features being developed, he was now helping to facilitate conversations between the Business Leads and developers during the Sprint. He still did the operational product owner work of keeping the product backlog up-to-date, leading estimation sessions with the team, and updating the stakeholders on progress and risks.

Growing an Agile team

What was the result of these changes? By the end of Sprint 5 they were starting to deliver at a fairly constant rate. Both the team and the business units felt like they had turned a corner. By Sprint 10, there was a considerable improvement when compared to their starting point. Specifically:

• Improving engineering practices - the team had made progress with some key engineering practices like continuous integration, defining clean code standards, peer review of code, and automated acceptance testing. There was still a long way to go, but the developers started feeling more confident about the changes they were making. And the business leads started having more visibility about progress.
• Collaboration with the business - the closer collaboration that started to grow between developers and business was a big change, and Tom could feel it. He was spending a lot less time in status update meetings, and more time solving actual impediments, like dependencies with other teams. Nobody was happy yet, but for the first time in a while Tom felt like there was a direction now.
• Roadmap for simplification - the fact that enterprise architecture had dedicated one person from their team to Tracked Mail was also very significant. Architectural decisions that had been taken 3-6 months before during the requirements gathering phase could now be reviewed together with the team during refinement. And if changes needed to be made because somebody spotted a better solution or because some of the assumptions they had taken before were no longer valid? They just agreed on a new design together and implemented it right away. And together they were creating their roadmap for simplifying the architecture and making the Tracked Mail application more resilient.
• Improved team engagement - the developers were starting to build trust on each other, and knowledge was being shared. There were some difficult discussions at times, and a couple of people were rotated to different teams because they weren't happy with the direction, but overall the 23 team members were engaged with their work, collaborating, and trusting the process. They had understood the change and bought into it. It was refreshing to see.

Despite these positive signs, some challenges remained:

• Financial crisis - the financial crisis of 2007-2008 meant budget cuts all around, and the business units had to reshuffle their roadmaps. This meant demand from both units started to vary. One month there was a lot of demand from "Mail Operations". Then their next project would be stuck in the budget approval phase for a few weeks and there was not much work for the team for the next month. The same would happen for "Key Accounts."
• Change of competitive landscape - as a business, this postal operator had benefited from some governmental protections, limiting the number of competitors in some of their markets. These protections were ending in 18 months, which meant there would be increased competition in their market space. So the business wanted to innovate and become more responsive to the needs of the market, to keep their market leadership. 
• Integration with other products - In order to unlock new capabilities and services, they needed to start integrating closer with some other key areas, such as "Delivery Rounds Management" and "Point of Sales". 

Tom sat down with the Scrum Master to discuss what options they had. Given the financial crisis, there was pressure on Tom to either start showing impressive results or to start cutting down costs (i.e. people). And they agreed on an idea - they would invite the business leads to a workshop, along with two of the senior developers. They wanted to ask everybody a simple question.

What is our product?

The developers had raised the issue in one of the Sprint Retrospectives that they felt a disconnect between the pitch they had heard about Agile and what they were actually experiencing. They were told this was all about customer centricity and focusing on value delivery, but what they saw were disconnected projects and business units arguing with each other about who was more important. With the permission of the developers, the Scrum Master chose to start the workshop by sharing this with the business leads. And he asked them if they agreed with that assessment.

There was some defensiveness, and the Scrum Master had a difficult time facilitating that workshop. Some "hard truths" were shared by everybody, but in the end they managed to reach an understanding. They agreed the current approach was more promising than anything else they had tried. And indeed trying to define their vision & goals from their customers' perspective seemed coherent given the changing of the competitive landscape (financial crisis and new competitors entering the market).

The outcome of the workshop included agreement on the following key changes:

• One big "Product Team" - they would stop having separate backlogs to manage "Mail Operations" and "Key Accounts" requests. Their product was "Tracked Mail", and they would have only one Product Backlog where all the features, improvements, and fixes would have to be prioritized.
• Two guiding goals (for now) - they agreed to collaborate on prioritization with two common goals in mind. First, they wanted to maximize the value they were generating for Tracked Mail, regardless of where that request was coming from. And secondly, they needed to improve their technical excellence, including improving code quality, continuous integration practices, and simplifying their architectural landscape.
• Four small, cross-functional product teams - instead of having 2 larger teams (11 people p/ team), they would split into 4 smaller teams (5-6 people) with a few shared people across the teams (testers, the enterprise architect, and the former "product owner" who was now working with the teams as a senior analyst). The intention was to speed up knowledge sharing, so everybody started to know all the different applications and sharing quality standards.
• One Sprint - since they were all working on the same product, they would basically all be in the same Sprint. Sprint Plannings would be shared, so the teams could decide what items they wanted to work on. Also the Sprint Reviews would be shared, so everybody could see what the other teams had built, ensuring they weren't creating new silos of knowledge.

So the new operating model for Tracked Mail looked like this:

And this worked well for a while. They had managed to scrape enough budget from different sources to keep the team together during the recession and the continued focus on value delivery and engineering practices was paying off. Specifically:

• Fast feedback cycles - the combination of an ever-closer collaboration with the business leads, who were now named "Co-Product Owners", as well as the improvements in continuous integration, automated test coverage, and clear (and sufficiently high) quality standards, meant the team was able to get much faster feedback on the features they built. They were consistently delivering E2E tested features at the end of their Sprints.
• Agile culture bubble - the organization itself had not changed. There still existed the "Mail Operations" and "Key Accounts" business units, and officially, business still had to hand-over requirements to IT, and IT was ultimately responsible for delivering on its commitments. None of this had officially changed in the organization. But anybody who observed this team working would not have believed that. They had created a culture bubble within the large organization, it was clear to anybody who even just walked by the team space.. The lines that separate the different departments present in the Tracked Mail product team in the org chart had started to disappear.
• Gaining trust within the organization - Tracked Mail had long been considered a problem area within IT. This was actually one of the reasons that Tom got the permission from his boss to try "something different" (Agile). Now, less than a year after they embarked on this journey, their reputation had completely turned around. Business was happy with the team, they were delivering, and they were delivering high quality. This started to open up collaboration opportunities with other products and teams in the organization who were now regarding Tracked Mail as a trustworthy partner and not a liability.

The Tracked Mail teams were essentially now working as one large Scrum team:

• 1 Sprint - all teams started and ended their Sprints on the same day
• 1 Product Backlog - all teams pulled work from the same backlog
• 1 Sprint Planning - everybody together aligning on the next deliverables
• 1 Sprint Review - everybody together getting feedback on those deliverables
• 1 Sprint Retrospective - the Scrum Master was surprised this worked so well, but the teams shared common challenges and issues, and they found it better to have 1 single retrospective
• 1 Definition of Done - all teams had to adhere to the same quality standards

And a few months later, just about when Tom was starting to feel pleased with his courage for starting this journey and proud of what they had achieved, two serious problems started to emerge:

• Mis-alignment between the business - once the economic situation started to improve, the budget of the business units started to increase again. And they had a lot of pressure to innovate and deliver because of the new competitors entering the market. And this created a challenge for the Tracked Mail structure as there was more ambition from the business than delivery capability from IT. And all of a sudden the co-product owner structure was not working anymore - they couldn't align on priorities.
• Pressure to speed up and start cutting corners again - the mis-alignment between the businesses brought back the pressure on the Tracked Mail to speed up. Tom was again hearing suggestions from stakeholders that they could maybe cut corners (lower quality) in the short-term since the new competitors were entering the market. "We can spend some time later doing some clean-up and paying off that technical debt," they would say. Tom had heard this before and knew this would be a mistake. The clean-up time would never come and they would again be drowning in the waste generated by low quality. Also, the developers would be extremely demotivated after all the work they did to clean-up and simplify. 

This time however, Tom had an ace up his sleeve - the improvement of Tracked Mail over the last 18 months, and their high performance over the last year had given them a stronger voice in the organization. So Tom stood his ground. With the help of the Tracked Mail Scrum Master, they prepared their case for what should be the course of action. 

In a series of workshops with the business, program management, and leadership, Tom argued it would be extremely counter-productive to repeat the same mistakes of the past. On the contrary, all the work they had done in improving their situation was exactly to be ready for this situation. The problem was simple, there was more ambition from the business than delivery capabilities from IT, which is normal. The solution was not returning to our previous mistakes, but rather continuing to follow the path they had chosen. The whole point was to be a high-performing, customer-centric, and responsive product team. The problem they were facing now was about better prioritization, and the solution should not be quick upstaffing or cutting corners on quality. 

Rather, they should take the next step and better align the organization structure with the team structure. He had created the Tracked Mail product team. What this needed from the organization was one Tracked Mail Product owner. The person in the organization responsible for taking these tough prioritization decisions to ensure they were investing the time of the Tracked Mail on the right initiatives. One person ultimately accountable for the return on investment for the Tracked Mail product.

This was another round of tough discussions as now the real organizational lines were being challenged. Who had the power to decide on priorities between different business lines? This role didn't exist in the previous organization. Eventually though, the success of the Tracked Mail team for the last 18 months, as well as the strong defense from their manager (Tom) to keep going on their change journey was enough. Nobody in the organization wanted to take the risk of being responsible for breaking that up. Instead, one of the organization leaders was assigned as responsible for the Tracked Mail value stream. 

This leader didn't have time to really collaborate with the team during the Sprint, but Tom didn't need that. The collaboration between the business leads and the developers was not a problem. On the contrary, they had developed a relationship and trust over the last 18 months. The Scrum Master explained they could divide up the product owner responsibilities between the Business Leads and the new Tracked Mail Product Owner based on:

• Prioritization - what are the most important items to focus on next?
• Clarification - what needs to be delivered exactly for those items?

The first one (prioritization) had to be done by one person responsible for the vision and return-on-investment. The second one (clarification) could be done by the two business leads. It was not a problem that multiple people were doing this since the priorities were clear.

The Tracked Mail product team had managed to involve all the levels in the organization by this point. From director level (the Tracked Mail PO) to the team members. Tom felt this was a significant milestone, and started to re-evaluate what should be his role here in the future. The team clearly didn't need him to operate and deliver value. Yet, he still had to ensure the team would be protected from the next challenge the organization might throw at them. His role was changing, and he was happy with that.

An example of the organization

The continued focus on technical excellence combined with the addition of the single Tracked Mail product owner, delivered some impressive results and milestones:

• More autonomy - during all this time, the official delivery governance processes and policies were not changed in the organization. IT still had to follow a very structured (and time consuming) process that was not at all aligned with Agile ways of working. But because of Tracked Mail's success (fast UAT periods, low number of production issues, and high satisfaction from the business) they were not following those processes strictly and nobody was complaining. They had more autonomy to take decisions (all relevant parties were already part of the team in some way) and avoid unnecessary bureaucracy.
• An example for change - other team leads in the organization were coming to Tom and asking him to explain how he had turned the Tracked Mail team around. This curiosity created a pull from other teams that wanted to learn if they could do the same thing in their environment.
• Customer satisfaction (internal & external customers) - the Tracked Mail had three main personas they focused on. The person sending items they wanted to track, the person receiving tracked items, and the person delivering the tracked item. One of those was an internal customer. Understanding of the different needs of all three had grown as they became more customer-centric, and satisfaction had also increased for all three personas. 
• Value delivery and responsiveness - because they understood better the needs of their target market and the personas operating there, Tracked Mail was delivering features more consistently having a positive impact for customers (and the results of the organization). Also, the advances in technical practices meant that they were able to react more quickly, and make high priority changes without much stress.

1. Scrum defines the Product Owner role as "accountable for maximizing the value of the product resulting from the work of the Scrum Team." Looking back at the Tracked Mail case study, reflect on the level of empowerment necessary to be able to act as an effective product owner. What challenges would arise if you wanted to give Product Owners in your organization this level of empowerment? What would have to change? Could you articulate a case for the change?
2. Scrum also says that the Product Owner "is one person, not a committee." Do you agree with this, or do you think there could be product ownership by committee? Why? What issues would come up if you had more than one Product Owner? What are the challenges with having one Product Owner?
3. Take a look at the Large Scale Scrum (LeSS) website and read through the LeSS Framework pages (it's a quick read). Do you see how the Tracked Mail case study is an example of an Agile team moving from doing single-team Scrum to LeSS? What do you think are the main difficulties or challenges organizations will face when trying to implement LeSS? Could you use it in your context? Why? 
4. One of the lessons learned from the Tracked Mail case study is clearly the importance of close collaboration within the value stream. The fact business was interacting with the developers, seeing how good they were, and empathizing with their challenges made some of the changes easier to push through. What do you believe are necessary conditions to create an environment where collaboration across organizational divisions can really happen? What are the biggest impediments to it happening?
5. Tom seems to be running out of work. If you were Tom, what would you do next? What have you learned from Tom's example about turning around a team?

1. LeSS Framework (Bas Vodde, Craig Larman) 1.
2. "Large-Scale Scrum: More with LeSS", B. Vodde & C. Larman, 2016 2.
3. "Introduction to LeSS", YouTube, 2017 3.