In an organization that wants to act according to the Agile Manifesto, the mandate of decisions lies with the teams and they are self-organizing. Where does the organization go to if everyone can do their own thing? This may lead to chaos. A form of direction is needed to be stronger together than alone. Leaders in an Agile organization no longer steer directly with directives and assignments but indirectly, with context and arguments, focused on value for the bigger picture. A bit like driving an autonomous car, you enter the organizational destination and you leave the rest to the teams. There are already several frameworks that claim to achieve the same, but the Value Wall is the only Agile Framework that respects full team autonomy.
When an organization goes through an Agile transition, the entire organizational structure is generally changed. On the advice of many consultants, a new structure is being sought in which teams can work as autonomously as possible. After all, autonomy and self-organizing capacity are crucial for the success of the Agile transition. In organizations where IT dominates, it is generally easier to set up the organization in such a way that the teams can largely work autonomously and thereby add value to the company independently. With non-IT this is generally a bit more complicated.
Non-IT
In large (non-IT) organizations, however, it is very difficult to achieve a new structure at once that meets all the conditions of a well-oiled Agile organization. So-called “feature teams” are often difficult to form due to, for example, great dependence on technical components from different teams. Regardless how you organize such an organization, feature-team-oriented, or component-team-oriented, you will often need several teams to develop or adapt a service or product.
All the same priority
There it starts to wring. If several teams are needed to deliver a service that works, but all those teams are autonomous and can determine the priority of their own backlog, will there ever be a service implemented? How do you get consensus on the goal in such an ecosystem? You can do this in different ways.
The easiest way is to have a priority list circulate in the organization and thus not allow autonomy. Everyone must work on the same thing. Fast and effective but not in line with the Agile Manifesto and on top of that, it requires that the person who draws up the priority list has extensive knowledge of both the market and the technology. There are people in every organization who think they have this extensive knowledge, but realistically nobody fully has it. That’s why there are different ways to find a balance between autonomy and management. Some of the most famous frameworks do it in the following way.
LeSS
In LeSS (Large Scale Scrum) the problem of potential chaos by many autonomous teams is solved by having several teams work on the same backlog. This reduces the number of unique backlogs and therefore reduces the number of self-organizing entities. In LeSS Huge this is reinforced by allowing even more teams to work on the same backlog by means of a requirement-hierarchy and Area POs. In (very) short, team autonomy is reduced to prevent chaos.
SAFe
In SAFe (Scaled Agile Framework), some limitations are placed on the autonomy of the teams by allowing Business Owners to determine the goals of product development. The potential chaos is limited by allowing Business Owners to act as coordinating layer and to do allignment. On an even larger scale, an additional coordinating layer is added to the system, consisting of the Solution Train Engineer, Solution Management and Solution Architect. In this framework too, team autonomy is reduced to prevent chaos.
Is there no method at all where the autonomy remains with the teams without creating chaos and without introducing coordinating (management) layers again? There is now!
The Value Wall
To coordinate the activities of the teams, we have devised a framework at KPN’s network company (the largest telecom provider in the Netherlands) that is in line with the Agile Manifesto and actually respects the full autonomy of the teams.
At KPN, we took the step to Agile at the network company in 2018 by converting a department of 600+ engineers and engineers from more than 20 departments into more than 70 Scrum and Kanban teams. Product Owners could easily prioritize their backlog when it concerned work that they could perform independently, but when several teams were needed for a delivery, it quickly became a difficult story. Here too, the need quickly emerged from leadership and stakeholders for a priority board to have consensus on the goals. The leadership team also wanted a little more control about what would be developed because certain requests simply did not always end up with the right PO’s.
In my opinion, however, setting up a priority board went against the Agile Manifesto of autonomous teams. Determined to find a solution to this fundamental problem, weeks went by before the Eureka light came on.
The value determines
When there are certain requests for development from upper management, they were previously imposed on lower management as an assignment or directive. People had to work on this and had to work on that. All those requests usually had good arguments, but those arguments were not always clear to the people which eventually had to do them. The Eureka moment came when I realized that once people share those good arguments with each other and convince each other of the importance, then “I must” becomes “I want”. As the manager was previously convinced, the Product Owner is now convinced. All arguments together represent the value of the request. Value in the broadest sense of the word. This is how the Value Wall was created.
initiatives. The closer to the center, the more valuable to the company.
Value distribution
The idea behind the Value Wall is that if a Product Owner has to choose between different activities, the Value Wall is a guideline. In front of the Value Wall, there is a periodical discussion between the people with a request (or initiative) for development (the stakeholders and leadership team) and the Product Owners of the teams who do the development. This solely concerns initiatives where several Product Owners require significant development.
The PO, together with his or her team, determines the priority of their backlog. A PO should aim to maximize the value of his or her product and a PO should therefore be sensitive to features that add a lot of value and put these features high on the backlog. Stakeholders, the business and managers are, in that sense, value advisors who must provide value guidance. During the session in front of the Wall, the arguments help determine the position on the Wall. The more to the center, the more valuable the initiative is to the company. Because not everything can be in the middle, a healthy discussion arises with all stakeholders about what is the most valuable thing to work on during that period. When a PO can choose from different activities, each PO should want to choose the activities that are most in the center.
Smaller initiatives that only require one or a few POs go directly to the relevant PO. If he or she finds it worthwhile to develop, he or she will include the initiative in the other activities on the backlog.
Not a priority board
After the introduction of the Value Wall we have often been asked why it is not just a priority board. The result is just the same, right? The result is often the same, so that’s right, but there is a fundamental difference between a priority board and a Value Wall. Namely, the difference between having to do something or wanting to do something.
A priority board implies that someone else decides what the teams do. Even if you have jointly determined that priority. You can even hide behind it. That is exactly not the way of working that we want to support. As a PO you must want to work on something because you know it is valuable to do. Although the Value Wall is full of work for your team, you must always be able to change priority if something is more valuable to work on at that time. There could always be something popping up that is more valuable for your product to work on at that moment. Then you must always have the autonomy to do this work. Obviously, you should always discuss this with your fellow PO’s accordingly.
Priorities imposed by someone else is killing for entrepreneurship and motivation and that is why we should not hear the word priority from anyone else than the PO. The rest of the colleagues mainly have to make “valuable direction” and “valuable activities” visible. The better the leadership team and stakeholders map the “value landscape”, the better the POs can realize their autonomy.
Value Wall not yet mature
Even though the Value Wall has had a prominent place in the new organization for a year now, it is not mature yet. There is an extensive process and approach to it which is also under development. Every quarter something big or small changes as a result of the feedback from all attendees of the Value Wall discussion. We also want to further develop this new framework next year.
So, does it keep true autonomy of the teams? YES, I think so and I am fighting for it. All of this without chaos? No, not yet. However, if we keep challenging each other on what we want to achieve then this framework (or part of it) has the potential to allow full autonomy without causing chaos.
If you recognize any of the above and would like to discuss, feel free to contact me or reply below in the comment section.
Recent Comments