10 Agile Transformation Pitfalls - and how to avoid them
10 Agile Transformation Pitfalls - and how to avoid them
Over the years, I have been part of many organizational transformations. Almost without exception, the goal was a worthy one. Some did succeed, but many of these transformation efforts failed, either completely or at least to a large degree.
The reasons for failure were often the same. This article will list the 10 most painful ones and how to avoid them.
1. The main actors in the transformation aren’t aligned
The people who lead the transformation think they are on the same page but they fail to verify this. Saying “we need to be Agile” is one thing, but everyone has different ideas of what this actually means. I have seen people misunderstanding what DevOps means, what Scrum entails, or what Value Streams are. To give some examples.
It may sound obvious that alignment on your objectives is key. However, don’t underestimate how often this doesn’t happen. It may appear obvious that everyone is on the same page, but you don’t know unless you verify this.
People may think they know. People may think the others know. People may be afraid to acknowledge they don’t know. Regardless, a failure to align is a sure way to having a rough transformation journey.
Avoiding the pitfall
Ensure you all agree on the goal
I can vividly remember how the head of our department announced we would start working with a scaled Agile approach (not SAFe). The C-level of the company was convinced it would make sense for every team to work in the same way and this approach would establish that.
He had already hired consultants to implement the approach. What he forgot to check, however, was what others than himself thought of the idea. In the corridors, I heard many people complain. It didn’t matter what their position was. Developers, product people and even people from the management team: all dreaded the day they would have to work with the scaled approach.
As a result of this lack of enthusiasm, the passive resistance was massive. On the surface, it seemed people did the work to implement the approach. But in reality, they continued to work as they did and ignored the scaling approach as much as possible. After a few months, the head of the department decided to end the initiative.
I am lucky to have experienced many times what difference it makes when people do agree on the goal. The most successful example involved the first Agile transformation. It was a time when we were in big trouble. We worked on 50 simultaneous projects, but none of them were successfully completed. Our value creation capabilities were at an all-time low.
We all knew things had to change. We were ready for something new. The management team involved everyone in identifying the pain points and possible solutions. The conclusion of what we needed to do was obvious to all. This kickstarted a journey that turned the company around and changed many lives to the positive, including mine.
Ensure you all understand the scope
It’s one thing to be aligned on the goal, but another one to be on the same page of the scope. You want to have alignment on questions like:
What elements of the way of working will be subject to change and what elements will not be in scope?
What parts of the organization will be the target of the transformation and how should they be involved?
What is the impact on people outside of the target group and do you expect them to be involved in a way? These are some questions that come to mind.
I have seen how a transformation team hadn’t thought about discussing whether our Project Managers should also be included in the transformation. The person responsible for the communication thought they weren’t “in scope”. This meant the Project Managers weren’t receiving information about what happened that directly impacted their daily life. When, well into the transformation, they received a mail informing them their role would cease to exist (they could choose out of three different new roles), they were unpleasantly surprised, to say the least.
Ensure you all have the same idea about the concepts
It’s mind-boggling to me how people THINK they are on the same page but are actually talking about totally different things. For example, when people talk about Agile, one person may have in mind that it is all about learning quickly what brings value and what doesn’t. But they may be unaware that the other thinks it is about faster delivery.
I have seen the same misunderstandings with Scrum, DevOps, Value Streams, Product Owners, OKRs and many more. One may be right and the other may be wrong. But that is not the point here. They are not aligned on the concept, but they think they are. As a result, they both have different ideas of introducing a concept.
Suppose that the head of the transformation sees Agile as a way to learn fast, but the others in the team think it’s about fast delivery. If this misalignment isn’t recognized or resolved, this will sooner, or (most probably) later lead to major issues.
The fallacy of thinking you need to produce to make progress
A pattern I have observed often is how people wish to switch into execution mode immediately. I am a fan of Agile. I subscribe to the principle that “Working software is the primary measure of progress” (Agile Manifesto). But this doesn’t mean you should avoid seeking alignment. Actually, Agile is very much about alignment.
Having a conversation to be on the same page takes time. But it will also save you from spending needless effort based upon misunderstandings. There are many ways to have effective conversations. I’m a fan of Liberating Structures. You don’t need to create huge documents. But you need to be sure you’re all on the same page.
Psychological safety
Sadly, not every environment is safe enough to allow people to bring everything to the table. As an example, the head of the department may not want to hear anything but confirmation of what they believe is true.
I remember how a CTO said he wanted to introduce an “Agile” admin tool because according to his golf buddy, it would revolutionize our way of working. No one was enthusiastic about the tool. Some even had bad first-hand experiences. However, the CTO did not accept anything but enthusiasm for it. After 6 months, the CTO left the company. A day later the new tool was shelved for good.
Lack of psychological safety can be a reason for alignment issues. This needs to be addressed to have any chance of success. Otherwise, both the transformation and working in an Agile way are doomed to fail.
2. Agile transformation as a traditional project
I find it interesting how people can strive to have an Agile organization, but their approach towards this is in a traditional fashion. They design, plan and execute the transformation with the idea that everything will happen as planned and that at the end of the transformation, the organization will be changed according to the expectations.
However, transforming an organisation is complex and sometimes even chaotic. You may have all kinds of ideas for changes that will benefit the organization, but often these will not play out as expected. You are working with people who all bring their uniqueness.
Also, in your organization people interact, and create values and practices. Every location, every department and every team has its own culture. What works for one location or team may not work somewhere else. It’s simply impossible to know upfront what to do to achieve your goals.
Running an Agile transformation as a traditional project can be a sign that the organization doesn’t have a learning culture. When people are not allowed to do experiments to learn from their outcomes, they will often choose to follow a traditional approach that gives a false sense of control.
A lack of learning culture is even more alarming given that Agile organizations should embrace the unknown and learn from what they did to understand what to should try out next.
Avoiding the pitfall
Traditional project approaches focus on upfront planning of the work to create the desired output. All steps are meticulously analyzed to ensure the plan is as solid as can be. The premise is that the delivery of the output will result in the desired outcome. That cause and effect are known.
The worst Agile transformation I witnessed had such a traditional plan. It described how the first weeks would be used to communicate the transformation and how and when the teams would be formed, trained, and coached. It had a strong focus on performing the tasks. Because showing that the Scrum training had taken place was considered to be the same as having everyone on the right knowledge level to work with Scrum.
Alarm bells should be ringing when people wish to introduce Agile in your organization using a traditional project management approach. It justifies the question: do these people know why you would want to work in an Agile way in the first place?
All the things true to using Agile to create your product or provide your service apply to Agile transformations as well. You may have ideas that will benefit the organization, but you can’t know for sure. Also, there may be ideas that only come to you while you are well underway in your journey. You need to uncover better ways to create value. It doesn’t work to simply implement an off-the-shelf approach. Instead, the transformation will be a discovery.
As the transformation is a discovery, the tasks you complete and the output you generate are no measure of success. Hence, you need to understand what the desired outcome is and which impact you wish to make.
Objectives and Key Results (OKRs)
One way of defining and moving towards the desired outcome is by using Objectives and Key Results (OKRs). We are using it to great effect in many of our transformations. We together establish what we wish to achieve, resulting in objectives. Then we determine how we can assess if we are moving towards success. This we do by defining key results.
For all the things we do during the transformation, we know how it will contribute to achieving the objectives plus how we can assess our success by measuring the key results. In fact, we are not aiming to justify our work by finding ways to link it to the objectives. Rather, we start with the objectives and then identify what would be the most effective things we can do to bring us closer to do objective.
OKRs have helped us to focus on the work that brings actual value. Completing the work isn’t a measure of success. Getting closer to the objectives is.
Another great tool is Evidence-Based Management. It is also goal-based and very much aligned with using Scrum.
Milestones
Many believe that Agile approaches rule out the use of milestones. I don’t agree. However, I do often see how milestones are horribly misused. They are almost always about output and deliverables. I already discussed how you can’t know upfront what you need to do to meet your objectives.
But you do know what you wish to achieve and when your transformation is a success. You can certainly add a date to this, like “By December 1st, we wish to have improved stakeholder satisfaction by xx%.” (when you have established you care for stakeholder satisfaction improvement). These milestones allow you to find alternatives to increase stakeholder satisfaction based on what you have learned along the way. Done this way, milestones help bring commitment and focus on what really matters to the organization.
Working in Sprints
I facilitated many transformations where we worked in short iterations. Every iteration, we reviewed if the things we had produced were actually bringing us closer to our goals.
I look most fondly back to the transformation when we decided to use Scrum. The transformation team would have Sprints of 2 weeks. We defined a longer-term goal that stated what we wished to achieve within 3 months. Every Sprint we had a Sprint Goal which was an objective to bring us closer to the Product Goal. Then we would decide what we would do to achieve the Sprint Goal.
We had our Daily Scrums and ended the cycle with a Sprint Review and a Sprint Retrospective. The Sprint Review was a collaborative session with everyone who worked at the department or who was an important stakeholder. We showed what we had produced including our findings and had great discussions with the attendants on what we had achieved and what we should aim for next.
Using Scrum for our transformation efforts helped us to focus on our objectives and still be flexible in the way to meet these objectives. And most importantly, we allowed everyone to chip in. It was so successful, that we since then often turned to Scrum for similar endeavours. And we have coached others to successfully use it.
Scrum may not be your cup of tea. Then, why not use another Agile approach?
3. The transformation work is on top of the regular responsibilities
The effort needed to transform an organization is often severely underestimated. Instead of focusing on it, people need to balance their responsibilities. They get additional work on top of their already-loaded agenda.
Transforming an organization is a long-term effort requiring focus and dedication. Having one or two people full-time on the journey and the rest doing it on the side won’t cut it when you’re looking at transforming an organization with more than 250 people. Let alone transforming an organization with over 1,000.
Avoiding the pitfall
What does it really tell us?
What message are we conveying when we rally the people behind the need to transform, tell them they are key to the transformation’s success and then add that transformation work should not impact their primary targets?
I can think of multiple:
Your message to everyone is you don’t want to invest in the transformation. Your people work at their capacity to achieve their primary goals. Now you added goals on top, but the primary goals continue to be more important. Assuming there’s no magic way to meet the primary goals with less work, you can be certain they will not find the time to do enough for the transformation.
You think the transformation is an easy, straightforward endeavour. People can do it on the side, without their prime focus on it. Anyone of them who has a grasp of the true nature of the transformation will be immediately discouraged.
You think people are slackers as they were sitting idle for a huge portion of the week. So they can easily do the extra work.
You believe it is normal for people to work longer hours week after week. You don’t care about their work/life balance or their health.
By requesting people to do the transformation work on top of the regular responsibilities, you are setting yourself up for failure. Transforming an organization is a long-term effort requiring focus and dedication. You need to invest in it if you believe it is important to succeed.
Don’t burn out your people
I find it particularly painful when Agile transformation efforts are tasks on top of an already loaded agenda. It directly violates one of the Agile principles:
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” - Agile Manifesto
There’s a good reason for this Agile principle. When you push people to work beyond a sustainable pace, errors will creep in. Ultimately, morale and health will suffer. Regardless, people who work at an unsustainable pace will only be more productive for a limited time. When pushed beyond their limits longer, they will be less productive than people working at a pace they can maintain indefinitely.
How ironic is this, to have an Agile transformation while violating one of the Agile principles?
Do you actually know what it means to transform?
I am convinced that the large majority of leaders who wish to transform their organization have good intentions. At least, most leaders that I have met are convinced their company should have more agility.
What I often miss is the understanding of how impactful an Agile transformation actually is. I will discuss this in a separate article as this is a pitfall in itself. In the end, it is not about implementing Agile frameworks. What is more important to succeed, is to involve everyone and not only the teams that create the core product. Also, the company culture will be highly impacted. Cultural changes are hard to pull off and take commitment and focus.
Do you really want to transform?
While most of the leaders I have coached actually wanted to see a successful Agile transformation, I also know of some who only acted as if they did. Some of them only wanted to introduce new tools or procedures under the premise of Agile. Others were indifferent or actually wanted it to fail so they could say they tried, but the original way of working turned out to be better for them.
Leaders who can’t be bothered about the success of the Agile transformation actually find benefit in adding it to the pile of work of their people.
Invest!
When you are serious about your Agile transformation, you should invest in it. This includes freeing up the people you need to make this transformation a success. They should have the capacity to be able to focus on the transformation goals. This will not only send the right message, but it will also actually increase your chances of success.
What’s more, a true Agile transformation involves everyone in the organization. Not only people for the transformation team or the teams that create the core product. This means that everyone should have the capacity to play their part. If only for a portion of their time to provide feedback on the steps you take.
4. Failing to communicate the goal of the transformation (often enough)
Your organization has professional, capable people. Many of them have experienced multiple transformations. Some may have good experiences. Others may have witnessed failed attempts. Regardless, people will have expectations. Excitement, anticipation, fear, all of these emotions impact your people.
To make a transformation a success, the entire organization needs to be involved. Some may play an active role, and others will need to find their space in the new organization. This is why people need to understand why the transformation should take place.
It doesn’t suffice to have one town hall to announce the Agile transformation. Regular communication is key, repeating the goal of the journey and keeping people informed on developments. Even better is to ensure people are actively involved. This is the next point on the list.
Avoiding the pitfall
In my professional life, I have been subjected to many organizational transformations. Most of them were poor attempts that were announced in a grandiose way but petered out quite quickly. At the start of my career, these announcements had a huge impact on me. I can vividly remember how they robbed me of my sleep, either of excitement or worry.
But when I had experienced multiple of these transformations, I became aware of a pattern: most of the time, the hype would fade away and ultimately nothing significant would change.
The exceptions to this had one important thing in common: they informed us meticulously about the need and what was about. Plus they didn’t do this only once, they made it one of the core messages of the organization throughout the transformation. Me and my colleagues were taken on the transformation journey.
Outcomes that matter to your people
If you wish to have any shot at succeeding with your transformation, people need to understand the objectives. They also should support this goal. You may not succeed in getting everyone behind the transformation, but you wish to have sufficient support.
Almost every transformation I can recall started with a session solely focused on informing the people about the current state of the organization and discussing why we needed to change our organization.
The most compelling reasons to change were focused on the desired outcome, like:
“We need to remove the silos in our organization to be more response to market needs and to improve the quality of what we create”.
We all felt the pain of the siloed organization. Improving this would directly impact our daily work. We wanted this reorganization to succeed.
To paint the picture, the worst goals focused on output, like:
“We will introduce Scrum to all teams to work in two-week Sprints and use Jira as the admin tool.”
In essence, we were told that we had no say in what we believed was the best way to do our work and create our product. Also, this goal doesn’t help us understand why this would be a good thing in the first place. I felt immediate resentment and secretly hoped this would fail. And I wasn’t the only one.
Communicate often
Communication of the goals doesn’t end at the start of the journey. To everyone informed and engaged, you should communicate regularly. I found that a good way of doing this is by having a specific regular event that is solely focused on the transformation journey. In this event, you seek to have a conversation with your people.
You start off with the transformation goal to get everyone on the same page (again) and show consistency in your message. You then address all the things you were able to achieve to bring you closer to the goal. Then you can discuss and verify the results with the attendants. You can end the event by collaborating with the attendants on what would be the best things to achieve next. Some of you will recognize this format. It is exactly what happens in a Scrum Sprint Review.
As a matter of fact, the best transformations I was involved in, we worked with Scrum. The Sprint Review was our moment of contact with the people in the organization to touch base on our goal, our progress, the feedback of the people and what we should do next.
Communication goes both ways
Communication isn’t only about sending the information. It is just as much as listening to the responses and having a conversation. It all starts with determining the reason for the change. When the people in your organization can’t relate to your reason or change, you will face an uphill battle. Perhaps you see issues that others don’t see. Or you think there’s a problem, but in reality, it doesn’t exist. Regardless, you will only find out by having the conversation.
You should continue to have the conversation with your people throughout the transformation. It helped you to clarify the progress you have made and learn from your people what their pain points and desires are to achieve the goal.
Note
Agile is all about collaboration and communication. So is an Agile transformation. After all, you wish to improve the agility of your company. The only way this can work is by including your people in the discussion. They are the ones who work in Agile teams or will collaborate with Agile teams. It would be nonsensical to keep them ill-informed and roll out your Agile project from an ivory tower. As a traditional project.
5. Failing to actively involve the people
I have seen Agile transformation teams that worked from an ivory tower, taking all the decisions and doing all the work. They “rolled out” the transformation and expected the people to simply adopt the new procedures, practices and culture. It doesn’t work this way.
Avoiding the pitfall
Better is to engage the people and give them the opportunity to identify with the journey towards Agility. People can help on every front from start to finish. You can involve them when you decide on the purpose of the journey and discuss what would make the transformation a success. People could also volunteer to address aspects they feel they can contribute to or help verify the progress.
Actively involving your people helps to increase their engagement and commitment. It feels good to know your skills and efforts are appreciated and have an influence on the outcome of the journey.
You may wonder how to manage this, how to have conversations and make decisions with a large group. There are many ways to do this. I personally am a fan of Liberating Structures like Purpose to Practice and Ecocycle Planning.
Regardless of the great ideas the transformation team may have, they will not find fertile ground unless they involve the people who are going to be impacted by the transformation. Your communication may be top-notch, but you will not be able to transform the organization without the people actually involved and invested.
Also, how odd is it to aspire for more agility without the involvement of your “customer”? We want to have “Individuals and interactions” and “Customer collaboration”, isn’t it? Actually, it makes all the sense to embrace the Agile Manifesto for your transformation journey.
From start to finish
When people see their opinions matter and they can make a difference, they will be invested in making the transformation a success. When they can make their voices heard and the environment is safe to be critical, the chances of success will increase.
I have the best experiences involving everyone from start to finish. This helped me to achieve the following benefits:
Better transformation goals
We were able to identify transformation goals that better reflected the needs of the organization. By involving everyone who wanted in the discussion, we were able to verify our assumptions. At most points, we came to the conclusion we had it right. But sometimes we didn’t. So we reformulated the goals in these situations.
Better understanding of the goals
By collaborating with the people, they understood the reasoning behind the transformation. We clearly conveyed we wanted to transform to their benefit. We did it to tackle their most pressing issues to be more effective in working in an Agile way. And not to “be more Agile”, whatever that means.
More opportunities to find ways to improve
Because the people had a good grasp of the transformation goals and they had the opportunity to collaborate, we had a better view of what mattered most. But this is not enough.
A transformation team in an ivory tower may have all kinds of great ideas to improve the organization. But if you include the collective bright minds and experiences of the people actually working in the Agile teams, you are certain to find more important areas of improvement.
Using knowledge and skills
When you involve the people, they will actively contribute with their unique knowledge and skills. You are sure to have more opportunities to improve. It is only a matter of finding the right tools and techniques to do this effectively. It will address this later on.
Unleashing the motivation of your people
Think of how a transformation team drives improvements from their ivory tower. Now think of a transformation team that enables their people to actively contribute. How will the motivated people in your team respond to the first scenario? And how about the second one?
My experience is that many of the people in the first scenario are wary of the possible negative impact of the changes. In contrast to the people of the second scenario, who are much more open to the changes.
The motivation of the people will be unleashed by enabling them to work on something meaningful, granting them autonomy and giving them the opportunity to grow (Autonomy, Master and Purpose - Daniel Pink).
Better assessment of the transformation success and higher chances of success
Everything I discussed before will help you to have a better grip on the success of the transformation. Your goals are more grounded in reality, as are your efforts to reach those goals. On top of that, people will be more invested.
I have noticed that our events to assess the progress towards our goals were very open and engaging. And with that, we always felt confirmed that what we were doing was important and the right thing.
Engagement at the start of the journey
At the start of the transformation, you wish to:
Establish the purpose of the transformation.
Identify the most important improvement areas.
Have a good idea of who should be involved (and how).
Identify a structure for the transformation.
Select what to focus on first to reach the goals.
Doing all of this with a group beyond 10 people may appear daunting or impossible. However, I have had great success with using the Liberating Structure called Purpose-to-Practice.
Purpose-to-Practice is a great structure to actively engage every contributor, regardless of their position in the organisation and how easily they express themselves. The essence is that everyone’s opinion is equally important.
With Purpose-to-Practice, you will be able to design the five elements essential to start an (enduring and resilient) initiative:
The purpose of the initiative
What principles/rules the group wishes to establish
The participants and how they will play a role
How the initiative will be structured
What the people are going to do
I have facilitated many of these Purpose-to-Practice sessions. They have always brought more insights to the table than a small team could generate on their own. On top of that, it always proved to be a slingshot for high engagement.
Another great Liberating Structure is Ecocycle Planning. It has the same benefits as Purpose-to-Practice and focuses on identifying the activities, obstacles and opportunities for progress.
Engagement during the journey
You want to involve the people at the start, but most certainly also during the journey. Some may be actively involved in doing work and creating solutions to help achieve the transformation goals. Others may play a stakeholder role and bring their feedback and new insights.
Having active stakeholders is important to:
Present what you have been working on and have been able to achieve.
Get feedback on the things you achieved.
Find ways to see meaningful change spread throughout the organisation.
Collaborate on what to do next.
Understand the progress towards reaching the goals.
Knowing when the goals have been reached and the transformation can be called a success.
I have great experience using Scrum as a framework to manage our transformation. We had multiple Scrum Teams. They all worked towards the transformation goals. Every Sprint, we would have Sprint Goals per Scrum Team as a stepping stone towards the transformation goals. We would use the Sprint Planning to define these goals and plan what to do.
The Sprint Review was ideal for having stakeholder interaction. Every two weeks we would present what we created and what we achieved and discuss this with the stakeholders. We had up to 60 people attending the event as stakeholders. They would not only provide feedback but also discuss the most pressing points that held them back from the transformation goals.
Other transformations in the company followed our example. They also noticed how this approach increased involvement and effectiveness.
Note
If you want to bring changes to the organization, it is vital to have buy-in from the people who are impacted by your changes. The best thing to do this is by involving them.
People can actively work on improvement topics. They can also play a role as the stakeholders who give feedback and provide insights. Regardless, you will make your transformation smoother by making it an all-inclusive journey.
6. Failing to understand how deep a transformation goes
It pains me when I see transformation efforts limited to tools and procedures. Like implementing Scrum or SAFe as an approach to managing the work, introducing Jira to administer the work, and reshuffling people into Value Streams.
While the above examples may be of benefit, the human factor is the essential thing. You wish to have a culture of collaboration to achieve results. This doesn’t come out of the blue. It calls for a change in management behaviour and also additional responsibilities for the product creators (designers, developers, quality people, etc.). Agile approaches are about collaboration and self-organization. Teams aren’t merely building the product. They are also expected to be on top of the value they are creating.
The human factor adds complexity of culture to the transformation. And a culture change takes its time. An Agile transformation is a continuous journey as there’s always room to improve or to adapt to changing circumstances.
It boggles my mind and saddens me when Agile transformations are about tools and techniques only. I have seen Scrum implementations fail because it was about doing the events and forgetting empiricism. Even worse was the roll-out of a scaling framework where people turned into puppets.
Avoiding the pitfall
Many of these issues boil down to two misconceptions:
The transformation is a straightforward journey
People will easily understand and happily accept the changes in their way of working
However, organizations aren’t straightforward. Agile transformations impact the company culture; its shared values, goals, attitudes and practices. Many of these are unwritten. They are ingrained in the company. You don’t simply bring changes to the company culture.
The impacted people will need to deal with many uncertainties. Many will understand and be excited, but others may not grasp what will change in their new role. They may even have anxiety about their future in the company.
These are some of the factors that should be taken into consideration with an Agile transformation. They require attention which translates into serious effort. I will now address the topics that dominated the discussions in my experiences.
Changes in objectives and measures of success
When teams transition from a traditional way of product creation to an Agile way of working, they will have to define their objectives differently. Many teams used to trust that the delivery of product features would lead to a predefined value.
Agile approaches are different. They assert that you do not know upfront what will bring you to your desired results. This means you need to move the focus from output to the desired outcome. Your objective will not be to make as many cups of coffee as possible. You will rather focus on making your clients happy by serving them a cup of coffee.
When you wish to transform your organization to embrace Agility, you need to help people embrace setting objectives that are outcome-oriented and defining ways to measure your progress towards the desired outcomes.
My experience is that transforming from output thinking to outcome thinking is not easy. Firstly, you have to get everyone on board. Secondly, you may have many processes that rely on output-centered KPIs.
On top of the shift towards outcome-oriented goals, you may also look into moving away from individual objectives to team objectives. Agile is about working in teams and reaching your objectives together. It therefore makes sense to step away from individual appraisals. I know this is easier said than done. But it is important if you seriously wish to change.
Learning Culture
Agile also embraces a learning culture. The premise is that you wish to take small steps, learn and then assess what is the best course of action next. You may conclude that the things you built in the past months don’t bring the expected value. That is OK. At least you now know you can focus on other things.
The culture of learning has often proven to be a major obstacle in the transformations I have witnessed and facilitated. The sunk cost fallacy is a real thing. Often, this reluctance to abandon the work you invested time and money in is related to a misconception that the answer to complexity is to do thorough analysis and meticulous planning.
The traditional project management approach doesn’t work when you need to grapple with unknowns. It works when you need to design and build a bridge. It even works when you need to build a spaceship. But it doesn’t work when your product is in a volatile market.
When you wish to have a successful Agile transformation, you need to invest in helping people embrace a learning culture.
Company-wide: it involves everyone
Many Agile transformations only target the product and delivery teams. This will not suffice. Teams that work in an Agile bubble in an otherwise traditional company are bound to fail. Sooner or later, they will be restricted by people and teams outside of the bubble that impede them in one or more ways to flourish.
Human Resources / People Management
For me, the name Human Resources says a lot. It hints at considering the people in your company to be (exchangeable) resources. As if they are part of a factory. This is why I favour other names, like People Management.
Regardless, People Management has an enormous role to play. After all, the Agile transformation is in large part a culture shift. This culture shift should be of interest to People Management. They should consider topics like:
Helping your people understand and embrace Agility
Talent Acquisition focuses on finding the people who fit into the Agile culture
Supporting leadership with the role in an Agile organization
Ensure benefits and compensation match the Agile culture
Ensure performance appraisals match with the Agile culture
Whenever people management is not engaged in the transformation, you may have a constant mismatch between People Management and the Agile organization. Consequently, your people may not get the proper training, you may attract people who don’t fit your culture and your people may receive compensation and reward incentives that obstruct working in Agile teams.
Finance, Risk, Security, Sales, Marketing, etc, etc
If you don’t include the people from finance, risk, security, sales, and marketing (add what you think is important in your situation), they are likely not to understand the Agile way of creating value and their roles in this.
Finance and risk may want you to create long-term detailed output-oriented plans with extensive risk registers because they believe this is the way to ensure you stay on the right track. Security may want to see an extensive Change Approval process. Marketing and Sales may promise their customers things putting the teams under pressure.
I believe you can hardly fault these people when are excluded from the Agile transformation. They will continue to do their work as they have done before.
This is why it is vital that people from these areas need to be part of the transformation process. They need to learn how Agile value creation works and what this means for them. They need to know how they are in a position to inspect the work of the teams and collaborate on what to do next. They need to work with the teams to find more effective ways of managing budget, risk management, and security. They can collaborate with teams to have a better story to tell to the customers.
(Higher) Management
Often the direct managers of the teams are part of the Agile transformation. Many of the transformations I have witnessed were driven by them. That said, I have also observed two recurring anti-patterns:
The managers focused on transforming the teams but did not include understanding how it impacted them. Managing/leading Agile teams differs from traditional management. This should not be ignored.
Managers on higher levels in the organization were excluded from the transformation. This has the same undesirable effects on the Agile teams as I described in the paragraph above. There will be a mismatch between the Agile teams and what higher management does.
The role of management changes when the company transforms into an Agile way of working. They should be less interested in how teams do their work, but instead establish the vision and set outcome-oriented goals. They should also foster the environment and help teams to be self-managing. And they should help remove organizational impediments so that teams can be more effective in their way of working. Managers should stop telling and start serving the teams.
The changes are just as impactful for management as for anyone else in the company. It is therefore vital they are also included in the journey.
Note
Whenever Agile transformation limits their focus to tools or techniques only, they are in trouble from the start. Because Agile is not about using different tools or techniques. It is about embracing the notion that you can’t predict the future and therefore need to build, measure and learn.
This realization is not only relevant for the people who are directly involved in creating the value (typically product and delivery). Ultimately, it impacts everyone in the organization. Because everyone works towards achieving the organization’s objectives. And in a world with many uncertainties, this calls for close collaboration and a learning culture.
7. No eye on the objective, only on implementing transformation “features”
Every step of the transformation exists because you believe it will bring you closer to your goals. Often though, implementing these steps is a goal in itself. The efforts are a success when executed according to plan.
However, I have seen many actions without the desired impact. I also have seen actions that turned out to have a negative impact. As an example, we once thought it would make sense to have all teams using the same Jira setup. But what suited one team was detrimental to another team. Still, the actions of implementing the Jira setup were marked as “completed” and the teams that “complained” were considered temporarily disgruntled. It took years before this issue was repaired. Not coincidently the person responsible for the setup had left.
Avoiding the pitfall
All actions should be a step closer to the goal. You can’t simply assume that this is the case. It needs to be top of mind for everyone that completing actions doesn’t automatically mean progress towards the goal.
Outcomes over outputs
Any change you wish to bring to the organization is not about the output. It is about the outcome you achieve and the impact you make because of your output. Despite this universal truth, many transformations are merely a list of actions without a mention of the desired outcome.
I have witnessed how high-profile transformations covering organizations of over 10,000 people started with good intentions and great goals, only to turn into a series of actions to execute and things to implement.
The transformation teams couldn’t convincingly explain to the people involved how these actions would benefit the goals of the transformation. After a few months, they often couldn’t even tell why certain actions were part of the plan at all.
Transformations that do not define the expected outcomes of the activities have no way of understanding if they are progressing toward their goals. What's worse, some of these transformations had their entire focus on finishing activities, disregarding the goals entirely. Many of these transformations were abandoned because of lack of progress. But the ones that managed to deliver everything according to plan still weren’t unsuccessful. The output they created didn’t solve the problems and sometimes even made it worse.
The expected outcome is an assumption only
People may have all kinds of bright ideas to reach the goals of the Agile transformation. I often saw teams use complicated calculations, ideally in a spreadsheet, to assess the expected value/outcome of an activity. Others may do value point estimating similarly as developers define story points to define the expected overall effort of an item. Such tools may be very helpful to assess what to work on next.
It is even better when such potential value calculations are a subject of discussion. I may help to understand the potential of the activities. But there’s a major potential issue with these upfront value assessments. They are no more than estimates. The actual value will only be known when an activity is implemented and people experience the impact of the results of the activity.
Your transformation is in trouble when you solely rely on the estimated value. As logical as this seems, it baffles me how often people take the value estimates for reality. They argue that bright minds who know the ins and outs of the organization have defined and assessed these actions. Therefore the estimates are reliable.
However, an organization is a complex ecosystem. You can’t simply know upfront what transformation activities will make the most impact. Your experts can’t simply read the minds of all people involved or predict the changes in the group dynamics certain actions cause.
This is why you can’t simply work your way through the actions defined upfront and expect to know the impact. Ordering the backlog of work based on the assessed value without reflection is a sure way to fail.
The forgotten column
One of the practical ways to keep an eye on the objective is introducing the forgotten column. Here’s how that looks:
Many will recognize this as a Kanban board, which is widely used by Agile teams. Typically a Kanban board has columns to identify an item from Idea to Shipped (or similar wording). But even more important than knowing if the item is shipped is to understand if it achieved the desired result. This is the forgotten column.
Adding the forgotten column to your Kanban board (or as part of your narrative) will increase the emphasis on continuing with the item until the desired outcome is achieved.
You may have a column that states the ‘actual value created’. I prefer that because, in a complex environment, not all items will bring the expected outcome. Some may even move you further from your objectives. And that is fine because you wish to learn what works, and what doesn’t work and adapt.
Note
Don’t fall into the trap of defining actions to complete your transformations without keeping an eye on the objective. Almost equally bad is defining an expected value upfront without checking this after you finish an activity to bring changes.
The desired outcome of your activities should always be on the radar. After all, you wish to achieve an outcome and make an impact. It is not about completing actions according to a predefined plan.
I could go on and on, but I leave this for future instalments of this series. The next one will be about regularly assessing the progress of the transformation and then I will dive into defining and using measures of success.
8. No regular assessment if the transformation is going well
I already highlighted the complexity of organizational change. You may have all kinds of ideas of what would be good to do. But you can never know, because your organization is totally unique. What works for one organization doesn’t for another. What’s more: this also applies to departments and teams within the organization.
Avoiding the pitfall
It is therefore of crucial importance to regularly assess if the transformation is heading in the desired direction. Just like Scrum has the Sprint Reviews to assess if the outcome of the Sprint resulted in bringing them closer to their Product Goal, maximizing the value of their product.
Agile applied to the transformation
Transforming your organization to be (more) Agile is a journey with many unexpected twists and turns. In previous chapters of this series, I already discussed how using an Agile approach for this transformation makes sense.
You wish to be able to respond to unexpected events and quickly respond to change to stay on course to meet your objectives. To do this, I recommend creating something valuable to bring you closer to the transformation goals regularly. This allows your stakeholders to collaborate with you to understand if this piece of value brings what is expected and learn what would be the most valuable thing to do next. I will discuss this in more detail now.
Define goals for the shorter term
As you can’t predict upfront what you exactly need to do to achieve your transformation goals, I recommend setting goals for the shorter term to indicate what you find most important to achieve on your way to the transformation goals. You may want to set a goal stating what you wish to achieve three months from now. This is typically called a tactical or intermediate goal. An example could be:
“Within three months, we wish to increase the empowerment of the teams. We will measure this by doing surveys every month, including before and after the timebox.”
Three months is typically still too long to exactly know what you need to do to reach your tactical goal. This is why it makes sense to also set a short-term goal. This short-term goal states what you wish to achieve in the coming weeks. A short-term goal towards the tactical goal could be:
“We wish to increase understanding of the people of what they are allowed to decide as self-organizing teams. We will measure this by including questions about their understanding of self-organization in the surveys.”
Continuous value creation
Whenever you work in an environment where the impact of your work can’t be predicted upfront, you need to take small steps towards your goals. This means you will create small pieces of value which should bring you closer to your goals. For example, to raise the understanding of self-organization, the transformation team can ensure that people receive training on the topic.
Collaborate with your people
What worked best for me was to include the people involved in the discussion. It helped tremendously to ask them what they believed would bring us closer to the goal. As a rule, we came to work on other things than we expected. And this is OK. The transformation team should not believe they have the answers to all questions. Especially when others can assess what they need to reach a goal.
Regularly check where you are going
Any Agile approach will have a point where reflect on what you created. Typically, you do this with the people who are impacted by your work, like your users or customers.
The same applies to your Agile transformations. I have had great experiences facilitating a bi-weekly collaborative event to discuss all the work the transformation team completed and how this impacted our path to achieving our goal.
We had the transformation team together with many of the people from the Agile teams, But not only that, we also had many people attending who were not directly impacted but had a stake as well. Examples are people from finance, payment security, operations and management. We showed what we aimed to achieve, what we did to reach this goal and the survey results to show the actual impact we made. The feedback we received during these events was highly valuable to us. It gave us an even better picture of our effectiveness.
This event was also where we discussed our plans for the next few weeks, This is where we included the people to understand what would likely bring us to our goals fastest.
Note
In essence, I recommend using an Agile approach to drive your Agile transformation. I have seen great results with Scrum. We worked in Sprints and defined Product Goals and Sprint Goals. The Sprint Review always was a highlight.
You may prefer a different approach. Regardless, I would always recommend working in short cycles and having close collaboration with the people who are to be impacted by the transformation.
9. Wrong measurements or no measurements of success
Regularly assessing if you are heading in the right direction is important, but this requires an understanding of how to assess this. What makes the transformation a success? How can you determine you are making progress towards the goal?
Avoiding the pitfall
How do we know we are on the right track to our goals?
You may have a compelling goal and your people may understand and support it. The next step is to agree on how you can understand you are moving towards this goal and whether you have achieved it in the end.
I recommend using established practices to do this. Instead of struggling to find a useful way yourself, you can make use of frameworks that are well-established in the industry. Here are three.
Objectives and Key Results (OKRs)
This is a goal-setting framework to define measurable goals and track their outcomes. OKRs work in a cycle. You define OKRs, have regular moments of progress reflection, end a cycle and start over. It is very much comparable to Agile frameworks like Scrum.
Setting OKRs
You start a cycle by setting an objective. For an Agile transformation, this could be something like: “Establish an organization where collaboration flourishes and value creation skyrockets”.
To understand if you heading towards your objective, you can define key results. They are measurable outcomes required to achieve the objective. For the objective above, they could be:
“Improve Time-to-Learn of a product improvement by 10% by the end of the year.” This requires you to know what the current Time-to-Learn is. I like Time-to-Learn because it takes into account what you wish to learn if your improvements are effective. Unlike Time-to-Market, which only looks at when people can start using it. The benefit of this Key Result is that it focuses on the outcome you wish to achieve: having faster learning loops.
“Improve User Satisfaction Score from 75 to 80 by the end of Q3.” This is another Key Result that does not look at how many silos are removed or how much collaboration improved. It is about checking what matters more: does our new way of working have a positive impact on our users?
“Improve Employee Satisfaction score from 85 to 90 by the end of the year.” This also looks at what your people experience, which is an important part of your objective as well. I would not only ask them how happy they are with their work but throw in questions involving collaboration, value-creation, focus and reducing silos.
Regular check-ins
Vital for OKRs is that you regularly check if you are making progress, using the current metrics and comparing them with your Objectives and Key Results. This is very much like a Sprint Review in Sprint. The emphasis is on using the measures.
End of the cycle and starting a new one
It is good to end the cycle with a reflection to understand what worked and what you could do better next time. It’s much like an Agile retrospective. Then you take all these learning and your current understanding of where you are on the transformation journey to define a new Objective (if needed) and Key Results.
I have used this framework on multiple occasions and it was a great help.
Evidence-Based Management (EBM)
EBM is a framework organizations can use to help them measure, manage, and increase the value they derive from their work. With EBM you define your ultimate Strategic Goal, just like the Objective of OKR. You also define Intermediate Goals as stepping stones to your Strategic Goal.
Just like with OKR, you also look at how you can understand you are approaching your goal. For this, EBM has 4 Key Value Areas (KVAs): Current Value, Unrealized Value, Time-to-Market and Ability-to-Innovate. For all these KVAs you have different metrics that can be helpful for you.
A metric for the KVA Current Value could be User Satisfaction or Employee Satisfaction. A measure for the KVA Ability-to-Innovate could be the Innovation Rate.
EBM also works with iterations. Every iteration, you work on something you think will bring you closer to your goals. At the end of the iteration, you use your current measures and compare them with your goals to understand if you are progressing well. Otherwise, you will find ways to increase your chances of success.
EBM is very much like OKRs. The main difference is that EBM helps you with finding the areas you wish to improve and ways to measure this. Obviously, you can also use these areas and measures if you prefer using OKRs for objective setting. Regardless, the objectives and Key Results I used as an example for OKRs can easily be translated into EBM terminology.
I also have some great experiences with EBM. I have had the best results using it for the transformation where the transformation teams used Scrum.
North Star Framework
North Star is a model for managing products by identifying a single, crucial metric (the North Star Metric) that, best captures the core value that your work delivers to your organization.
This is about one metric that you wish to change where OKR and EBM don’t rule out you may have several important metrics. When we look at the example I gave for the OKRs, we would for instance say:
“We are successful when we improve Time-to-Learn of a product improvement by 10% by the end of the year.” We would not look at the other two (which involved user and employee happiness). A reason could be that we expect they will increase anyway with the new way of working.
I do not have experience with North Star. I do think it may be helpful. That said, I like to look at multiple measures. Because focusing on one could lead to undesired side effects. As an example, the Time-to-Learn could be shortened by having people work overtime. However, the side effect may be that your people are unhappy or errors creep in.
Outcomes over output
As stated in earlier articles of this series, you wish to have a certain impact with your transformation efforts. This is why you should not define goals and measures that are focused on output only. Goals like “We have rolled out Scrum to 10 teams at the end of the quarter” therefore aren’t helpful. Scrum may be helping the teams to focus on effective value creation. But you don’t know until you measure that.
Involve the people
I also brought forward how important it is to involve your people. They are professionals and highly impacted by the transformation. On top of that, you wish to have more self-organization and collaboration. What better way to foster this than to allow them to contribute?
Workshops using tools like Liberating Structures have been very helpful for me. You can engage many people this way. It shows transparency and also you take your people, professionals, seriously.
Note
There are multiple ways to assess if you are heading in the right direction of achieving your transformation goals. The nice thing is, that these are all ways that are very much related to an Agile way of working. Using these approaches is not only helping you to stay on track. They are also showing your people you are serious with your Agile transformation, eating your own dog food.
10. Abandoning the transformation after a few months, never mentioning it again
It’s not a problem to abandon something that doesn’t bring the expected results. Perhaps a different approach can be more fruitful. And it’s always good to avoid the sunk cost fallacy: the fear of stopping something that has cost so much already.
But when you decide to abandon a transformation, ensure you properly inform your people. They have a right to know as it concerns them heavily. But it also may prevent them from being sceptical towards the organization and/or management. They may also be more open to the next transformation that will inevitably come.
Avoiding the pitfall
Regular moments of reflection
I have seen many transformations being kicked off with great aplomb. At first, we’d be well-informed about all the ambitions and achievements. But then the updates became scarcer and at a certain moment, there was nothing. Sometimes we’d hear in the corridors that the transformation was abandoned. But then we’d be lucky.
This wouldn’t have happened if the transformation team would regularly assess the progress of the transformation. In those cases, the sudden silence is a byproduct of another transformation pitfall.
If the transformation team had had regular moments of reflection, with their stakeholders, they would have had a way to communicate the end of the transformation. Firstly, they would have voiced it at the reflection event. But they would also most likely be triggered to ensure a broader communication happens.
Embracing the law of diminishing returns
A reason to quietly abandon a transformation could be because the goals set at the start were not going to be met. They might have been too ambitious. So the team drops the transformation like a hot potato. I certainly witnessed this exact behaviour.
But not meeting your initial objectives does not mean your transformation failed. Your efforts may have brought great benefits, regardless of whether you only managed to get to 80% of your target.
Maybe it would take too much effort, time and resources to reach all targets. Then it’s time to embrace the law of diminishing returns: at a certain point, your investments will return decreased incremental value (if nothing else changes). It’s time to make the decision to end the transformation.
Communicate
Sudden changes can prompt you to stop the transformation. And that is OK. But it is not OK to not communicate this. Therefore, you should put in one final effort:
Clearly explain why you embarked on the journey. The end of a transformation endeavour is a good moment to reflect on your initial objectives.
Highlight what you achieved. You wish to express clearly where you came from and where you are now. You may not have reached all your initial goals, but should recognize the lasting impact of your mutual efforts.
An Agile transformation is a complex journey. Your learnings may be beneficial for future similar efforts.
Express what changed to stop the transformation. This was one of the main topics in the fast months. Why are the reasons for the transformation no longer valid to continue?
Continuous journey
Your Agile transformation may end, but your organization will continue to transform. Especially when you enjoy an Agile learning culture, changes will become the norm. Whenever teams are impeded to achieve their goals of creating value, they will seek to remove the impediment. Also if these impediments are outside of the team.
So, regardless if you have a specific transformation initiative or if your daily routine is about continuous learning, the organization will never stop changing.
