Case Study: Enhancing Strobbo's Agile Journey with Org Topologies

I recently co-authored a case study about our journey at Strobbo over the past few years: ‘Strobbo Adopts Professional Scrum to Accelerate Go-to-Market’. Alongside my colleague Bert Neels, our agile coach Steven Deneir, and the fantastic team at Scrum.org, we delve into the challenges we faced and how we overcame them over 12 to 18 months. And believe me, it wasn’t always smooth sailing! Even after contributing to the document and recording a podcast about it, I still feel like there is more to share about our story.

In this document, I aim to explore our journey through the lens of organizational design using Org Topologies. This approach provides a structured map to navigate the complexities of teamwork and organizational structure. How did we reconfigure our team 

dynamics? What organizational structures helped us thrive? It’s like assembling a detailed jigsaw puzzle where every piece is crucial. 

Background on Strobbo

Strobbo is an HR platform that automates the administration of flexible workers. It offers an all-in-one solution for managing availability, staff scheduling, time tracking, Dimonas (social security declarations in Belgium), contracts, and monthly payments across various sectors, including hospitality, retail, and the funeral industry.

Strobbo integrates with existing tools like cash register systems, enabling quick analysis of turnover and staff costs through its reporting module. The platform also connects with reservation systems and weather forecasts to optimize staff scheduling and links with payroll systems for seamless payroll processing.

Founded as "Onlinewerkrooster" in 2016 in Lommel, Belgium, by Nick and Bert, who identified a need for flexible staff scheduling in the hospitality sector, Strobbo addressed issues related to the white cash register system aimed at preventing tax evasion. By 2018, it had a team of 9, serving 500 businesses, and was acquired by Protime, a European workforce management specialist, to accelerate international growth.

Rebranded as Strobbo in 2020, the company expanded internationally, supported by a growing team. Today, over 2,000 businesses in Belgium and beyond rely on Strobbo for automating personnel administration.

Scaling Issues and Mechanical Scrum

Our story starts somewhere roughly two years ago. As Strobbo's team had expanded over time we had already restructured into multiple smaller teams to maintain agility and efficiency. This restructuring involved creating three development teams with a multi-skill mandate and a capabilities-focused work mandate, and a second-line support team with a task-focused work mandate. The second-line support team would handle more complex support issues and maintenance for our older technology stack, thus allowing the new development teams to concentrate on the newer technology stack and developing new features.

Despite these efforts, we faced significant challenges, including frequent bugs, performance issues, and a lack of maturity within the team. We brought in external experts operating with a very narrow, TASKS-1 mandate to help improve code structure, implement solutions for better quality and performance, and provide training for the existing teams. However, several key issues persisted:

• Mechanical Scrum: Teams were going through the motions without fully understanding Scrum principles.
• Overplanning and Lack of Autonomy: Heavy reliance on the Product Owner led to disengagement.
• Lack of Trust and Fear of Speaking Up: Trust issues and fear of speaking up resulted in low motivation and commitment.
• Poor Communication: Meetings were passive and disengaged, leading to individualistic work.
• Tactical vs. Goal-Oriented: High pressure from management and pessimism undermined efforts.
• Lack of Transparency: Poor transparency and communication led to a lack of shared understanding.

The issues faced by Strobbo indicated that while the teams were designed to operate as cross-functional teams, they were still struggling to embody the characteristics of effective teams with those mandates. Lacking a visual depiction of Org Topologies, we missed the crucial insight that Strobbo's teams were in a transitional stage—aiming to operate as cross-functional teams—but facing significant hurdles that kept them closer to task-focused and functionally siloed behavior.

Some specific examples of behaviors inside the teams that kept us back were:

• A large focus on ‘resource’ efficiency, with team members being very focused on keeping busy individually. 
• Breaking down work to fit the skills of one team member, resulting in frequent hand-offs between single-skilled individuals.

Inside the teams people were falling back to task-focused behavior and were not working as a team but also overly focused on tasks. Some team members compensated by keeping the overall picture and breaking down the work.

Mapping of the dynamics inside the team.

On the other hand there were also still several dependencies between the teams and the product owner and the teams and the external experts that were holding them back:

• Relying on testing and acceptance by the Product Owner, which caused frequent delays.
• Contract thinking at task level when feedback was given. e.g. there were frequent discussions about something being in the acceptance criteria (or not) and no focus on the overall goal.
• Teams did not trust their own skills to make architectural changes and relied heavily on external experts to do the work, causing more hand-offs and delays.
• Dependency on the second-line support team to release features dependent on our legacy software.

While some of these dependencies were to be expected (e.g., dependencies on the legacy software) for the foreseeable future, reliance on both the Product Owner and the external experts was something we actually wanted to avoid. The teams were, however, lacking in certain skills to be able to avoid this. These challenges, combined with legacy issues in both the old and new tech stacks, further complicated their transition to stronger cross-functional and more independent behavior. A visual Org Topologies map would have highlighted these discrepancies, allowing us to address them more effectively and guide the teams toward the desired position on the map.

