If it looks agile and is called agile, could it still not be agile?

I interviewed my dear colleague Sami Lilja for this article. It's part of an anthology I am writing about agile practices. It’s not only about software development, but rather about modern ways of organising work, leadership and making sure the desired targets are reached. This article looks into the many ways organisations try to be agile, and sometimes miss some key points and it prevents them from succeeding. Sami Lilja is a pioneer in agile practices. His expertise on the topic began to develop during the growth years of Nokia and eventually shifted from technical challenges to issues related to organising work, people and interpersonal dynamics.

He studied computer science at university and worked at Nokia as a software developer, project manager, team leader, and department head. Everything had to be planned, reported, and put in order very traditionally. During his career at Nokia, Lilja worked in China, where he encountered? Bas Wodde. Bas is known as an agile coach and developer of the LeSS model (Large Scale Scrum).

There was a collision as their different worlds met. Sami strongly believed in planning, reporting, and control, while Bas swore by agile. They seriously debated what is right, what is wrong, how one should act, and how one should not act. For a while, Sami kept arguing and then he started to wonder if there could be something valuable in the agile approach.

When leaving China, Sami got a couple of books from Bas. He read one on the flight from Shanghai to Helsinki. It was really good. The same problems Sami? tried to solve at work have been pondered by wise people around the world.

They didn't have the answers, but they had better questions. Better questions are what are asked in agile. Sami experienced a kind of awakening that many things he has been doing have actually worsened things in the organisation.

Sami transitioned within Nokia to be an agile coach. In the beginning of his career, when he spoke about agile, built teams, or supported changes, everything was about Scrum. Just get the ceremonies right (backlog, planning, review, retro, and daily) and there you have it.

A few years later, Kanban arrived. Everything is resolved when you limit the amount of work in progress and visualise it. Gradually, the toolkit grew. Different agile or supporting models and tools help to discuss problems and needs more maturely, and the best tool can be chosen in relation to the? demands of the situation.

Now Sami has had a long career at Reaktor. Sami is one of Finland's best-known Scrum trainers, and through him, thousands of experts have? been certified to the art.

How does agile look today

Looking at the phenomenon today it's easier to say what is not agile, and even this surely has many views. Agile fundamentally means the ability to react and a continuous readiness to act fast and in a smart way in various situations.

Agile and Scrum could be compared to a car's steering wheel. A car has a steering wheel so that the direction can be changed when necessary. The wheel itself is not meaningful, and it is only turned when needed, not to veer from side to side.

The ability to act and change direction in different situations requires many capabilities on an organizational level. Related to planning, implementation, and even thinking. If one cannot analyse and develop their own thinking, they themselves prevent the needed change. The role of agile coaches is to identify the prerequisites for change and to enable it.

In addition to capability to change, continuous learning is a key element. We should be able to look at our environment with open and curious eyes. Things are not good or bad, they just happen. We must be able to learn from things. At the heart of agile is that when something new happens we should stop. Stop to examine what happens, why it happens, what the impact is, and what can be done about it. This is what agile crystallises into, and from these, Scrum, Kanban, systems thinking, and other models are born.?

Agile has become such a common term that it has semantically slipped off track. Legal departments are being made agile, which doesn’t make sense, or removing people's offices is called agile. Right now? AI is seeing the same phenomenon, even a razor or a coffee machine has AI. At some point the word agile was added to everything. Every company, team, and department claims to be agile and projects are done in an agile way. It has become a hygiene factor. All employers are modern and agile, just so that recruitment works.

Organisations tend to call things agile that are quite far from origins of the philosophy?

Sometimes things that are done under the guise of agile are almost the opposite compared to the roots of agile thinking. When agile projects start to show positively outward, and the first projects succeed, people start to imagine that agile can achieve things it actually can't.

Agile is about capability to change and continuous learning, nothing else. What often happens is that traditional production economy metrics are attached to agile; more, faster, better quality. Business representatives start to think that agilke can turn the business around. Just adding more agile to everything, including the legal department and why not a bit of HR, the cash register sings.

While the initial agile teams are successful businesses or outlying organisations ability to learn and react to changes has not changed. Then teams are in trouble, wondering why they are overwhelmed with bureaucracy and context that is contrary to agile. There is also inherent conflict between traditional and agile development. A world based on planning and predictable implementation of plans is not compatible with constant and rapid response to changes in the environment.

Digital development and IT are often managed with the same industrial thinking as factories. Process thinking is carried over by strong traditions and culture to a place where it does not yield benefits. Lean thinking comes from the industry and is often confused with agile. Lean is a great way to structure things, and the ancestry of agile has a lot of Lean genes. Lean aims to minimise variance, variation, and waste.

