Faster, more focused and centred around users’ needs – and therefore a better use of the organisation’s or unit’s resources. That is the purpose of agile work. And doesn’t that sound intriguing? The agile mindset is often rolled out quickly in many companies. More and more managers claim to be “working agilely”. But how do you maintain an agile mindset to thrive and grow in the classic zero-error and project control culture that dominates most larger companies?
Imagine this scenario: The IT department of Alfa Finance implemented agile development. Among other things, this means that they prioritise current needs on an ongoing basis, according to how important they consider them to be. In other words, current needs are continuously prioritised according to importance/the IT department’s assessment, after which the IT department solves them in the order that they themselves have prioritised them. Then imagine that you have asked the IT department to solve a problem for you. And now you want to know when it will be resolved. When you ask your IT department for an update on the problem, the answer is: “it’s in our backlog waiting to join a sprint, so we can’t say yet. But it has been registered.”. Your first thought might be: “how unprofessional – they’re never on top of things in IT”, while IT is thinking: “we are efficient – we solve the most important problems first, creating the greatest benefit for the rest of the organisation”.
So, this is a clash between the agile mindset and the classic project and zero-error mindset. A clash involving your need to know when your IT problem will be resolved so that you can consider it in your planning – which makes perfect sense when you are on the receiving end and want to be able to plan your work for the coming period. And when you are stuck with a task until IT has solved the problem. And the agile notion that we solve projects in small chunks and continually prioritise, re-prioritise and organise in accordance with what makes the most sense.
And IT is not the only place where this can cause difficulties. What about when you need to report to the board? You cannot present a classic project plan because it does not exist when you work with agile processes. Or what about when the board asks who approved a key decision? And the director replies that the agile team probably made the decision themselves. And the board wants to know whether the decision was sent for approval by a director, and the answer is no because that does not align with agile workflows?
Or when you are negotiating with a supplier regarding the development of a new concept or service, and they cannot put an exact timeframe or price on it because they are agile? These three examples may sound fictional, but they are all real-world examples that come from a number of our customers.
Now, this article may seem to go against the idea of agile working. That is not the case. But it does illustrate a number of issues a company must get a handle on if agile is to gain acceptance in the company culture:
- Where is the line between agile and traditional? Between zero-error and fail fast, learn fast
- How do you encourage employees to dare to work agilely?
- How do you convince management to buy into agile and feel secure?
We will take a look at each of these three questions in the following text. Each of the three questions deserves its own article to be explored fully, so we will only outline the main elements here.
Where is the line between agile and traditional?
Many organisations are currently focusing on rolling out the agile principle. And of course, that is a good place to start. But a number of processes – e.g. in connection with board reporting, financial overviews or investor relations – are hard to place within an agile framework. Investors and boards of directors typically like to have a plan for how a development will run, how long it will take, how much money should be allocated, and who will be responsible for it. And managers still struggle with the idea that you must define how many resources and how much time you will spend on a product – but not the final scope of the solution.
If, as management, you are faced with e.g. a risk-related problem, you will want to make sure that the problem is resolved before the resources run out. But agile contract management does not ensure the result, only the resources. Or in other words: In agile, you allocate resources – e.g. 1,000 hours for a project. Then you use the resources as efficiently as possible to remedy the problem – but without being absolutely sure in advance where the project will end up and whether the resources are sufficient. This risks the recipient and sender being out of alignment. It is therefore a key role to define and communicate which processes are agile-driven and which are run by more traditional (waterfall) methods. In particular, processes affecting external actors must be reviewed as one can easily run the risk that the effect of the agile is offset by the hassle of communicating the process and results.
Many organisations currently implement agile ways of working through a kind of bottom-up process: It starts with an IT development, spreads to the rest of IT, and then continues on to other projects within the organisation. And sooner or later, it will have an impact on the operational areas of the business, where people will find it harder to see the benefits of the agile principle (which has essentially been designed for development and not for operations).
We therefore recommend that you spend resources on identifying which processes you want to make agile. And that you complete an agile rollout of the agile principle: That is, rather than wanting to do everything agilely all at once, go through a feasibility phase for each project and determine whether it makes sense. Is there a good business case? If not, leave it in the old project culture. If yes, roll it out in iterations and bring the agile mindset to life in the specific project bit by bit.
How do you encourage employees to dare to work agilely?
Resources, security, overview. A cultural change takes time and requires you to help people adapt. They need to see how an agile culture can help them and create value in their work. And they have to get used to not having turnkey solutions done in one go and without errors, but rather build everything from small chunks that may be imperfect and need further development and adjustment before they can work. This is not easy if, for the last 20 years, you have focused on planning everything carefully to avoid making mistakes!
Employees must also see and feel that agile is only implemented where it makes sense. All too often, employees feel that they are exposed to new management mantras that they find difficult to understand or see the benefit in. There are three objections we hear particularly often: ‘I work hard and don’t have time to start working differently’; ‘I can’t see how it makes anything smarter – we’ve already thought about what we do’ and ‘what is it I need to do differently – I don’t understand the difference?’.
One of the tools we always find to be effective when you need to create change and make it concrete: What is it about the agile method that is different to the way we have worked in the past – and what am I expected to do differently? In communication and rhetoric, concretisation is called evidentia, which means to ‘make real’ and ‘be able to visualise something’. And it comes from the same root as the English word ‘evidence’. So we use what is concrete as a sort of evidence that can enable employees to visualise the change.
The number of times we have experienced employees frustrated by ‘having to work agilely’ without quite understanding what it means to their work and what to do differently is immense. And often, the use of evidentia will demystify things and make employees exclaim ‘oh, is that all there is to it? Well, that makes sense’.
Another approach is to use the old sales model: the FAB model, which you, dear reader, may be familiar with. While it is certainly out of fashion in a lot of sales work, we like to bring it back to life in internal communications, where it has proven to be quite effective.
FAB stands for Features, Advantages, Benefits. And in relation to implementing an agile culture, you might say that the agile concept has a number of features, a number of advantages and hopefully a benefit. The features are e.g. the elements of agile. It might be having a scrum master, running sprints or continuously prioritising tasks rather than making a fixed roadmap from the start. Among other things, the advantages are that you can focus on the main elements at all times, continuously adapting your work to a changing world. Benefits can include customers getting better solutions in less time and you continually solving the most important problems.
Imagine that you are launching agile ways of working in a new unit within the organisation. You can choose to talk about how the agile concept is structured, what roles it involves and so on, i.e. focus on the features. Unfortunately, our impression is that this is where a lot of people start their agile culture implementation.
Or you can talk about the benefits – what we might call the ‘why’ in modern management language. In this way, you can review why there is even a need for new ways of working, and explain what it is that agile can accomplish and why the benefits will be greater than with the old ways of working.
We might as well reveal that the latter is more effective than the former.
How do you convince management to buy into agile and feel secure?
When it comes down to it, managers are not so different from employees. Therefore, the approaches described above can be largely recycled. One example of evidentia in use was when one of our customer’s digitisation team had been working on a new customer portal for the company’s website. They had taken the agile approach and had designed their own solution: The company’s customers could perform a series of calculations themselves, thus obtaining a quick overview of their situation.
When the solution was presented to the directors, the digitisation team focused on explaining the features, advantages and benefits. The new solution was more user-friendly, made calculations faster and had a higher level of IT security. Therefore, the digitisation team considered their solution both smart and efficient. But of course, not quite finished, as the last refinements and quite a few functions still had to be added. Very agile, in other words: We make a mini version, test it and develop it further as we learn.
But there was resistance: In the minds of the directors, the new solution was still unable to live up to the previous one, and they were concerned about whether it was ready for launch and whether it had too few features. In other words, the directors expressed a project mentality and zero-error culture: When we are presented with something that is going to be launched, we expect it to be finished and free from errors.
Several meetings were held at which scenarios for progress were discussed. The digitisation team repeatedly presented data, measurements and customer quotes that showed that the new solution had the potential to be better than the old one. But without much success.
Until the digitisation team got a tip that they might want to try employing evidentia. At the next meeting, they simply went through the new solution: They showed it on a screen at the meeting, they tested it with the directors and they showed the directors how customers might use it in different situations. The directors were simply brought along on the agile journey and were talked through why and how the solution came to be the way it was. They were also told what was still in the development process; i.e. what was still missing in the longer term. After that came acceptance. Enthusiasm, even.
So even directors can be dismissive when they cannot see something for themselves and are stuck in a non-agile mindset. They may see something in a different way to the agile unit. Concrete, demystifying reviews may be the most effective things here.
The second approach that must always be taken (and is easily combined with evidentia) when you want to instill a sense of confidence in management is involvement. Directors and managers like to be in touch with what is happening in their organisations. And if they think something is good, they will usually back it. If a director has been involved in an effective sprint that solved a problem or has helped to prioritise a backlog, they will feel involved. And as a result, more secure. Implementing agile culture therefore requires you to invite all managers to be close to the process. You must also encourage them to participate in the prioritisation of which tasks will go into a sprint (i.e. are moved from product backlog to sprint backlog). And fortunately, this fits very well with the role of ‘product owner’. This gives them an understanding of how they can support an agile process – and how they can think in agile terms. Without focusing on zero-error and long processes. This allows them to better support the implementation of an agile mindset and feel secure along the way.
As mentioned earlier, this short article will not solve all the cultural problems you might face when the agile clashes with a classic project culture based on zero-error. But I do hope that it has given you a few tools to use when the agile concept is to be brought to life in your organisation. Beyond that, you are very welcome to give me a call for more advice.
Get an introduction to scrum and agile work methods here: