Biggest Mistakes of Delivery Transformation to Agile Explained

As the companies move with software solutions from on-premise to the cloud, they often set themselves a goal to become more “agile”. This often should apply ideally to everything on a cross-company level. And, of course, everywhere at the same time.

Transformation of the processes could be easily possible, at least in theory. You can define scrum ceremonies and reassign people to new roles (like scrum masters, product owners, delivery managers, and scrum teams).

You can bring tools like Jira, Azure ADO, and Miro boards and make them mandatory to use. But what about the processes connecting the tools together? What about transforming people’s minds, behaviors, and ways of working? It becomes clear that those will not transform smoothly, nor will they finish quickly. Now, let’s observe why.

What Is a Delivery Transformation Initiative and Why Companies Are Doing It?

A huge part of companies today still work according to the waterfall delivery model. That means that:

1. First, plan what you want to do as the end result/product and how much it can roughly cost.
2. Start the requirements gathering process, where you thoroughly discuss all the details of the end product, objected to, questioned, agreed upon, again discussed, and finally confirmed.
3. Estimate the whole thing and confirm the budget expectation.
4. Design the solution. Conduct several meetings with stakeholders. Create various documents and let stakeholders review them. Confirm and approve the final functional and technical design.
5. Implement the solution based on the design. This is where you develop the complete end product.
6. Enter the testing phase and execute various kinds of tests: unit tests, system tests, functional tests, integration tests, performance tests, regression tests, user acceptance tests, and potentially many more (depending on the culture of the company). Document everything and let the stakeholders review and approve it.
7. Deploy the solution to the production environment. This is where the target users start using the final and complete product.
8. Schedule some support phase during which the development team corrects potential bugs of the solution.

This whole process might take a few months to a few years, and as you can see, users will see the results only at the end of that process. So, after long waiting comes the moment of truth (or failure).

If something changes during that long time and the end product should look a bit different, that’s a situation called a change request. The design must be reopened, reworked, and reapproved. It prolongs the whole time schedule by another part.

Clearly, this isn’t agile by any means. Every change requires a restart of the whole process before.

Switching to Agile

So, how do we get out of this situation and change it to become agile? The people work in the waterfall setup for many years or even centuries. They have roles and responsibilities they are comfortable with, and they do not want to change the status quo. The main reason for that is that doing this change ultimately means losing some of the power they had up until now.

This is the main reason why such change extracts the strongest level of resistance from the people that you can possibly create.

#1. Team Restructure

The first and relatively simplest to do is to restructure the people into scrum teams. Divide them based on the functional areas or any other logical split that makes sense.

The splitting usually goes smoothly; the problem starts when you realize that people are still bound to the original structures. Even if they are already part of the new scrum teams, practically, they are not. They still work on that old setup because they still have responsibilities that were not ended together with the team restructuring process (because why it would be – leadership does not care much about what needs to be finished, but mostly about what must be started).

So, practically, you end up with a scrum team that is not fully dedicated scrum team. It is a group of people that now simply has more work to do. There is not as much time for the work inside the scrum team as the management expects.

At the same time, the expectation is that the people will finish their original activities as well as this new expectation inside the scrum teams. It’s a setup determined to fail right at the beginning.

#2. Scheduling Scrum Ceremonies

Ordering the teams to schedule several regular calls (sprint ceremonies) is easy to define and start. At least, assuming your scrum teams do not consist of people from 3 time zones (which is often the case).

The problem starts when the people won’t join the ceremonies on a regular basis. Depending on who is missing and how often, this can evolve into various kinds of problems. For example:

• If product owners do not attend the planning and refinement ceremonies, the team has no new stories to work on. Or the description of the stories is so poor that the rest of the team cannot start working on them.
• If scrum masters are missing on the calls, the team is missing basic scrum orchestration and might get lost over time eventually.
• If the team members of the development team are often missing, they can’t synchronize with each other, and communication inside the team is much harder. Also, more meetings are required to catch up, which takes out yet another time from the team.

Ultimately, it’s not necessarily people’s fault they miss the ceremonies. It’s just the setup will not allow them to be on the calls (see above about parallel previous assignments).

#3. Team’s Stability

You might have a scrum team with structure and ceremonies, but if that team is not stable over a longer period of time – let’s say at least half a year ideally, a year of stability would be my personal minimal requirement – then such a team can’t really evolve and improve.

Next, you will probably never reach a fully independent scrum team that handles the sprints as business as usual. Finally, you will need to constantly educate and learn people inside the team to understand the scrum mindset and processes. It’s an exhausting problem to have.

This is a very underrated problem, specifically by the leadership or management of the company. Calling the teams of people just “resources” and planning their “utilization” from quarter to quarter is an instant road to hell.

#4. New Roles for the Same People

Another obstacle to overcome is reassigning existing people to different new roles. Those who previously managed teams with ultimate power might now become Product Owners, for example. This is a strong position in a scrum team, but it can be seen as a weaker role in relation to the existing setup.

Suddenly, the product owners must synchronize with the scrum master or program managers. They are still responsible for the content but not so much for the delivery processes. This situation requires giving up on some responsibilities that the people previously had and, therefore, is hard to swallow.

#5. Ways of Working

