Agile Transformation mistakes you must avoid at any cost!

One of the pillars of the ADAPT Methodology™ is the Agility part, that`s why talking about Agile Transformation Mistakes is very important!

In this blog post, we make you aware of 14 common Agile Transformation Mistakes that you must avoid at any cost! If you are an executive leader looking to ADAPT your company to the digital era check more about our approach in this link: ADAPT Methodology™.

[sc_pathway pathway_title="The Agile Transformation Roadmap" pathway_description="Do you want to do an Agile Transformation but you do not know where to start? This roadmap will help you! The Agile Transformation Roadmap was created based in several years of Agile transformations operated in Europe!" pathway_button_text="DOWNLOAD THE ROADMAP" pathway_button_url="https://adaptmethodology.com/agile-transformation-roadmap-en?utm_source=ADAPT_Blog&utm_medium=Site_PopUp&utm_content=Welcome_PopUp&utm_campaign=Agile_Roadmap" /]

In 2004 I got my first job in NOKIA, I think I was lucky to be in the right company at the right time. At that time I did not know how much that job would impact my entire career.  Now, I have spent the last 15 years helping organisations become more Agile, Flexible, Lean and Faster. During these 15 years, I've seen a lot of Agile Transformations and I realise that most of the companies do the same mistakes over and over again.

I want to help you to succeed in your Agile Transformation and because of that, I wrote this article where I share 14 Agile Transformation Mistakes that organisations do when going through the transformation.

Agile Transformation Mistakes

1. Agile Transformation Executed Only On Team Level

Most of the organisations make this mistake. They believe that Agile transformation means simply implementing Agile only on the team level. Unfortunately, this will never work.

Actually, it might work during one or two years but after that, the development teams will start to hit the organisational barriers and everything will get messy.

Some of the symptoms that you might face in case you just implement agile on team level:

1. Teams might start delivering software faster than the business can produce business requirements.
2. Agile will bring a lot of transparency, therefore a lot of organisational problems will start to appear, but the organisation does not really improve.
3. As a result of this, people will start to complain and say that they had less problems before they started implementing agile. For your understanding, the problems are and were always there, but they were not visible :)

Solution

If you decide to implement agile in your organisation, make sure that you as a leader are ready to change as well. And more importantly, that you are ready to change the organisation as a whole, not only the development teams.

Agile Transformation implies that you change:

• the structure of the organisation
• the way how you cascade the strategic goals down to the operations
• the way how you manage failure in the organisation
• the way how you share knowledge within the organisation
• the way how you drive innovation
• and most importantly, the way how you manage and empower your workforce

I truly believe doing Agile Transformation in the entire organisation is the only way to do it right! You can start on the team level at first, but at some point the business and the organisation will be affected as well!

2. No connection between teams and the company strategy

Many companies mention they go through Agile Transformation but I often don't see any connection between what the teams deliver and the strategy of the organisation. Most probably this happens because the organisation skipped the previous step and they just apply the transformation on the team level.

You will see dozens of teams developing great stuff on a daily basis but without any clue how their work connects to the overall strategy of the organisation.

Solution

There are several ways to solve this problem but I usually recommend two different solutions. You can implement an Agile Portfolio Management process or  Objectives And Key Results (OKRs).

I personally believe that in a transition phase the Agile Portfolio Management could be a good approach since most of the organisations have already some kind of Portfolio Management process. When the organisation is more mature and is ready to transform itself into a product organisation, then I recommend the OKR approach.

The most important thing is that everyone in the organisation is able to map their work to the overall strategy of the organisation.

3. The organisational structure does not change

As I mentioned before, most of the companies believe Agile Transformation represents implementing Agile on the team level, therefore they do not change the way how the organisation is designed.

Typically, organisations are designed using the old-fashioned matrix model that is completely outdated when you want to design a product organisation (most of the cases in today's world). If you want to know more, you can check this blog post: "Why a matrix structure will destroy your company".

When work in agile, you will need to change to accommodate the different paradigm shift that Agile brings.

Solution

If you are a product company and you want to be serious about Agile Transformation you must change the way how your organisation is designed.

Nowadays most of the companies are optimised for efficiency, that's why most of them have the matrix organisational structure. However, when you create a product organisation you must optimise for speed, therefore, a value stream model is much better.

Some time ago I wrote an article explaining how you can reduce time to market by using these ideas, this article can be found here: "Time To Market, What Is It And How Can You Speed Up The Process".

4. You see your Agile Transformation as a cost

Many executive leaders see the Agile Transformation as a cost and I believe this has to do with the fact that most of the companies still see the IT department as a cost and not as a business enabler.

If this is your case, you are not seeing the big picture here.

Solution

The first step is to start understanding that you are in the digital era, therefore everything is moving towards digital. You must understand that your IT department is a business enabler and not a cost.

When you have an IT or a digital product department that is agile and fast, you can satisfy your customers like never before.

You are able to understand their needs and wants much better, and you are able to test different versions of your product that will guarantee you sales growth and customer satisfaction.  You can create different revenue streams like you never imagined.

Let me give you an example. Some years ago I had the pleasure to work in a travel agency company in Germany. If you talked with some of the employees they would tell you they were a travel agency, that's it. But there are some employees who tell you they are an e-commerce company. And the executive team also understood the IT department was not anymore a cost but it is a huge business enabler. They decided to transform the company into a digital product organisation.

In the past, this business was done using physical travel agencies, nowadays the company has more than 1 million visitors a day on their website. Just imagine the business impact their online site (product) brought to the company.

Therefore, start looking at the IT department as a business enabler and not a cost. Start to see the Agile Transformation as something that will help your business to succeed tremendously!

5. Teams - 2 weeks cycle vs Organisation - 12 months cycle

It's very common to see companies with agile teams usually working on a 2-week cycle but the company working using a 12-month time frame (or even bigger).

This is a clear sign that something is wrong and that the organisation implemented agile only on the team level.

Solution

In today's society, companies cannot afford to be working with yearly goals, they must be able to adapt to the market much faster. It's ok to have strategical goals with a 2-3 years horizon but the company must be able to have short-term goals that are delivered much faster.

To tackle this challenge, companies must be able to transform the way how their organisation is designed and start implementing OKRs or Agile Portfolio Management processes.  In this way, companies would be able to define quarterly goals that are aligned with the 2-3 years company strategy feeding teams' backlogs with their bi-weekly deliveries.

6. No clue how the software impacts the business in general

It is often forgotten to make sure a company understands how the software impacts its business.

How many of you work at companies with dozens of software developers who have little or no idea how the result of their work impacts the business?

They might have an idea why they are doing that but do they really know exactly how much money their efforts will bring? If they do, then it's awesome! It's definitely rare to see it!

Solution

When you perform Agile Transformation, make sure you implement what I mentioned before - OKRs or Agile Portfolio Management. Then create a process to include the Cost Of Delay for each feature.

As a summary, the cost of delay tells you how much money you are losing for each day/week/month without the feature being in production. If you want to know more about the cost of delay just follow this article: "Cost Of Delay".

7. Create a "Digital Transformation" department out of PMOs

It's very common to see people who are part of the PMOs (Project Manager Officer) be appointed to lead the Agile Transformation Office but I think that is a huge mistake.

When I work with executives, I often mention that PMO is one of the biggest organisational barriers to a successful Agile implementation.  Many agile values are completely against the ideas of “old school project management” theories so the overwhelming majority of PMPs or PMOs will apply agile as a process rather than a mindset.

Once you have a problem that you don't know how to solve, you will immediately re-apply what the PMP says.

A few weeks ago I had a session with my client who shared a few challenges with me. I suggested to use a physical board and forget about any virtual tools, without going into great detail. I told him that probably by implementing some of my ideas, the engagement on the Daily meeting would increase. It was hard to believe him when he told me he couldn't use physical boards because Agile Office forced people to use JIRA.

This is a great example of how old-fashioned PMPs will try to create standard processes instead of helping teams find their own solution.

Solution:

If you really want to have a successful Agile Adoption, avoid giving PMO this responsibility. In most cases (exceptions happen), they are by far the least that able to take such responsibility…

Hire a specialist company that can help you. But double-check that consultants are no longer Scrum Masters who are certified PMPs.

8. Old School Director In Charge Of The Agile Transformation

I think this problem is related to the previous one, but it still differs. Lately I've met several people who told me a very similar story.

They all reported to Directors of Agile Transformation but they were simply old school directors that were put in charge to lead the whole transformation.

Usually, old-fashioned managers are very political and love to look great in front of their bosses, therefore, they will never be transparent with the organisational impediments and will never be supportive to the people that are part of the transformation.

And often these managers have a completely wrong background experience to do this kind of work.

Solution

When you decide to implement Agile Transformation try hiring someone that did it in the past! I am not saying that you will not have competent people in your organisation to lead this transformation but to be very honest they chances are very low.

Agile Transformation is too important, make sure that you hire a person with the experience.

9. Hiring One Of The Big Management Consulting Firms

It’s easy to be tempted by the glossy brochures of the big traditional management consulting firms that offer digital transformation services. This is especially true for bigger corporates (e.g., banks, telcos, big pharma companies, etc.) looking to reinvent themselves in the digital era.

The irony is that whilst they might offer reputational reassurance to a Board of Directors, these consultants are actually the least digital themselves and are, at best, old fashioned in their systems and approaches.

Therefore, don’t be lulled into a false sense of security simply because they’ve acquired a roster of smaller management consultancies in order to shore up their own shortcomings.

Solution

There are several companies out there that are specialised in Agile Transformations and have a good name, of course, we are one of them :)

So in case you are serious about your Agile Transformation hire one of the specialised companies, I am pretty sure you will have good results.

10. The Team Lead Becomes a Scrum Master

Most of the organisations want to perform Agile Transformation but they want to ignore some of the agile values. It's seen quite often that companies appoint the Team Lead the new Scrum Master.

Of course, this is a disaster!It's not any coincidence that Scrum "tells" us that we should not have a hierarchy within the team. We want to build self-empowered agile teams, however, having a team lead inside of the team will destroy the whole purpose.

Imagine a scenario in which a team has a retrospective session, they mention several problems which are caused by the team leader! Can you imagine any of the team members raising the voice towards the team lead? I don't think so...

Solution

If you truly want to create a fantastic and self-empowered team, leave the team lead out of the equation.  Having the team lead is a huge anti-pattern to creating self-empowered teams.

You do not need team leads, you just need great Scrum Masters that know how to create a fantastic team out of individuals. Of course, Scrum Masters that do not have any hierarchical power over the team.

11. The Project Managers Become Scrum Masters

Nowadays theres is a big number of people who have been Project Managers for years and suddenly become Scrum Masters within the same organisation, doing the same work but now with the title of Scrum Master.

Organisations still do not realise that the Project Manager and Scrum Master are completely different roles.

A project manager is someone who knows the business well, someone who has a very good network within the company and makes things happen. If you need a Project Manager, you even put a little pressure on teams to make things happen faster. It is someone who often has the budget and responsibility for the whole project.

The Scrum Master is almost the opposite role. The Scrum Master knows the process very well (usually not from the business point of view), has also have a very good contact network but has no power. He helps teams find the best solutions and is there to serve the team.

The Scrum Master has no budget or decision power. I do not want to say that the Project Manager doesn't become a very good Scrum Master. I know some, but usually, the result is not the best.

Solution

Next time when you work with agile product or project, think of Project Manager as Product Owner.

Try to get a non-Project Manager Scrum Master. Try to identify someone within the organisation who is very good with people and who uses influence rather than persuasion, you may even be a project manager but be wary of this choice.

As mentioned before, you want to make sure you build a complete self-empowered team.

12. Agile Coaches are the same as Scrum Masters

I know there is a lot of confusion in the community when we talk about Scrum Masters vs Agile Coaches.

At the end, you should be aware of something very important: you need to have someone to help you with the teams and someone to help you with the organisation.  These are two completely different types of work.

Usually, the Scrum Master is focused on the team level whereas the Agile Coach is focused on working with executive leaders and with the organisation itself. But I often see that everyone calls themselves Agile Coaches without any related experience.

Solution

After all it does not matter if you call a person Scrum Master or Agile Coach, however, but make sure you know what you are doing! Make sure that you have someone to work with the executive team and the organisation because having just a Scrum Master/Agile Coach on the team level is a recipe for disaster.

13. Not hiring experienced external Agile Coach

You might think that you are able to do whole transformation alone without any external help, but... I have some news for you, the chances of success are very slim.

You know, implementing agile is not changing a process. Agile Transformation requires a paradigm shift in the way how you run your company. And usually, utilising people that did the same stuff in the same way in past will not bring the results that you need.

When you try to do the transformation with the help of the "old" PMO and old-fashioned director this will (most probably) cost you lot of money! Remember, it's much more expensive to recover from a bad implementation than hiring a person that knows what is doing right from the beginning.

Solution

As mentioned before, there are companies that are specialised in these kinds of transformations. We at evolution4all can help you with that, but of course, we are not the only ones. Always do your research!

The important part here is to be humble and understand that many of us spend our entire career dealing with these problems. So, do not try to do everything by yourself.

14. Not providing training to EVERYONE

The last mistake and the one that I find the most common in organisations is that agile transformation initiatives do not take involve everyone that is impacted by the transformation. Organisations usually provide training to the Scrum Masters and Product Owners forgetting all the others.

Everyone says people do not like changes, I do not agree with this argument. I truly believe that people do not like the change if they do not understand what will happen, and of course, by implementing a huge change and ignoring most of the people involved, you are asking for troubles.

Solution

When you do Agile Transformation and you explain to people how this transformation will help them as persons and professionals, most of the people will be on board. Of course, you will maybe have the early adopters and the ones that must be convinced a bit better and the laggards.

With laggards you can't do much. In my opinion, you should even think if you want to keep them in your organisation since they (in most of the times) are a huge obstacle for a successful transformation.

If you are thinking of doing an agile transformation, make sure that you provide training to everyone that is involved and is interested in learning more.

In Summary

Agile Transformation is not easy, but to be honest, I think companies make it more complicated than what it needs to be.  Every company is different but if you start your implementation considering all the ideas and tips I mentioned in this article, I think you are starting with the right foot. I really hope you succeed with your transformation.

Did you like this article?

We enable leaders to become highly valued and recognized in order to make an impact on the World by helping them to design Digital Product Companies that will thrive and nourish in the Digital Age, we do this by applying our own ADAPT Methodology®.

If you want to know how we can help you check the page: Work With Us.

If you are interested in knowing if you have what it takes to build a Digital Product Company take the Scorecard.

If you want to learn how to build a Digital Product Company take a look at our Digital Leadership Accelerator.

[sc_product_cta product_title="Will You Succeed Or Fail As A Leader In Designing Your Digital Product Company?" product_description="If you want to know more about your company's digital product development maturity just take this scorecard. It will help you to identify all the different areas that you can improve and build a truly Digital Product Company." product_img="6440" cta_url="https://digitalproductmaturity.scoreapp.com/?utm_source=ADAPT_Methodology&utm_medium=CTA_Box&utm_content=Agile_Transformation_Mistakes&utm_campaign=ADAPT_Scorecard" cta_url_button_text="TAKE THE SCORECARD" /]