In digital development, however, each problem encountered is unique, unprecedented, and faced for the first time. In a factory, ten million identical parts are made and the aim is to eliminate waste and polish and refine the process. If agile is imagined as a work method where the process is polished to be better and waste is minimised, it's on the wrong track.

The optimization target in Lean is different from agile. We start optimising calendars and time as waiting times should be eliminated. This stems from Lean. In agile, we actually want to have time to think, consider options, do experiments, and go backward. If Lean thinking prevails in the company, then agile may have a hard time taking root on its own terms in the culture.

In hierarchical organisations, there are often leaders who believe their value comes from telling other people what to do. In this situation, agile is reduced to a process to do more but not better. In a company with even a hint of industrial heritage, scaling starts to guide the adoption of agile practices and it goes wrong. It's believed that the more of the same is done, the smaller the unit cost becomes (economy of scale).

Agile serves digital development, but needs support from the surrounding? culture?

In the digital world, things are the opposite or different from the industrial world. Many companies have hard time understanding? that the logic is different. It's about optimising the flow and how well unique problems are solved. User feedback and business data reveal things that need to be reacted to quickly and in unique ways. The scale benefits of industrial thinking are irrelevant. Fundamentally it's about how each defines, experiences, and understands agile. People's own experiences influence this and it's hard for a clear-headed engineer to unlearn industrial heritage.

We have a strong need to formalise things because then they can be scaled. Agile teams, however, are unique based on culture, problems, selected tools, people's personalities and abilities. It would be good to ensure that people have a common view of what agile means, or at least a view of what is being solved with agile in that organisation.

When asked why you are using agile or training in agile methods, quite often the answer is a blank stare. People have been told that now you need to be agile. This kind of rollout of agile methods, where the tail wags the dog, gives Sami goosebumps in a bad way.

Suitable problems for agile might be lead time, how quickly things move from idea to production. Or poor communication and the bad decisions related to it. Or quality issues in product development. It would be good to identify the problem being solved and then develop a suitable remedy.

The fear of autonomy lives in organisations. We have worked for hundreds of years in a way that work is led. We are mentally conditioned to the idea that some people plan and others implement. Or some people lead and others execute. Breaking this thinking is difficult.

There are always? paradoxes when you try to find balance between autonomy and management. It can be a bit surprising, but autonomy requires control as well. Autonomy is only possible when we have constraints. In the agile world, there's a term called enabling constraints. They are boundaries, safety rails, and within them the real autonomy is born. Finding these boundaries that enable sensible autonomy and quick progression is the philosopher's stone for all organisations.

Autonomy does not mean having no boundaries, no conditions, no structure. Sami had a team under coaching once that went through many changes. People left, it grew, and responsibilities changed. The team decided that they already knew Scrum and now they would focus on the work and ditch the ceremonies. A couple of months later, the team started to struggle. They had removed these enabling constraints from themselves. They no longer had a proper backlog, they didn't gather together for sprint planning to plan a common goal for the sprint, and so on. Full autonomy led to collapse with the team's output and quality..

Enabling constraints are a support structure, a bit like a spine, it allows the team to move forward together. They also bring continuous review and analysis into the work, which is at the core of agile learning. We must constantly think about what works for us, what doesn't work for us, what we should do. Giving up is not a good strategy when planning one's work, but structure is needed. This is one paradox that challenges the common perception of agile. Agile needs structure and discipline.

Things that are agile in name only

Jira is often mentioned as a tool for supporting agile. "Now we're agile because we have Jira." Jira itself mentions agile in its advertising slogans, but it's as much agile as the Democratic People's Republic of Korea is democratic. If something needs to be emphasised in the name, alarm bells should ring.

Tools are not inherently bad, but since Jira is widely used, the issue comes up. Tools almost always have features contrary to agile practices, and through them, it's easy to slip into acting against agile ideology. Tasks or tickets, for example, are assigned to a specific person, and this breaks against the principle of distributed responsibility of autonomous teams. In Jira, tasks can also be left unfinished and with one button moved to the next sprint. At the core of agile is finishing things. Jira has made the wrong things easy.

Atlassian's tools, including Jira, bring a lot of hierarchy. There are epics, features, tasks, subtasks, and whatnot. The backlog and the work should be built into a complex hierarchy, although it should actually be clear and unambiguous. I often see the focus of work turning to whether Jira tickets have been done and progressed correctly. Meetings, encounters, and discussions revolve around whether Jira has been used correctly. We don't talk about whether we're doing the right thing but as if we're serving the tool. I've successfully phased out Jira in some projects and replaced it with a clear electronic whiteboard.