Implementing Lean Improvement Kata

Recognizing these challenges, we initiated a coaching track with Steven Deneir, utilizing a Lean Improvement Kata on a weekly basis to enhance our work processes. This approach aimed to systematically address our issues and guide us towards more effective team dynamics.

1: Get the Direction or Challenge2: Grasp the Current Condition3: Establish Next Target Condition4: Conduct Experiments to get there

Hover over or tap any text on the drawing to read it.Tap any text on the drawing to read it.

We set forth these goals for ourselves:

• Make the team independent - stop them from looking to Bert (co-owner of the company) and Michael (Product Owner) for the smallest decisions, clarifications, etc.
• Make sure the team understands that everything can be discussed and changed.
• Make sure the team is proud of their work and boost morale.
• Make Strobbo a showcase within our parent company Protime as a good example of what it means to be a team and what they delivered.
• Prepare the team for further growth (uplift the technical skill level).
• No longer practice Scrum mechanically and half-heartedly.

Looking at these goals through the lens of Org Topologies, we aimed to enhance the team's technical skills, moving their position to the right on the map. Simultaneously, making the teams less dependent on the product owner required them to move up on the map. Speaking in terms of mandates, we knew that we wanted to expand beyond a capability focus toward a partial solution focus with our teams, and focus on achieving business agility.

Achieving Full Adoption of the CAPS-2 Archetype

But as we saw in the previous section our teams were still struggling to fully adopt the intended position on the map. Our Lean Improvement Kata resulted in a bunch of positive improvements, which really helped elevate the teams to more stable cross-functional, capability-focused behavior and further. With the coaching we received, step by step we were able to make progress. Many of these are also proposed as Elevating Katas™ within Org Topologies.

Sprint Goals and Transparency:

• Sprint Goals: Introduced clear Sprint Goals to guide the team's efforts, ensuring alignment and focus on delivering value.
• Stakeholder Involvement: Invited stakeholders to Sprint Reviews, transforming them into collaborative sessions that provided valuable feedback and boosted team morale.
• On-Site Reviews: Moved from online to on-site Sprint Reviews, which significantly improved interactions and engagement with stakeholders, including senior management.

Product Backlog Refinement:

• Involved team members in refinement sessions using Impact Mapping, Event Storming, and User Story Mapping.

Team Cross-Functionality, Self-Management, and Definition of Done (DoD):

• Encouraged collaboration between front-end and back-end developers.
• Implemented Mob development and pair programming for knowledge sharing and tackling complex issues.
• Focused on End-to-End Testing, balancing technical and functional responsibilities.
• Ran a defect matrix workshop to aid in self-management and decision-making.
• Conducted workshops to define and clarify the DoD.
• Made UnDone work transparent, creating a clear path to getting items into production.

These structures and practices collectively enhanced team autonomy, transparency, and alignment, driving significant improvements in Strobbo’s agile adoption.

Transitioning from Capabilities to Partial Solution Focus

But as we said our vision was to enhance our team's capabilities and autonomy. Initially operating with a capabilities-focused work mandate, we sought to transition toward a partial solution-focused work mandate within the Org Topologies framework. Our vision went further than simply improving processes; it entailed a fundamental shift towards greater business agility and independence. After fully realizing the CAPS-level position, the teams were working effectively, but there was still a significant amount of coordination required from the Product Owner. Additionally, we wanted to close the gap with the customer to ensure better alignment and responsiveness to their needs.

This is also the point at which we learned about Org Topologies and understood that we needed to spend more time with the team to help them better understand the direction that Bert and I were moving the teams toward. In a team exercise, we started with showing the video ‘How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It’ to not only better explain the role of the product owner but also to make the point that they can take ownership themselves. We then let the team put themselves on the map, and had a group discussion about what we are currently lacking.

To further elevate the teams at this point, we invested heavily in the following Elevating Katas, building on our previous efforts:

Product Roadmap and Ownership:

• Goal-Oriented Backlog: Transitioned from a feature backlog to a goal-oriented backlog, focusing on metrics such as the number of pilot customers live, feature usage, or deals sold. The emphasis shifted from merely completing features to ensuring their adoption and impact on the company.
• Roadmap Workshops: Organized workshops with internal stakeholders and developers to align on the product vision and co-create the roadmap.
• Enhanced Collaboration: Fostered collaboration to reduce reliance on the Product Owner for day-to-day operations.

Product Backlog Refinement:

• User Story Mapping: Utilized techniques like User Story Mapping to create valuable increments towards achieving goals, ensuring value delivery each sprint.
• Flexible Scope: Instead of detailed estimates, we set goals and placed bets on achieving them within a certain number of sprints. This approach acknowledges uncertainty and allows flexibility in adjusting the scope based on the situation, focusing on the impact rather than features.