This one is interesting, and I hear it every now and then quite often – we need to learn new ways of working in order to become relevant in the evolving market where agility is the basic expectation. But what exactly does it mean those ways of working?

If you ask me, it’s clear what the management means by that – to achieve (much) more in a shorter time. After setting up the scrum teams, the expectation is that every team member will suddenly achieve some documented incremental results from day to day. If that is not the case, leadership will start to ask why the agile process is not working well.

Just out of nowhere, the leadership expects every hour to count and that the scrum teams have basically no idle time, just because there arguably is no space for that will all the scrum processes in place. And that is the definition of “new ways of working” from the leadership perspective in a nutshell.

Of course, this expectation isn’t built on the reality check. It’s illusional to expect people in the company to start working more within the same period, just because some day-to-day processes will change. I mean, some of them could, even if only a minority. However, even this group is further reduced by cluttering them with more tasks at the same time.

Difference Between Target and Reality

There is no doubt the description of the end goal is often good, and it makes a lot of sense. It goes around the following principles:

• Stabilized scrum teams working on independent backlogs with clear KPIs and OKRs.
• Product owners to build up solid roadmaps and plan prioritized content to deliver against concrete timelines.
• Defined backlog content with relevant features already detailed before the work started.
• Reliable testing processes executed alongside the regular sprint development work.
• Regular releases to production – at least once per month, but ideally after every sprint completion.
• Risks and issues tracking and communication between the different scrum teams in case of dependencies.

Then, when it comes to reality, I can tell that none of the points above are easy to achieve.

• You form the scrum teams, but they are constantly changing (from quarter to quarter). You invest time to teach the team the scrum processes, and once they finally start to accept it and change their ways of working, you reorganize teams for the next period. Roadmaps are modified, shifted, or canceled.
• Product owners have no real clue about the roadmap details, and (just because they had such habits before) they will assign their tasks of building up the backlog content directly to the team. As a result, the team has no time to develop the content as they first need to figure out what to develop.
• Testing processes are only manual and require a lot of substeps and approvals and complicated processes to follow. That means there is no way the testing can finish within the same sprint as the development does.
• As a consequence, release to production is lagging several sprints behind.
• Communication between the different scrum teams is chaotic and ineffective, as every team has each sprint a lot of activities to accomplish. In fact, product owners tend to assign to the team too much of content each sprint. There is no chance the team can complete it all, so they are constantly under deadline stress.

Correcting the Mistakes

Having experience from a few agile transformation projects, I’d like to summarize some of the biggest mistakes I experienced and give some subjective opinions on possibly overcoming them.

#1. Right Responsibilities for Right Roles

If you try to bend the definition and distribute the responsibilities in any other way than they should be by the scrum/agile, you are putting the whole initiative to failure.

• Product owners shall own the content and maintain the backlog. They are responsible for the backlog stories, and if the backlog stories are not well defined, it is up to them to take action and fix it. On the other hand, they should not have any influence on scrum team people assignments or decisions about the project budget.
• Scrum masters shall not have any responsibility regarding the backlog content. They are on the team to orchestrate the ceremonies and educate the team in an agile way of working. They shouldn’t be a secretary for Product Owners. On the contrary, they shall protect the development team against the product owner and external stakeholders.
• Every scrum team shall have assigned a delivery lead. This person will connect the PO, SM, and development team into a workable setup, define delivery processes, and resolve any potential risks, issues, or conflicts the team might have. The delivery lead is the right person to decide the project’s staffing and budgeting questions. This person shall strive to build an environment for the team where everybody can perform at their best.
• The development team’s responsibility is to develop the stories from the backlog. They can help PO to build content for some stories (mainly those that are too technical), but they aren’t responsible or not even accountable for stories building the roadmap content creation.

#2. Stable Team

Investing in the team’s agile education is important and must be a fast process. Leaving this knowledge to go away every few months is just a waste of time for everybody.

The first five sprints you can use as a learning curve for the team to get to know and practice the basic scrum activities. Once those are clear for the whole team, the continuous improvement process of the scrum team can start. But if the people inside the team are changing regularly, you will find yourself in a constant loop of knowledge transfers and education.

Such a team will probably never reach full performance potential, and the leadership team will continue to wonder why it was previously (before the agile transformation) more efficient than it seems now.

So, build the team, invest the knowledge, and once the team is confident with the new processes, just keep it as it is and develop further. From here, the constant road towards perfection shall start.

#3. RACI Matrix

It is a good practice to build up and agree on the RACI matrix (Responsible, Accountable, Consulted, Informed) between all the teams just before the real work starts. This can potentially eliminate a lot of confusion right at the beginning.

It is quite important, especially in the early stages of the transformation initiatives. Otherwise, the people will start raising questions about who should do what in what situation, especially in those that were not explicitly addressed via the team’s communications.

Here is an example of such a RACI matrix for some of the responsibilities. Your project can have a different set. It is important to capture the relevant ones.

Conclusion

There could still be a lot to write about, as there are many ways and many places where the agile transformation can lead off the track. The purpose was to point out some of the problems I consider to be repeated often.

The initiative itself is a good idea. However, it can quickly become a nightmare for all the participants if you obey some basic rules. I highlighted a few of them, but just use common sense, and you shall be fine. 🙂

Next, check out good learning resources for Agile certification.