An electronic tool is often necessary due to remote work, and it still enables simple visualisation. Jira's strong point is automation, but traditional and clear visualisation multiplies the team's internal discussion. So, if you think you're agile because Jira is in use, you're on the wrong track. Tools and processes are good when they support solving the problem or achieving the goal. Sometimes the focus shifts to the tool or process itself, and their management may come from outside the team. It may be that the team's task management is in Jira, to which the team does not have administrator rights. It's the opposite of what agile should be. Work methods and learning cannot then be continuously optimised for the goal, and time goes to entirely unnecessary discussions. If we talk about minimising unnecessary work, then discussions about tools and their features could always be left out.

?Agile methods and certificates

Many build their careers on certificates and methods, and then they naturally seem important. It's easy to forget that methods are not significant in themselves but the aim is to solve problems more effectively and better. Sami’s career and livelihood is based on Scrum certification. Yet Sami tells at the beginning of Scrum training that the attendees are not actually supposed to do Scrum, and the audience is puzzled and a bit scared. The purpose is to make a product or service. Scrum doesn't add any extra points, it's not put into any product's advertising campaign, and it doesn't add a single percent to sales.

Scrum is a tool. If it doesn't work, try something else. Clinging to a certain process, method, or tool is really dangerous. The autonomy of the team is more important, they have the best understanding of the problem and they need to start thinking for themselves and ask questions like how would I solve this? What tools would help us?

Methods or tools could be thought of as a starting point or support structure. If a bunch of people who haven't worked much together before were thrown together to build something completely new without any clear way to start, nothing would come of it.

We need a way of working that helps us get moving. What happens after that is another matter. We need to critically examine how we work. In what way, by what process, by what framework. Remembering that if something doesn't work, then stopping it might not necessarily be the solution. If we think about, for example, Scrum. Scrum has a lot of things that are also safety nets. If it feels like there's no time for retros or dailies, then it's not necessarily the problem of the retro or daily. The actual problem is elsewhere.

It's like if someone on a construction site came to say, "Hey, that safety rail up on the roof prevents me from running. Can we remove the safety rail?". No sane person would remove it. Sometimes you have to be able to go slowly so that later you can go fast.

According to Sami, a good approach to different development frameworks after starting is that the direction should always be towards simpler rather than more complicated. Someone will always suggest, "Could we do this too or add that field to Jira or adopt this working method or write one more report." The answer should always be no.?

We should always be really critical of complexity. Could it be done more simply? Could it be automated? How would this be done so the team doesn't have to stop? So many things go so that the method or tool is like a rain dance. When it doesn't rain we put energy into fixing the rain dance. And you're no closer to the goal and the focus is in the wrong place.

That rain dance story comes from a system thinker named Russell Ackoff. Many management practices are like a rain dance. They hardly affect the climate, but a lot of time is spent on improving the dance. The focus should stay on the ball; the problem being solved. If lead time is the problem, then let's try to fix that lead time and not, for example, Jira. Lead time might be addressed with visualisations. But let's not do it too long because that would be polishing the rain dance. Let's remember to return to the original problem, and consider what the visualisation tells us.

Many harmful things are done in the name of agile

Many companies do something under the terminology of agile that ultimately isn't very agile. Companies are not stupid, of course; when things don't go as they should, they might call a coach for help. Companies rarely pay a consultant when everything is going smoothly.

If agile is reduced to a tool or process, then one can live under the illusion that they are agile because they follow the use of that tool or process. They may be very satisfied when Jira's usage rate is high and 90 percent of teams do retrospectives. Teams may be miserable and nothing comes out, but the metrics look nice. Usually, such situations start to be revealed when business is dissatisfied with the concrete results. This is a typical conflict within organisations. IT or R&D, which is responsible for doing the work, naturally wants to succeed and can also prove it with metrics, but the business is not satisfied.

These are demanding situations for the coach, when one part of the company says that nothing works and another part says everything is fine. It's worth finding out if business is getting the things they want in the desired timetable, the answer can guide in the right direction to identify bottlenecks.

Sometimes the answer is found in the mirror. It may be that the business itself has caused the situation. There may be problems within the teams. There could be comments that they can't take it anymore, the tools don't work, and so on. Many teams follow their well-being through retrospectives or surveys. When results are bad, the reason could be overload. The overload has resulted from the focus going elsewhere than to meaningful work. Time goes to processes and tools. It could be that processes and tools have covered up that the workload is unreasonable and the actual work is stuck.

One of the main tasks of agile is to bring transparency and understanding where we are right now. The worst foolishness done under the guise of agile is that tools show that everything is fine even though the machinery and people are broken.?

