Introduction
Any organization can be analyzed using the Org Topologies™ map.
On this map, the Holy Grail is at the top right, representing an organization capable of adapting ultra-rapidly to face any opportunity thrown its way. An organization also capable of delivering value to its customers quickly and efficiently.
Figure 1 : Org Topologies Map
Startups generally fall into this category, and if they don't, they don't last very long in this highly competitive world, where it's crucial to perform at a very high level. A level where the consumption of the few resources available enables you to quickly find the product that the first customers will love and that will keep the adventure going.
As a small organization grows, the general tendency is to segment responsibilities. Departments specializing in different areas are created (marketing, sales, after-sales, etc.), with a consequent reduction in adaptability and in the ability to deliver value quickly and cost-effectively.
The growth of an organization tends to take it towards the lower left-hand zone of the map, where the teams and individuals making it up no longer have a holistic vision of what is best to do for current customers and to continue to prosper by reaching new markets, for example.
In this article, we'll follow the story of Paul, a consultant specializing in digital application testing at the start of his career. On an assignment, Paul joins an organization with multiple departments, scattered teams and individuals, that require a lot of coordination to ultimately serve the company's customers.
In this story, you'll see how this organization, and more specifically the business unit Paul joins, embarks on a path to regain the holy grail, notably by relying on the Kanban strategy.
Chapter 1 : The beginning
The business unit Paul joins, delivering digital services to its customers, is a collective of around 50 people. These 50 people cover all the skills needed to deliver a digital product to some of the company's customers (Business, IT, Marketing, Sales, Hotline, etc.).
This business unit is located within a larger company serving other products and services, for a wider panel of customers.
Using the 4 vertical strata of Org Topologies mapping (C, B, A ,Y), this would give this form of representation:
Figure 2: The company as a whole in the vertical hierarchy of org topologies
The story that will be told throughout these chapters focuses on the business unit X that Paul joins.
The organizational situation of this business unit when Paul joins the company is represented on the following Org Topologies™ map:
Figure 3: Representation of the business unit Paul joins, with mapping of Org Topologies™
Links between individuals or teams (pseudo-teams) are represented by connectors.
This organization is highly siloed, with no member of the sales group (C1), who is closest to the customer, ever communicating with the product development group (A1).
To act as an interface between the salespeople busy in the field selling the various products and services the company offers, and the people developing the product, the organization has chosen to place several business contacts (B0), each with their own area of responsibility (marketing project manager for X-type customers, another for Y-type customers, etc.). There isn't one coherent unit sharing knowledge, but X number of distinct interlocutors with their own dedicated business knowledge. These people find themselves without a global, customer-oriented vision, but with a partial vision centered on their business domain, their customer domain. The hotline (B1) has a broader, more shared knowledge base, with its members dealing with all types of customers and all kinds of problems, but it responds and unblocks situations on a case-by-case basis, without having the decision-making power and capacity for action to bring about lasting changes that benefit customers.
In this situation, a lot of coordination is required between these different actors, and inevitably a lot of useful information is lost so that the right decisions can be made for the business and the best possible service can be provided to customers.
These people don't have the skills to maintain and develop the product. They will rely on an IT department, generally divided into two parts, Business Analyst and Coder.
In this case, a group of people with skills linking business and IT will analyze the problems and needs raised by the Hotline or by business contacts. It's also not uncommon for this group to consist of people who are highly specialized in specific business fields, but who can't all address the issues of different customer groups. The organization presented here is such a case, with its Business Analysts (B0) specialized in specific fields.
Paul is assigned to join a group specialized in testing, the QA unit (A0). This group acts as a reinforcement, freeing up the BAs' bandwidth so that they can focus on understanding needs and issues, and manage "big" projects as IT project managers. A group of testers with missions often specific to non-regression test batteries.
A frenetic pace of testing that leaves no room for knowledge sharing, leading people to specialize in parts of the application.
Paul has a hard time getting to grips with his mission, as his colleagues are not available to help him understand how the application works and all its subtleties. Fortunately, there's a lot of documentation available, and after a few weeks he's able to find his way.
In view of future developments, an IT project manager (B0) asked him to focus on one part of the application.
Obviously, the organization has equipped itself with IT developers (the digital product isn't going to be built by magic!), these developers form a unit often siloed into specific areas of competence (A1). This is the case in the organization Paul joins, where knowledge sharing is rare and peer-programming non-existent. A unit where each developer, according to his or her specialization on the application, takes bits and pieces of the specifications written by the BAs in order to code the evolution or the correction.
The organization has chosen to call on an external technical skills center (Y1) to manage fluctuating IT development skills requirements. The company's strategy is to control the increase in its payroll for technical skills, fearing a drop in activity around these skills in the future. They do not want to have dozens of employees to whom no activities can be entrusted. Between poorly drawn-up contracts and IT security constraints, this technical skills center finds itself carrying out corrective rather than evolutionary tasks, and submitting deliverables that must then be integrated by the internal development team.
Finally, to deliver the application in production, carry out technical monitoring and ensure infrastructure maintenance and evolution, the organization has specialists in a dedicated unit (Y1).
Paul regrets not being in touch with the business contacts or the hotline. Instead, it's the BAs and IT project managers (B0) who receive the problems and, when necessary, pass them on to Paul's unit.
He sincerely believes that he could better understand the bugs found and more easily reproduce them to help developers correct them. He's already mentioned the subject several times, but nothing has changed.
An organization that sets up numerous committees to coordinate the various teams and individuals, requires many hours of reporting preparation and spends many hours in these meetings.
Paul has to keep track of the bug counters, the percentage of remaining test cases, and an assessment of the time remaining to complete the tests he has been asked to perform. A complicated task for him since, if he detects a bug, he is often unable to continue because the bug needs to be fixed first. Since he has no idea how long the fix will take, he commits himself to other test work. As a result, it can take a long time to get back to what was interrupted a few days later.
At least, he says to himself, "I'm becoming more and more proficient across the entire application."
He wonders on what basis the IT project managers communicate landing dates for the various projects. It seems to him that this is done on a gut feeling rather than on factual elements. Of course, there are Gantt charts and schedules, but there are always unforeseen events, such as bugs or setbacks, which he detects and which upset the plans.
A type of organization that you may have known, or in which you are currently involved in some way.
An inefficient, ineffective, and unpredictable organization.
For this organization, schedule slippages are constant. Announcements of corrections and new features are communicated to customers but are hardly ever kept. Customer dissatisfaction is on the rise, to a level that is becoming critical to the business, and this is not something that management can afford to ignore. It is absolutely vital for this organization to increase its ability to respond faster and more predictably.
We'll continue Paul's adventures in this organization in the next chapter...
Chapter 2 : Redesign project and initial organizational changes
What's more, the organization, which was far from efficient, had dragged the digital application into a major technical debt. Customers were suffering the consequences, with critical incidents becoming increasingly frequent. Paul was also paying the price, with more and more non-regression tests being pushed to the tester unit, hoping to avoid bringing major problems into the hands of users.
With this in mind, and with increasing feedback that the organization was not efficient, management decided to launch a major overhaul project.
They took the opportunity to make a few organizational changes to bring together the people whose objective was to carry out this project. The BAs/IT Project Managers (B0) merged with QA (A0), to form a functional unit (B1) (For the time being, this unit will be referred to as the BA unit).
Paul, who had acquired a great deal of knowledge in the area, was offered the chance to join the team and terminate with consultancy. The idea appealed to him all the more as, at the business contact level, management had taken steps to federate a customer knowledge unit around one person, a business project manager (C0).
Figure 4: Representation of the business unit after the first modification
Through her work with sales, marketing, hotline staff and, of course, customers, this person would quickly acquire a broad knowledge of customer expectations and issues. She would also work closely with Paul's team to bring meaning to the work carried out and prioritize the most relevant developments in relation to what was expected by customers.
Paul had never had the opportunity to talk to someone who made him so aware of customer expectations, and his motivation, and that of his colleagues quickly became much greater.
In his previous experience, Paul had seen teams using physical visual management to manage their projects. He suggested that the rest of his BA unit implement visual management.
Paul's idea and the collaboration with the rest of the unit led them to set up a simple "To do", "In progress", "Pending", "Finished" workflow.
The development unit had also heard about this approach, and Paul remembers that they had implemented much the same thing.
Paul discovered a little later that they had initiated the implementation of a Kanban strategy (see here for the official Kanban guide : https://kanbanguides.org/english/), however :
"We were clearly not in a Kanban strategy, simply because at that time nobody knew what had been set up at Corbis* and the emergence of Kanban for the product management field. If that had been the case, we certainly wouldn't have had this column ("Pending").
Moreover, we didn't have any very explicit rules for pulling elements to the next states, so there was a lot of implicit in this workflow. Finally, we lacked all the other elements of a true Kanban strategy. How to control work-in-process? Explicit pull policies, a service level expectation, etc.
At that time, we could and should have merged our workflows to have a global view of what was going on, because in the end, when we (BA) finished something, it was a specification, an explanation of a bug that we gave to the dev team, and which for them would then appear in their "To Do" list.
When they finished, it would come back to us (BA) for testing. We would then enter a test ticket that would go through our workflow (hence the pending column we used when a bug was found and we were waiting for a fix to be delivered to resume testing)."
*If you want to know more about the birth of Kanban for product management that happened at Corbis (a Bill Gates company), the story is very well told in the Kanban pocket guide (https://prokanban.org/kpg/).
If these two units had juxtaposed their workflow, they would have obtained something like :
Figure 5: The initial workflow and the evolution of the elements after a few weeks
This juxtaposition made it difficult to get an end-to-end view of how long it took the team to complete a project that customers were waiting for, or that was useful as part of the application redesign.
Paul explains: "We sometimes had as many as 4 or 5 round trips with corrections to be made and new tests to be run, as many post-it notes circulating on our visual management. We had added creation dates to our tickets, but if we wanted to know how long it had taken to develop, test and correct the Dev A, we had trouble getting this information.
The simple implementation of this had a significant gain in terms of visibility in each unit of what needed to be done, of what was in progress. Collaboration within our units had become better, and people were increasingly able to intervene globally on the existing application, but also on the new one we were building".
On the other hand, Paul reports that the business project manager was regularly annoyed because it was impossible for him to get clear information on when a subject was going to be completed. He could see that a lot of work had been done, and that progress was being made, but if he wanted to communicate to management or customers when the F functionality was going to be released, he still couldn't get accurate answers. This meant that he had to revisit his communication on a regular basis.
The time actually taken to complete a feature was often well in excess of the initial estimate... and unfortunately not in the right direction, often taking several weeks.
Management, for its part, was beginning to doubt the team's ability to successfully complete the redesign project, with numerous schedule slippages occurring again and again.
Paul: "The increasingly frequent irritation of the business project manager and the doubts of management (which came down to us in the form of pressure) made us feel strongly that we had a major area for improvement to implement quickly.
In discussions with colleagues from the BA unit and the development unit, we saw the need to break down our silos and become a single, multi-skilled unit, aligned around a single short-term objective, in order to reassure ourselves of our ability to complete the project successfully. We also hoped that this would give us an overview that would enable us to be more reliable in our answers to the “When?” questions we were often asked..."
Chapter 3: The birth of a Scrum Team
This willingness of two separate units to work together to improve the overall performance of digital product creation was somewhat accepted by management. Not without a considerable effort, particularly on Paul's part, to convince everyone that the experiment was worth trying. This new unit was obviously expected to deliver on the expected results of this experiment, particularly in terms of improving Time to Market (T2M).
This T2M was clearly the cycle time, but the team used this name, better understood by management, to sell the experience they wanted to achieve.
Figure 6: Representation of the business unit after the second modification
Paul relates that this organizational evolution brought about two things:
"The "business" project manager more or less integrated the team into a Product Owner accountability. I say more or less because we were in the early days of Scrum. If today, in many places, Scrum is still not properly implemented, particularly around the PO role, I'll leave you to imagine what differences this PO role had at the time (and we're talking about the years ~2010) with that of a project manager (spoiler alert: nothing or almost nothing).
Together with the in-house developers, we (BA) formed the Scrum development team (yes, that's what it was called back then, so I'm allowed to say it!).
We had a great ticketing tool. Great is ironic, because it's certainly responsible for a lot of the mistakes we made when defining our unified team workflow:
Figure 7: Unified workflow following organizational change
We finally had a more global, unified view of what we were doing to create value."
You may have noticed that the "pending" column was still present with this unification of workflows by merging the two entities.
Paul explains why: "Well, for us at least, it was very clear because we weren't yet a team, but just a group of people with almost all the necessary skills, but still talking about Business Analyst People, Technical People and passing the hot potato back and forth. So yes, we always had this pending column mainly meaning that we were waiting for the technical people to correct a detected problem."
A bad practice, at least if you hope to achieve a high-performance flow! (But so common in an organization with silos).
In fact, each silo can be seen as a dependency, through which each element of potential value has to pass before finally reaching the hands of the end-user.
Each dependency is a point where the flow breaks down, with elements potentially (and frequently) piling up and aging.
As a result, these silos lead to an increase in the number of items in progress, as, for example, the "Business Analyst People" start additional work while awaiting either developments or corrections. Contextual changes are numerous, which also leads to a loss of efficiency, due to the not-inconsiderable cost in terms of time spent going back over elements. A serious study on the subject of context switching showed that by switching contexts between 2 subjects, around 20% of time was lost, and 40% of time was lost by pursuing 3 subjects at the same time (see: https://www.scrum.org/resources/blog/financial-cost-task-switching).
Even so, after a few weeks of experimentation, this fusions began to show positive signs. Both in terms of T2M, as measured by the Product Owner-to-be, a downward trend was visible, but also on the quality of what was being produced. Indeed, this fusion had sometimes (unfortunately not yet regularly) led to collaborative workshops between the different skills to understand the expectations, the problems to be solved and to find the best solution together. Technical skills were thus able to better grasp what was expected, enabling them to make proposals (and no longer code without trying to understand why), which collectively enabled more qualitative increments to be implemented.
However, there was still one notable point of inefficiency in this organization, and that was around an external development unit devloping software for the service center.
Paul makes the point very well:"In fact, in this workflow, if you zoomed in on "Development" you could see that things were no longer within our unified team, but on the side of this service center. The work they were doing had to be integrated. We added an integration stage before the acceptance stage to make this transparent. The data collected clearly showed a point of inefficiency, which helped us to support management's need to address the issue. "
When the opportunity arose to change the service center, Paul and his colleagues managed to convince management to make a few changes to the contract and internal process. Not without difficulty, they succeeded in getting this additional coding force to join their Scrum team and to work on the product in the same way as anyone else.This reduced dependency aligned these people with a common objective and increased the collective intelligence to come up with the best possible solutions. In the end, both the service provider and the people involved were more committed, because they were faced with problems to solve that made sense to end-users (instead of "peeing" code without understanding why).
A change that clearly paid off, as you'll discover in the next chapter.
Chapter 4: Ramping up the Kanban strategy
With a little patience, a little effort, and a lot of dialogue, Paul and his team sealed a collective spirit of unity.
They were making progress in their understanding of Scrum, but also of the Kanban strategy. They began measuring cycle times and experimenting with WIP limitations in an effort to optimize their workflows.
In creating the team's DoD, they unfortunately still were not allowed to go into production. This last step was always carried out by the infra-Prod people (Y1) outside their team.
Paul says: "We no longer saw work items as something we passed on to each other, but as something we had to finish as quickly as possible together. We helped each other, both functionally and technically, with whatever skills we individually had. For example, the functional people had learned how to carry out automated tests, and not just through the GUIs, we went as far as automating tests at API level. People with technical skills were invited to participate earlier in the design of the solution and contribute their ideas. Some of them carried out tests, when this was preferable given the state of our workflow. We were now in the same room, collaboration was very strong, pair programming had become a regular custom and pairs often functional & technical."
Figure 8: Representation of the business unit after the third evolution
The Scrum team's workflow* had thus evolved and was now :
Figure 9: Workflow evolution following this third upgrade
* For the sake of readability, not all the elements of a workflow definition for a professional Kanban strategy are shown here (refer to the Kanban guide to understand what's missing).
By checking with Paul, the team had established WIP limits on the refinement, dev and acceptance stages. The WIP limits were intended to help improve the team's focus by avoiding starting too many jobs in parallel, but also to avoid a "shortage" somewhere in the workflow. The team therefore established optimum WIP limits, i.e. both an upper limit not to be exceeded, and a lower limit to be maintained. Ultimately, the aim was to experimentally find the best limits to improve performance.
Paul: "The mistake we made at the beginning was not to also limit the stages of waiting for dev, waiting for test (or by grouping stages with the previous stage of active work)".
This is a classic mistake, which often results in a pile of pending work, and ultimately more work in progress than the optimum level for the team.
Paul reports that this problem was quickly detected and corrected, adding: "All this led to a clear improvement in our speed of processing. We didn't measure it very well before, but with the data that the project manager, hmm sorry our Product Owner, was communicating and the various reschedules, we were roughly between 30 days and 90 days to complete a feature.
The data we're now collecting showed us a halving of the maximum cycle time and reduced variability (~25-45 days)."
These now frequent measurements of cycle times, and the quest to improve their performance, led them to look at an even more interesting metric than cycle time: the age of the current elements in their flow.
Why even more interesting? Because it informed them much earlier than the cycle time (calculated only once the item had reached the end of the workflow), enabling them to have the necessary conversations more quickly to best manage the performance of their workflow.
Paul tells us how it came about: "We discovered this metric through the blog post: https://caroli.org/en/latency-and-banana/. The idea seemed brilliant, but we preferred to count the number of days without hanging banana peels on our post-its...
A little later, we learned how to visualize the cycle time of our various components on a scatter plot and, by adding percentiles, we discovered the distribution of the cycle time of our components... 70% under 24 days, 85% under 33 days.
This will lead us to define a Service Level Expectation (SLE) based on our historical data and challenge us to do better: 20 days or less 85% of the time was the one we chose.
We coupled that with tracking the age of our current elements and it was a game changer."
The limits of WIP that the team had experimented with had brought a fairly minimal improvement in performance. The experiments carried out had sometimes brought improvements, but also sometimes regressions, except that it took little time to assess. Age control and the Service Level Expectation (SLE) the team had chosen, on the other hand, brought a substantial improvement. Better WIP limits even emerged quite naturally through the practice of age control and the focus on trying not to exceed the SLE.
After a few months, the team had more than met its challenge and could even challenge itself to further improve its SLE.
However, it also undertook another improvement, that of increasing the usability quality of its product, by training part of the team in UX Design.
However, Paul tells us about one of his misadventures with UX skills: "We had succeeded in selling the contribution this skill could make to our customers' happiness, and therefore to our business. Management and our business representative (Product Owner) were so anxious to see the contribution this type of skill could make to the product, that they wouldn't let us apply our newly-acquired skills on our own. They called in a specialist consulting firm, and unfortunately this added a separate unit to our team, and therefore a unthoughtful dependency".
Chapter 5: A good idea that turned into a dependency for a while (thus a flow killer)
This addition led to dependency and, unfortunately, an overall slowdown of the system.
This team had its own workflow, disconnected from that of the Scrum Team. The Product Owner worked upstream with this external UX team to understand more precisely the customer's expectations and issues. They would produce prototypes, and carry out user tests with these prototypes. Unfortunately, this took up a lot of time.
Figure 10: Mapping org topologies after the fourth evolution
Paul remembers this period well, frustrated at not being able to put his newly acquired skills to good use:
"They were quite high-level in the macro-design of the solution, and we always needed when we got their work back to do some fine-tuning, chopping up the big features into smaller pieces to move forward iteratively and incrementally as we'd become accustomed to doing. What's more, it wasn't unusual for the prototypes they had tested with users to be a problem for us in terms of functional or technical feasibility.
We were in a discovery/delivery silo."
This can be seen in the Org Topologies™ Map on the vertical axis :
Figure 11: Another view of the Org Topologies™ map
This desire to better understand customer expectations was commendable, because it's true that it's a shame to develop things that aren't expected by the customer, that aren't going to be used, that are going to create usability problems, but all this had a cost, and in the end T2M, the cycle time for delivering product evolutions, was much shorter before.
Paul and the team had managed to find out how long it took before a subject reached them:
"You have to see that roughly with the addition of this external UX/UI team it was ~ 2 months of cycle time spent before we got the hot potato back (if not almost cold, considering the delay already passed).
The real knowledge of what we were bringing in terms of value was thus delayed by ~ 2 months, but we potentially had something with a higher level of usability and a few low-value hypotheses discarded.
The main problem, in my opinion, was the disconnect between discovery and delivery, accentuated by the fact that it was all upstream work and this UX Team never drew on the concrete in production and in the hands of users to close the learning loop leading to new UX reflections to improve the product."
In this ultimately business-oriented positioning, in the sense that the service provider responded to the Product Owner's initial "discovery" order, but without closing the learning loop with the real product and real-life user behavior, the organization was far from reaping the benefits of UX design.
Paul and the other team members who had been trained were well aware that the UX service provider could or should have offered more.
They had lost a battle with the arrival of this external UX team, but decided not to stop there. They installed a product analytics tool and began to discreetly analyze user journeys, feature usage and dropout points, and set up heatmaps to take a closer look at the pages where users were circulating in and where they were clicking...
Paul tells us: "All this information was extremely valuable, as it enabled us to learn how users actually used our product. I still don't understand why the UX expert company didn't offer this and settled for this initial "discovery", but in the end it made us happy. Indeed, one day, we decided with a few other team members that we had enough marbles via product analytics to open discussions on unused functionalities, paths to be improved, and so on.
Where we identified areas for improvement, we produced a few low-fidelity (and inexpensive) mock-ups to suggest improvements and provide a basis for discussion. These elements paid off, as they were much appreciated by the stakeholders and management, and enabled us to establish our expertise in this field too".
The UX service provider's mission came to an end a few weeks later, and management and the Product Owner decided to rely on the expertise that the team had proven to have acquired, at least at a level where they weren’t seeing the benefit of paying for an external service.
This led to an evolution of the team's workflow in two aspects.
Firstly, the team (including the Product Owner) decided that the endpoint was no longer when the product went into production and was in the hands of the customer. The endpoint would now be beyond that and would be when the collection of feedback from the use of the functionality was deemed sufficient. Either to decide to finish, or to decide to finish but with a new input to the workflow linked to the feedback and learning gained from using the product.
Second workflow evolution on "discovery" aspects. Paul had recently taken the Professional Scrum With UX (PSU) course and clearly understood the concept of agile dual track. In a nutshell, this concept is the delicate, ongoing mix between what needs to be learned upstream to avoid developing things that won't be used (or almost not used) and fast development, based on this learning, of small increments. Providing fast learning loop and enabling the refillment of idea and evolution based on this new knowledge.
It's not, as many may have understood (and perhaps still do), two parallel processes, carried out by different people and feeding into each other in a discontinuous, sequential fashion (the discovery work of the last 2 weeks, feeding into the delivery of the following 2 weeks), with no ongoing consideration of the learning achieved through each "prism".
With this newly acquired knowledge, Paul proposed an experiment to the team to visualize this discovery work at workflow level.
"In agile product management, it's crucial to know as quickly as possible if you're wrong, so it was beyond me to bring in the idea of having discovery items circulating alongside delivery items that needed to be done before we could progress on delivery. Most of the time, this work had to be linked to the same element of value, so that it was seen as one unit of value, where the whole team remained responsible for flowing the element as quickly as possible towards the end of our workflow.
But on the other hand, sometimes it was necessary to carry out more in-depth and longer studies to ensure that the value hypothesis was viable.
So I brought the following experiment to try:
The creation of a new type of value item that would circulate in our workflow, which I called "Study (discovery)" and which would correspond to this longer discovery work.
For the rest, I suggested to the team that they consider the contribution of UX practices in the various stages of our workflow:
Refining, for example by quickly interviewing a few users, or quickly prototyping something on paper and testing it with a few users. This enabled us to start the IT development with a few improvements or adjustments to the solution we had in mind.
During development, and when it made sense (especially when questions about usability emerged), we would continue to explore whether the solution was appropriate, for example on the basis of a higher-fidelity prototype.
When we got to the acceptance stage, we would approach end-users to have them handle the new functionality, and in particular check points where we had doubts about usability."
These proposals were deemed interesting, and the team embarked on the experiment.
For the new "Study Discovery" element type, the team challenged themselves with an associated Service Level Expectation (SLE). They didn't want to bring back the bad experience they'd had with the external UX consultancy themselves, and decided that this should be carried out the majority of the time (80%) within a timeframe of no more than 15 days.
The workflow* could be represented as follows:
Figure 12: Workflow definition after the fifth evolution
* For the sake of readability, not all the elements of a workflow definition for a professional Kanban strategy are shown here (refer to the Kanban guide to understand what's missing).
The experience was highly conclusive, and further strengthened the team's links and pluridisciplinarity. The expertise wasn't at the same level, but this meant that UX work that didn't require a great deal of expertise (collecting impressions and feedback on mock-ups and prototypes, for example) could be carried out by virtually anyone in the team.
All these developments brought the team closer to the end-users, management's confidence in the team was excellent, its efficiency had increased drastically and so had its predictability. The Product Owner (and a good part of the team) had been trained to use their (factual) throughput data to make probabilistic predictions via Monte Carlo simulation, which gave much more accurate and relevant results.
Confidence between marketing and sales was also greatly improved, and any tensions that may have existed in the past had completely disappeared.
The Product Owner was also increasingly integrated into the team, and on the strength of this experience and the results obtained, he was offered a very interesting opportunity in another company, which he seized.
Management knew they could count on Paul to step in and offer him this opportunity, which he was quick to accept.
At that time, the organization could be described as follows:
Figure 13: Mapping org topologies after the fifth evolution
Paul, supported by the rest of the team, has been working ever since to resolve a difficulty that is still largely hampering the team's ability to deliver value: the existence of this production and technical infrastructure management unit.
Indeed, the Scrum team is always dependent on this unit to be able to see completed developments available in production, which means they lose a few days before the new features are available and they can learn from them.
Once they have the power, the permissions and authorizations to deliver their products themselves, they will truly have become an autonomous Scrum team, able to deliver a continuous and rapid flow of new valuable elements.
Hopefully, they will succeed, and when they do, the organization in this business unit can be mapped as follows:
Figure 14: Mapping org topologies after the sixth, possibly upcoming, evolution
THE END... or not, depending on how you readers react ;-)
A big thank you to Alexey Krivitsky and Roland Flemm for creating Org Topologies™ and their incredible OTP class that I was lucky enough to follow on Paris in March 2024, as well as to their various feedbacks, clarifications and clarifications to bring to this story before I publish it.
Take a look at their work here: https://www.orgtopologies.com/ and learn more about Org Topologies™ with us in one of the courses.
Comments