Key Takeaways
- Frameworks like Scrum@scale can help you navigate in agile transformation by providing a holistic structure that identifies pains and potential for improvements, but they will not provide an understanding of what causes the pains or how to remove them. The framework asks the right questions, but depends on your knowledge and insight to find answers fit for your context.
- Use your intuition to understand the root causes, and you are likely to find that there is a pattern in these that revolves around different kinds of debt: legacy organizational structures and mindset, and legacy processes that are preventing the organization from achieving your goals.
- When your leadership team communicates, they are likely to bundle the information into infrequent waves that hits the organization hard and intentions are likely to be misunderstood. To mitigate resistance, consider radically changing your approach to be involving and frequent, and accept how this will take you out of your comfort zone while giving you the benefits of openness and co-creation.
- If your teams are disrupted by incidents and requests that remove their focus from the backlog priorities, help the team reflect on whether the new tasks will (better) help them achieve their shared team objective. Value measures can be a practical starting point for facilitating these considerations.
- Multiple teams who have work in common should invest in coordinating their priorities, but unrelated teams should not. Do not base the need for alignment on organizational structures.
Introduction
For organizations who work with software development, agile practices are now the default approach - especially for start-ups - and the market is swamped with experience reports and frameworks that can help facilitate agile ways of working for teams who are "born agile". But where do you turn to if:
- you don't work with software development, and
- you are an organization with a long history of being project-led and hierarchical?
In 2017, that was the question we asked ourselves, as our CIO exclaimed, "We’re going agile - and you have full freedom to figure out how".
Our context was that we were around 100 engineers who were in charge of the IT infrastructure in the LEGO Group, a Danish toy manufacturing company which today has factories and offices across the globe and employs 18,000 people. Our department (Infrastructure & Security, I&S) handled everything from internal hosting, network, application integration, ERP platform, cyber security, mobile phones and personal computers, and today we have expanded the portfolio to also include public cloud hosting platforms.
From Day 1, our approach to the agile transformation has been incremental - we have not tried to plan it. Our guiding star has been to try to constantly take steps towards a better and more agile way of working by introducing experiments and learning from them. Taking an incremental approach does not mean that the approach is without structure. To help us maintain an overview of the transformation process and be structured in our approach to introducing experiments we used a compass: Scrum@Scale, created by Jeff Sutherland.
Just like Scrum at the team level, Scrum@Scale separates the concern of WHAT customers/markets the organization will serve with what products, from HOW products that require several teams’ coordinated effort are produced; see Figure 1. In our case, the "customers/markets" are identical to the employees (IT users) in the LEGO Group organization (we refer to them as "the business"), and the "products" are the IT infrastructure elements described above.
Figure 1. The Scrum@scale framework
Scrum@scale, thus, helps us navigate our agile transformation by providing a holistic structure that identifies pains and potential for improvements. However, the framework does not provide us with an understanding of what causes the pains - and therefore it does not prescribe how to remove the pains.
In the beginning, after having introduced the Scrum@Scale framework, we used our intuition to understand the root cause of the issues we were facing. Over time, though, a pattern emerged: many of the pains we had were caused by different kinds of debt. When we ask ourselves why the organization is feeling a given pain, we usually come back to answers that include legacy technology, legacy organizational structures and mindset, and legacy processes that are preventing the organization from achieving our goals. We became attuned to the stale smell of debt.
In this article, the first of a series on how ‘debt’ can be used to guide an agile journey, we will provide two examples of smells that are related to organizational debt, explain the symptoms, the impact on the business and in our organization, outline the experiments (countermeasures) that we have introduced in an effort to try to remove the smell, and provide some specific - hopefully practical - advice for you to be inspired by, should you experience similar smells in your organization.
Smell #1: Wait, Who Said That?
The first smell is something that you will be able to recognize regardless of the way you are organized or what your organization does. It is about how openly you as leaders communicate to and with your organization - and why. In Scrum@Scale it is related to "Metrics and Transparency" as it is about creating radical transparency in the organization to provide the appropriate context for decisions and reduce decision latency.
In the beginning of 2020, we were experiencing organizational debt with regards to how we communicated from the leadership to the teams. We had continued the old way of communicating where the CTO, flanked by the line managers, called in everyone in the department for an hour every 3-4 months where major news were released and changes announced. Smaller news or news that could not wait until the next Townhall Meeting were conveyed from the CTO to the group of line managers who would then relay the message to the team leads who would communicate to the teams. It was either communication-through-big-bang or communication-through-chains.
Symptoms
Do you remember the game "telephone" from your childhood birthday parties? The concept is that kids sit in a circle, and one (most likely the birthday child) whispers a message to the child next to him/her, who whispers the message to the child next to him/her and around the message goes until it reaches the first child again. The original message is obscured along the way - and the message whispered to the birthday child is most likely very different from the original. Both due to mis-hearings but also due to deliberate modifications.
This was basically what we were doing when we communicated from the leadership to the teams: we were playing an organization-wide game of telephone through the layers of the department. Even though we had flattened our organization by only having one level between the CTO and the teams, we had not flattened and democratized our communication because it still was infrequent and filtered.
Impact
The impact on our department was that the changes we wanted to introduce had little traction and the information the CTO wanted to convey was not reaching the teams in an effective way. The teams questioned the motives behind the information, decisions were "faceless" and there was plenty of hear-say going around in the organization. For instance, the intent with the open-source and free approach to the agile transformation was "telephoned" into mandatory Scrum meetings, and the intent to ensure backlog transparency was "telephoned" into mandatory Jira boards functioning as performance reviews for team members. The leaders and agile coaches spent their time dealing with confusion and resistance, rather than facilitating change, and efforts that could have been spent on solving business problems were used for clearing up misunderstandings.
Internally, the teams were frustrated, and instead of feeling empowered, they felt like they were being micromanaged and handcuffed.
Countermeasure
We experimented with changing two things: the frequency of information and the purpose of information.
Instead of presenting a wave of information in the town halls every 3-4 months, we wanted to introduce drip-wise communication. The idea was to move away from a big build-up to communication sessions where the teams were wondering what kinds of major reorganizations would be announced, and instead give them the expectation that there was no big news, just some new nuances to known challenges or topics. Basically, we wanted to communicate so often that there was a risk that it would be a bit boring! Therefore, we started with 30 minutes sessions with the entire department every week, which was then adjusted to every second week, which felt like the right balance.
We also changed the purpose of our communication from being informative to being involving. In the past, we had waited with communicating changes and information until we knew we had all of the information and settled all questions. Now, we introduced a principle that for 9 out of 10 changes, the challenge itself should be communicated before the solution was decided. This increased uncertainty in the organization but the increase in transparency about what the leadership was working on balanced the negative impact of the uncertainty as it reduced the "surprise factor" and increased the opportunities for co-creating solutions and involving teams.
Of course, there were things that we could not communicate immediately. To help us navigate in what we could say and reduce the complexity, we introduced a new saying that went: "In all scenarios ...". We would ask ourselves that given the current uncertainty, what would then be true in all scenarios? If for instance we saw a need for introducing new offerings to the business, such as was described in section 3.1, and we knew that in all scenarios the solution would be to add people to the area and split the team in two, we would communicate this even though we did not know what the split would look like. This created opportunities for the team members to provide input as to what the best solution would be, and it signalled that we were aware of the issues that needed to be solved.
Learnings
Having the CTO communicating to the organization every second week has made the communication less formal, less anxiety-provoking, and more inclusive. Decisions from top level management now have "a face" and there is a forum for the teams to get answers to questions.
Ask yourself the following questions: Are leadership decisions and information bundled into a wave that hits your organization on a quarterly basis? Does it feel like your organization is playing "telephone", where intentions are misunderstood and the organization reacts with distrust and resistance? Does it feel like your leadership group communicates more to inform than to involve?
If the answers to these questions are "yes", you are likely to be able to benefit from moving towards a more frequent, drip-wise and direct communication style. Embracing rapid transparency will get you out of your comfort zone, but we recommend that you experiment with it to harvest the benefits of openness and co-creation.
Smell #2: So, John Just Called ...
The second smell comes from priorities - or, rather, the lack of priorities. The Scrum Guide states that the team should have one shared and prioritized backlog of tasks. This makes it clear to the team what exactly they should work on in order to maximize value creation for the organization - and even though it can be a tough challenge to make prioritizations, the idea is that when a sprint is started, the priorities are settled at least for a while, which enables the team to focus.
The reality in an infrastructure department is, however, that a large part of the work to be done cannot necessarily be planned. Incidents occur whether the backlog has anticipated them or not, and as our department services and provides resources for many other product teams in the organization, requests keep ticking in - and often with an urgent timeline.
Furthermore, many of the teams in the infrastructure department were operating 10-20 different technologies, and engineers in the teams were to a large degree one-man-armies on the more peripheral and legacy technologies, which meant that there would only be one person who could work on issues and requests in that area.
Thus, it was - and is still - difficult to ensure a sustainable, shared focus in the teams due to both process- (how to handle unplanned work?), technical and organizational debt (legacy technology is swallowing individuals). In Scrum@Scale we would put it under "Backlog Prioritization" because it is related to issues in identifying a clear order for services to be delivered and should reflect value creation, but we would solve it with "Metrics and Transparency," as it was not first and foremost an issue between the teams, but rather within the teams as there was a fundamental issue for teams in making the right decisions during a sprint based on value - were we prioritizing the right issues and features?
Symptoms
For the first 70 years of our organization’s history, the success was built on the close community that existed between the employees in the company. If you needed something from another department, the only way forward was to go and ask for it - and the most successful employees had a large network of friends and acquaintances. It rarely paid off to try to escalate issues or play the "mandate card": you utilized your social network and your goodwill to get what you needed.
Even though the company has become global and it’s no longer possible to know everyone - or even just know someone who knows someone - the social network still plays a significant role. People still reach out through their network to get help, and being a good colleague in the LEGO Group means that you help out when needed. The official priorities of the backlog are therefore often challenged, and we suddenly have a lot of "first priorities" which means we don't have any priorities.
The consequences to the team backlog and priorities of taking in new tasks was unclear, but the consequence of not taking in new tasks was obvious as it meant we would hurt our relations with a colleague if we said "no" - a relation we might need later. So we would work on the things brought to us by the most noisy customers.
Impact
This setup meant that help was not given to those who needed it the most and attention was not given to the issues that were of highest value. To the business, it felt like we were out of touch with the overall business needs. There would be long or unclear lead-times and eventually some of our customers would give up and try to find a solution on their own. This again meant that they were spending time on solving tasks and building competencies that they could have avoided. We duplicated work across the organization.
Another derived effect was that as the customers did not have the same insights and knowledge as we had, they eventually would introduce security and availability threats due to poorly architectured solutions and thus the consequence for the entire company was increased risk.
Internally, the teams felt like they were running in circles. It was not clear what they were working towards - they were chasing the latest fire.
Countermeasure
What the teams needed was a compass that could guide them to make the right decisions when incidents and requests were posed to them when the phone rang on a Tuesday morning, something that could help them decide will this - or something else on the backlog - help us towards our objective, or will it distract us from that?
To facilitate this we started working with value measures. For each of the 43 products in our portfolio, we defined an objective (what is it that we want to achieve for the business with this product), a measure (how do we translate the objective into something that can be measured), and metrics (providing the actual numbers). An example is given below in Figure 2 which outlines the value measure for the foundational cloud platform we provide to developers in the digital organization to make it as easy for them as possible to consume and build on public cloud resources with minimum cognitive load.
Specifically for this example we would track how long the lead time was to get an enterprise-configured account (measured in minutes), how well the product solved issues for the customers (how many of the customers would choose our solution instead of managing the foundationals themselves), and how well the product helped protect the company from risks (how much compliance was the platform ensuring).
On a day-to-day basis, the value measure can provide a compass to navigate requests and incidents that reach them: will it help us decrease lead time, increase number of customers on the solution, and increase protection of our accounts? If not, the team needs to think hard about whether to prioritize to work on the task.
Figure 2. Example of a value measure for the product "AWS cloud landing zone", a platform for internal developers.
Learnings
In the process of creating the value measures we found that we had been catching a lot of tasks that did not link up to the objectives of the products we had defined. It started a process of accepting that these tasks would have to be handed over to another product team - even though that team might not initially have the needed knowledge and competencies to handle them - or not done. The latter was especially hard, but the process of identifying "shadow products" that were not officially recognized but kept alive by individuals in the organization because they felt responsible has been necessary to create focus.
The teams became sharper in understanding what their specific responsibilities and focus areas were and it became easier for them to break down the professional barriers inside the teams and involve each other in the areas that earlier had been managed by one person.
The process of defining the value measures was relatively easy, especially as the product owners started to see the value of the value measure. However, the measures are in most teams still a high-level concept that hasn't been thoroughly embedded in everyday decision-making and events such as planning, etc.
If your teams have difficulties keeping their focus on the backlog priorities and are disrupted by incidents and requests around many different topics, we recommend that you facilitate that they reflect on the consequences of taking in new tasks: are they clear? How do they relate to the shared team objective? And do you say "no" or do you just postpone indefinitely? Does your team know if they are running in circles or progressing? Value measures can be a practical starting point for facilitating these talks and start moving the teams towards making the right decisions.
Closing Remarks
Smells, pains, impediments - different ways of describing issues - can be inspected with many different lenses. And to make a successful agile transformation, we believe that using different lenses, viewpoints and levels of abstraction is paramount. Above, we have tried to be very practical and prescriptive in how we recommend you experiment if you are experiencing specific issues similar to what we have described. The up-side of this approach is that it is - well, practical. You can go home and start your experiment at once. The down-side is that reality is complex, and if your situation is not exactly similar to ours (which complexity suggests that it is not) you are likely to not get the same result we did.
To adjust for this risk, we want to conclude with a set of more high-level strategies that we are also constantly navigating from. We believe that if you add these to the mix when planning your experiments, you are much more likely to be able to judge if the experiments are likely to be the right medicine for your ailments.
For the two experiments to remove organizational debt described above, we have found support in the following two strategies:
Align the organization. Alignment is king with regards to ensuring that the team has a common focus and a clear responsibility, and that not everything is Priority One. However, alignment is perhaps a God when it comes to ensuring the same for teams who are dependent on each other, which is an exercise in scaling that becomes more complex when teams provide multiple and different products to multiple and sometimes different customers. Whatever you do, don't underestimate the power - and the complexity - of cross-team alignment.
Do just-enough coordination. Aligning the organization from top to bottom can be taken to the extreme, and so can the desire to foster extremely fast decision making. The interesting thing is that the former tends to slow down the latter. Whatever you do, continuously try to find the right balance in coordination; only teams who truly have something in common or depend on each other should invest time in coordinating their priorities - and only when there is a specific issue to solve.
About the Authors
Anne Abell is Strategic advisor at The LEGO Group. Advises the CTO on product- and organizational strategy, and has worked as scrum master and product owner. Abell holds a Doctor of Philosophy in Information Technology Project Portfolio Management, a Master of Science in Information Technology and a BSc in Political Science; is certified Scrum@Scale practitioner and certified in ITIL Foundation and ITIL Service Operation.
Carsten Ruseng Jakobsen is Agile coach at Grow Beyond. Jakobsen has more than 25 years of hands-on experience working with change management in major Danish companies; is one of the agile pioneers and since 2005 has worked with implementation of agile mindsets and culture to achieve business agility. Jakobsen has presented experiences at international conferences like SEPG 2007, Agile 2007, Agile 2008, Agile 2009, Agile 2011, OOP 2014 and XP 2020. Jakobsen holds a Diploma of Engineering Business Administration (EBA), Scrum Trainer by Scrum Inc., Certified Scrum@Scale Trainer (CSaST), Certified Scrum@Scale Practitioner, Certified Scrum Professional (CSP). Certified Scrum Master (CSM), and Certified Scrum Product Owner(CSPO).
Rasmus Lund Jensen is Agile coach at The LEGO Group. Jensen teaches, coaches and develops leaders in their roles as scrum masters and product owners to facilitate agile transformation. Jensen holds a Master of Science in Engineer, Technology Based Business Development and Bachelor of Science in Electrical Engineer. Jensen is certified Scrum Master, Scrum Alliance Certified Team Coach, and Scrum@Scale practitioner. Has attended Leading Organization and Change (MIT), Summer Institute for General Management, Stanford University GSB, Situational Leadership II (CfL).