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 map contains sixteen archetypes each with their own characteristics, and they are named with a letter (Y, A, B, C) and a number (0, 1, 2, 3). The horizontal axis of the Org Topologies map represents the scope of capabilities of a unit in your organization. The more an organizational unit moves to the right, the faster it will be able to deliver value.
We distinguish 4 different types:
0: single-skill individual(s)
1: functional unit(s), i.e., a group of individuals with similar skills who typically perform the same function. This is often not yet a team as everyone is working on their own tasks.
2: 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.
3: fast-flow unit(s) that can deliver end-to-end value without being held back by asynchronous dependencies.
The vertical axis indicates the scope of work 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 they will actually start working on customer problems and not solutions:
Y: task focus, i.e. the unit receives tasks to work on.
A: feature focus, i.e. the unit receives work as features that need to be built.
B: business area focus, e.g. the units might work for goals stated by a given business department.
C: whole business focus, e.g. the units can work on business problems throughout the entire customer domain and are not tied to any business area or a sub-product.
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, C3 is worth mentioning here as it has units that are both complete in capabilities and in scope of work. As an example, the authors of Org Topologies refer to startups being in C3 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 C3 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 (A2 archetype) and a second-line support team (Y2). 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 (Y0 archetype) 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 structured as A2 archetypes, they were still struggling to embody the characteristics of effective A2 teams. Lacking a visual depiction of Org Topologies, we missed the crucial insight that Strobbo's teams were in a transitional stage, aiming to become A2 archetypes but facing significant hurdles that kept them closer to Y1/Y2 behaviors.
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.
As you can see, internally the teams were falling back to Y1 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 more mature and effective A2 teams. A visual Org Topologies map would have highlighted these discrepancies, allowing us to address them more effectively and guide the teams toward the desired archetype.
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 archetypes we knew that we wanted to move to B2 with our teams and focus on achieving business agility.
Achieving full adoption of the A2 Archetype
But as we saw in the previous section our teams were still struggling to fully adopt the A2 archetype. Our Lean Improvement Kata resulted in a bunch of positive improvements which really helped elevate the teams to an A2 and further. With the coaching we received, step by step we were able to make progress. Many of these are also proposed as Elevating Structures 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 A2 to B2 Archetype
But as we said our vision was to enhance our team's capabilities and autonomy. Initially operating within the A2 archetype, we sought to transition to the B2 archetype 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 A2 archetype, 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 Structures, 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.
In the B2 archetype you can also notice a big difference in the interaction between the teams. Y2 and A2 teams require external coordination at the team level as we saw with Protime. In the B2 archetype 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 in A2 teams will be more likely to focus hard on their own parts and use it as ‘cover’, whereas a B2 ‘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 (“C0/C1/B0/B1” archetypes) to figure this out for the teams. Part of moving to the B2 archetype 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 business 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 Topology 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 B0 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.
Comments