.png)
Case Study: Enhancing Strobbo's Agile Journey with Org Topologies
- Michael Voorhaen
- Aug 6, 2024
- 14 min read
Updated: 4 days ago
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 navigating 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.
Introduction to Org Topologies
Since we will be using Org Topologies to analyze our organizational design, I will first introduce some of the basics. What follows below is just the bare minimum to understand the rest of this chapter. For a more detailed introduction, I can recommend reading the Org Topologies Primer.
The Org Topologies map contains a set of recognizable archetypes, each with their own characteristics. In earlier versions these were labeled with letters and numbers; in the current version, the emphasis is on understanding mandates and the kind of organizational intelligence the design enables.
The Horizontal Axis
The horizontal axis of the Org Topologies map represents the Scope of Skills Mandate of a unit in your organization. The more an organizational unit moves to the right, the broader the range of skills it is mandated to apply, and the faster it can deliver value with less dependency on asynchronous hand-offs.
We distinguish 5 different types of org units:
Functional units contain people with similar skills who typically perform the same function. This is often not yet a team as everyone is working on their own tasks.
Multi-skill unit(s) or cross-functional team(s) that can tackle more complex work. There are still dependencies on other organizational units to complete their work.
End-to-end unit(s) that can deliver end-to-end value without being held back by asynchronous dependencies.
Expanding units can continue to learn to remain end-to-end capable over time when new technology emerges.
Unbouned contains org units that are free to learn without limitation.
The Vertical Axis
The vertical axis indicates the Scope of Work Mandate in which the organizational units collaborate and share work. The higher you move up the axis, the closer the unit is to the customer and the more it will be able to deliver customer solutions:
Task focus: the unit receives tasks to work on.
Capabilities focus: the unit receives work as capabilities that need to be built.
Partial solution focus: units focus on a partial solution area and might work for goals within that partial solution scope (for example a sub-product, a business area, or a bounded segment of the customer domain).
Whole solution focus: units can work on customer and business problems throughout the entire customer domain and are not tied to any partial solution or sub-product.
Unbounded: units operate beyond fixed solution boundaries, dynamically shaping work based on learning and strategic needs.
Below you find the full 4x4 map used in detailed org design work. It would take me too far to go into detail of each archetype now, but I will explain those in context of the teams later. However, it is worth mentioning here the position on the map where units are both complete in skills mandate and broad in work mandate (whole solution focus, and in some cases even unbounded).
As an example, the authors of Org Topologies refer to startups being in that space, as in this case, the founders are typically very close to the customer and either have the necessary skills or are forced to learn them (mostly because there is no money to hire someone to do the job). As a business grows, you will get lower archetypes, and it requires more and more effort to get back to that state (if it is even possible).
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.
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.
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 that 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’.
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 occurs 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.
Elevating Katas (addition of December 2024 by Alexey Krivitsky):
This article by Michael provides great examples of what we now call Elevating Katas.
Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery.
Elevating Katas Identified in the Strobbo's Case Study:
Unifying Product Ownership
Moving from individual team-based product owners to a more unified product ownership structure. This elevates product strategy and ensures that the product vision is collectively understood, prioritized, and managed. Instead of each team interpreting the product direction in isolation, a unified product ownership model helps maintain strategic coherence and alignment across the entire product landscape.
Merging Product Backlogs
Instead of multiple, disconnected backlogs, the organization merges them into a single, shared backlog. This structure forces transparency, reduces competing priorities, and keeps all teams focused on the same highest-value opportunities. Similar to the “Merge Product Backlogs” kata, this elevates the entire organization’s workflow by ensuring that work items are consistently prioritized at a product (rather than team) level.
Holding Multi-Team Product Backlog Refinement
Establishing regular, multi-team product backlog refinement events. During these sessions, all involved teams align their understanding of upcoming work, dependencies, and priorities. This structure ensures that each increment of work is clearly understood and synchronized, preventing silos and misalignments before development starts.
Using Obeya for Org Topology Evolution
While not explicitly called “Obeya,” the case study implies the use of dedicated forums or physical/virtual spaces where stakeholders (including product owners, coaches, and team representatives) gather to review strategic metrics, progress indicators, and customer feedback. This structure leads to better-informed decisions and quicker action. Over time, these regular strategic gatherings elevate governance and leadership practices.
Designing Tailwind Career Paths
Encouraging roles to evolve beyond traditional job titles or hierarchical tracks into more fluid, capability-driven pathways. Instead of fixed roles defined by narrow functions, individuals grow in breadth and depth of skill areas aligned with organizational goals. This provides a structure that consistently nudges people towards multi-skilled growth and adaptability.