Sprint Planning:

• Limited WIP: Leveraged our goal-oriented backlog by limiting work in progress (WIP) and, in some cases, having teams focus on a single goal at a time.
• Sprint Goals: Centered sprint goals around the next best step for the current goals.

A significant consequence of these changes was the evolution of the Product Owner role to be more outward-facing, focusing on stakeholder and customer engagement. This shift also created greater transparency on the roadmap and backlog for both development and business.

At this point on the map you can also notice a big difference in the interaction between the teams. Task-focused and capabilities-focused units require external coordination at the team level. With a partial solution-focused work mandate we see the dynamics change to a ‘Team of Teams’ where teams will organize themselves. Instead of coordinating at the team level you now coordinate the ‘Team of Teams’.

CAPS-2PART-2Team of TeamsTeamTeamTeamTeamTeamTeamTeam

Hover over or tap any text on the drawing to read it.Tap any text on the drawing to read it.

This also changes a lot of the dynamics regarding ownership as capabilities-focused teams will be more likely to focus hard on their own parts and use it as ‘cover’, whereas a partial solution-focused ‘Team of teams’ will start self-organizing based on the work they receive. There can still be ownership, but it is no longer a problem of the external managers to figure this out for the teams. Part of expanding toward partial solution focus involved less reliance on external expertise, which is why the ‘external experts’ are gone from the map.

Collaborating with Protime

Strobbo (formerly Onlinewerkrooster) was acquired by Protime in 2018. The timeline discussed previously occurred after this acquisition. While Strobbo remains a distinct brand and product within Protime, alongside their other workforce management solutions, we operate mostly autonomously as a product group. This autonomy allows us to make decisions regarding our product and technology independently. However, we don't operate in isolation. Over time, we've made significant progress in integrating the Protime and Strobbo product groups, fostering closer collaboration. This integration highlights the importance of addressing how we fit within the larger company and how it influences our position on the organizational map.

Portfolio Management

Until now, I have limited the scope to our product development part of Protime. However, the recent creation of a Portfolio Manager role has shifted the position of the Product Owner. From this larger perspective, it becomes clear that the product owner now lacks a ‘whole solution focus’ and is concentrating only on a specific part. This change adds an extra layer of coordination and alignment that was previously not there.

The impact on the teams is limited, but as the Product Owner might not have the whole picture anymore (depending on how transparent the Portfolio Manager is), we risk them making wrong decisions or losing time on additional alignment. We should realize that when work moves from portfolio to product and then to development, it is not a sequential flow. As we learn more, work might move back from development to portfolio. If this requires a lot of coordination, it can slow us down in terms of delivery and innovation.

Planning Domain

Following the acquisition, the Strobbo team gradually became responsible for the entire planning domain within Protime. Strobbo continues to exist as a standalone product, but two additional teams have been added to integrate Strobbo and another recent acquisition (Sheepblue) into myProtime, Protime's main product. This integration effort aims to streamline functionalities and enhance the overall user experience within the Protime ecosystem. 

This integration necessitates adapting our organizational map to fit the larger context. In Protime, the Product Owner (PO) role is different, responsible for assisting multiple teams with feature development but not acting as a true Product Owner. Instead, product ownership is handled by the Product Manager. This shift demonstrates the clear benefit of using an Org Topologies map over a framework-based organizational design. Even though the titles change, the position on the map remains consistent. The newly added teams comprise developers from both the Strobbo and Protime development teams.

The Planning domain fully encompasses Strobbo as a product, with all its features, and includes Planning as a feature of myProtime. For the teams working on myProtime planning, the scope of work is therefore narrower than for those working on Strobbo. This narrower scope limits the ability of the myProtime planning teams to cross the chasm as the Strobbo teams did. Work beyond their scope must be picked up by other teams, requiring coordination at the 'product' level between the PART-level archetypes.

Conclusion

Reflecting on Strobbo's journey, it is evident that our path to agile excellence was marked by both significant challenges and transformative successes. Initially, moving from a single-team scrum setup to multiple, more specialized teams did not immediately resolve our deep-seated issues related to agility, autonomy, and cross-functionality. However, over time, through persistent effort and continuous improvement, we were able to achieve these outcomes. Key to this transformation was the introduction of clear Sprint Goals, stakeholder involvement, and regular on-site reviews, all of which enhanced transparency and team morale.

Although we did not initially use Org Topologies, in hindsight, it would have provided a critical framework for understanding and addressing the complexities of our organizational structure. This approach could have highlighted the foundational issues sooner, guiding us more effectively through our transitions.

Our integration into Protime further underscored the importance of aligning our product and technology strategies with broader organizational goals. By adopting a goal-oriented backlog, fostering collaboration, and maintaining a flexible scope, we ensured that our teams remained focused on delivering impactful solutions. As we continue to evolve, the lessons learned from our agile practices will guide us toward sustained growth and innovation within the larger Protime ecosystem.

This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.