A few days ago, I was contacted by… well, let us call him Peter. Peter, the CIO was leading the transformation to agile in a (by Nordic standards) large global company in the financial sector. They had been working agile with SAFe for more than 6 years, but Peter and his fellow managers were still not seeing the results that they had expected to get out of their large investment.

They had done all “the right things”. They had changed the organization as described in the SAFe framework. They had plenty of management buy-in as the decision to “go agile” was taken by the top management with the support of the board. They had gone from the concept of projects to products, just like you are supposed to, so why did they not see any major changes in productivity and outcome?

Peter contacted me because he had come across by new book about agile transformations in practice (the book is in Danish but is currently being translated into English), and he wanted my opinion on enterprise agility, and whether I thought that it was at all possible to achieve.

He was curious to know what experiences I had had with enterprise agility after having worked as an agile consultant, coach, and trainer for many years.

Peter’s main concern was, as mentioned, that they did not see any concrete improvements in terms of faster completion and higher quality. Sprint goals were often missed, and rework often necessary, but Peter was still convinced that working agile was the right way to go.

Are you feeling agile, or do you know that you are?

I started asking a few questions about how the teams themselves felt they were doing, and if they were measuring their own performance. (You are supposed to measure progress no matter what agile method or framework you use).

The answers were:

1. Most teams felt they were very agile. They attended the meetings that they were supposed to according to the SAFe framework. They had a Scrum Master and a Product Owner and worked from a Product Backlog, and were part of an Agile Release Train, so what more could anybody possibly want?

2. No, the agile teams did not measure their own performance. They had talked about doing it, and a few of the teams did not mind measuring, while others were convinced that this was something that the management wanted to control them and check if they were working hard enough.

Both examples are behaviors that I have seen again and again on my agile assignments. Although there may be a sincere wish to achieve higher agility, many come to a full stop when they have changed their organization, introduced the new roles, and started up the new sequence of meetings as prescribed.

But when did organizational change in itself ever facilitate improvements? And what improvements are gained by changing the name of a requirements specification and call it a product backlog? Change only happens when behaviors change, and you can only know that your agility is increasing if you can back it up with data based on quantifiable facts. Feelings are good, facts are better.

Transparency is not optional in agile systems.

Behavioral change is not trivial, and it will not happen unless you plan for it. I have had quite a few discussions with other agile coaches who insist that change should happen organically, and bottom-up. This might work in theory, and if you have all the time in the world (as well as money) to wait for that change to happen, but if you don’t, and if you don’t like random change, I strongly recommend that you plan for the changes that you would like to see. Different goals require different actions.

Transparency is a very important part of the agile DNA. Continuous improvement are key words too, but you cannot improve what you cannot see.

Knowing your agile status because your data proves it is one way of creating transparency. Visualizing impediments, blockers, dependencies etc. is another. Analyzing what is blocking you, why and for how long, and being crystal clear about how you prioritize and visualize your product backlog also creates transparency. These are only a few examples, but transparent processes, decisions, quality standards etc. could be added.

Transparency is a prerequisite for making agile methods and frameworks work as intended but being transparent seem to be almost intimidating to some people. I have met quite a few who are uncomfortable by being complete open about their work, their mistakes, doubts, (lack of) competencies etc. But openness and knowledge sharing are key in agile systems, where the members of cross-functional teams are heavily depending on each other’s knowledge.

But let’s get back to Peter and enterprise agility.

Enterprises and silo-mentality

During my discussion with Peter, we also talked about silos and silo thinking in his company. I asked whether they during their SAFe transformation had been able to break down their silos and go “all-in” on the SAFe organization.

Peter’s answer was no. They had tried to get away from their old silo-organization but had not succeeded for several reasons, e.g.:

1. Some managers and employees did not want to give up or leave “their” old silo, and did not buy-in to agile thinking
2. Many legacy systems required a special team (a silo) to maintain and operate them. They could not allocate people full time to anything else
3. Old habits. Personal and team habits. And eg. the reward system was still based on silo performance

I guess that most managers have become managers because the like to have the power to make decisions and control and dispatch their resources, so maybe it is not so strange that some managers work against agile ideas such as self-managing teams, and more team-autonomy.

Working with my clients I always ask: “What will you do when (not if) you experience that managers or team members work against what you are trying to achieve with your agile initiative? Will you accept it? Will you fire them? Will you place them elsewhere in the organization?

One thing is sure. It is highly disturbing if just one person in an agile team is obstructing the agile ways of working. It slows down progress, and the cultural change that must take place. The work environment suffers.

However, even if it is big dilemma and a tough decision to make, you must decide how to deal with those that disagree to work according to new agile ways, in this case SAFe.

New solutions planned to be built by the agile teams would usually have interfaces to one or more legacy systems and would therefore need resources from the systems teams. Those resources became bottlenecks, which resulted in unavoidable unpredictability. Sometimes they worked in their agile team, sometimes in their system silo.

Unpredictability was also the result when e.g. managers, often high-level, asked teams or individuals to do them a small favor and work on new ideas or activities that they found important. I.e. activities that were not prioritized in the sprint backlog.

It is not a sign of good health in an agile system, where unprioritized activities are allowed to move directly into the fast lane, because a manager asks you nicely or maybe yells at you. It introduces risks to your plans.

You get what you measure

Old habits are hard to break. We have heard that many times before, but it is true none the less. Nothing is easier than just keep on doing tomorrow what you did yesterday.

So, if your reward system favors old ways of working, and do not support the new way, it should come as no surprise, that people will work in the way that leads them towards the goal that can potentially affect their own financial situation positively. Of course!

In Peter’s case, the ambition was to get all agile teams in agile release trains in sync, so they delivered value faster, and with higher quality. But the reward system pulled people in a different direction.

Of course, it can be costly to change your reward system, but if you spend millions on an agile transformation, why not take the effort to change your reward system too? If it favors those that work in accordance with agile principles and values, help smooth the way for the agile teams, and work to remove or minimize bottlenecks, cross-team dependencies, blockers etc., it will go hand-in-hand with the transformation effort and facilitate quicker positive results.

So, is enterprise agility an impossible dream?

Well, it depends on the method or framework you choose. If the method/framework is very complex it will only work as intended in high-maturity organizations that are not change averse.

It is a sign of warning, if you have to employ many agile coaches (overhead) to support the agile organization. Then the method/framework is probably too complex. Coaches that can help kick-start or re-vitalize agile initiatives are fine, but they should not be on board for ever.

Based on many years’ experience as an agile consultant, coach, and trainer, my conclusion is:

1. Keep things as simple as possible and go for a method/framework that fits your context. A “one-size-fits-all” does not exist. Choose your agile direction for the right reasons and avoid the “lemming effect”
2. Be explicit about what behavioral change you expect from people and what is in it for them. “Agile” is neither easy nor intuitive, and most employees are not hired to be method experts. Therefore, be clear about what people need to do differently and explain the benefits from changing
3. Measure, measure, and measure. Use metrics such as lead time, that show your actual performance and efficiency. Avoid vanity metrics that may make you feel good but tell you nothing about efficiency. Act on the findings
4. Make plans for continuous improvement. If you don’t you risk getting stuck at a low maturity level. It happens a lot, but it does not have to be that way.

Achieving enterprise agility is difficult but not impossible. It will certainly not happen overnight or just because you make organizational changes. It’s people and new behavior drive change.