The fault and the problem are often in different places. If your head hurts, probably your shoulders are stiff. You can always take a painkiller, and then the headache goes away, but soon it's worse than before. This leads to transparency and even to systems thinking, first we should see the whole before we start fixing things.

Quality issues might manifest as stretching of the backlog, and the business starts demanding for their features. The P.O. might be overloaded and not able to do the actual work, and then the team starts doing completely wrong things.

Hero culture is also dangerous, i.e., individualised responsibilities. When one person drops out of the game, the whole stops working. Problems vary and often customers react by asking help with analysis and with having better metrics on how agile works. In such cases adding more metrics often has a strong assumption that we know where the problem is and want to measure it away.

I approach such situations gently. I might suggest, for example, Kanban's first principle, that we find out where you are right now. To improve things, it would be good to understand where we are. Looking in the mirror or into the attic is hard for many, there might be many skeletons there that they don't want to disturb.?

Many companies also want out support in defining an agile organisation with predefined? processes and roles, and of course, it would be lovely to sell the service, but the assignment itself is in conflict with agile. Everyone has a good intention and a lovely goal, but at the core of agile are autonomous, well-functioning teams that produce value and always focus on the most important thing. Agile cannot be done in such a way that it's defined as a process where roles and responsibilities are decided in advance.

In those situations, a coach must be aware of expectations and culture. Predefining things only erodes agile. It may warm for a moment, like peeing in your pants in the cold. It feels good when everything is defined and looks clear, but as we move forward and need to adapt, we stumble even worse.

With procurement, it's also interesting when you want those agile teams and agile solutions, all on a fixed budget. The procurement policy can be strict, and that's understandable. It's more about what’s the basis for the thinking. If the thinking is based on giving this much money and expecting to get exactly certain things out, then there are difficulties. If the procurement policy is strict in such a way that it gives money for you to always do the most important thing, then that's a completely different philosophy. It gives the customer more freedom in risk management and strict control is good, and monitoring ensures that we're always at the most important thing.

Agile thinking is a great tool in business sense and it mainly scares customers because the mechanism is not understood. It aims to ensure as real-time as possible that the investment is directed to produce maximum value. In traditional ROI thinking, the value produced is defined before starting. It rarely happens as planned as the world keeps changing quickly and human capacity to understand their environment is limited. In agile thinking, the aim is quickly to get to a situation where we can continuously collide outputs with users and get genuine data on business impacts.

Business Value is a broad and difficult to define term used in business, procurement, technology teams, and agile communities. Usually, when asked what exactly this "Business Value" means, silence comes back. The book named The Art of Business Value opens up the term's multifaceted nature. Defining value unambiguously is difficult. It’s better to break tasks down to small enough pieces and validate if something improves rather than cling to some big value assumption.

A traditional investment is safe, it can be calculated and followed. It's like a situation where a drunkard is searching for his keys under a streetlight and when asked, "Did you drop them here?", he says, "No, but this is just easier to search because there's light."

In investments, the focus is often on a number that's easy to follow, but one should expose the organisation to think about harder things like are we doing the right things and can we change when the market changes.

Doing agile right

Professionals should have a 100% allocation to what they are doing. All kinds of focus changes are poison to the individual and the team's work. People can only be divided in spreadsheets.

An ideal agile team is a multi-skilled group of people who can focus on what they are doing. There's also a social side in teams. You have to dare to take different people onboard and build teams where people work with each other's strengths and insecurities. Social glue is? needed so that a team that dares to commit and take risks together.

The team should get support and coaching from within. If we return to what is not agile, then an external agile coach who comes from another organisational unit to facilitate a little bit. That is the same as if a Seagull flies to a rock, poops, and flies away. Nothing changes, at least not for the better.

Inside the team, there should also be vision and competence in developing working methods. In Scrum, it's the Scrum Master, but it can of course be more informal, as long as it meets the needs of the team. Product Owner, who watches over the work acceptance process, is crucial. A truly empowered authoritative person who directs development in the right direction and knows business priorities. The P.O. must understand both the backlog and the world of customers and business. The P.O. distils from all the information of the universe exactly the right thing that the team should do.

Lastly, there should be time for learning; the ability and desire to examine one's own work. In Scrum, the term used is retrospective. Retros should be done seriously and especially for the team. The retro is not something to be reported to management, but it aims to utilise the team's autonomy in continuously developing better working methods.

For the agile way of working? to succeed it primarily needs courage. The courage to do things correctly, challenge constraints and rigidity coming from the surrounding world. Agile means that we are always better than yesterday. Sometimes it requires a damn lot of courage to resist processes and structures rolling over you.