Working agile vs an agile mindset

To think agile

Working agile often means using a framework such as Scrum or SAFe. Common to most agile frameworks is that different events take place on cadence. Normally, these different events are booked in and the participants start tentatively, but improve over time. Of course, a lot of different educations often take place when a transformation begins.
Once the structure has settled, you can say that you work agile. But the promised results may not come and frustration will arise. What is often the problem then is that many in the organization still think traditionally but try to work agile. In short, that combination does not work. Thinking agile requires a lot of change. Below are a number of examples I have experienced.

The Agile Manifesto (www.agilemanifesto.org) gives us 4 values ​​and 12 principles. Already on the first value which is "Individuals and interactions over processes and tools" a lot of undesirable behaviors arise.
One such behavior is the widespread e-mail culture that exists. It includes, among other things, e-mailing people who sit in the same office landscape or even next to each other instead of talking to each other. This behavior is sometimes defended by the fact that it is "good to have it documented". That may be so, but it is not an agile mindset. Therefore, make sure to talk to your employees instead of writing to them. Almost everyone also has a telephone if the employee is not sitting in the landscape when you want to talk.

Another behavior that is not uncommon is that you communicate via tools. This can mean writing comments in tools such as JIRA or Confluence instead of talking.

Who is responsible?

Another question is about "Who is responsible?". Traditionally, there is often a project manager, program manager or perhaps a line manager who is explicitly responsible for an area or delivery. In agile, the responsibility is instead divided in different ways where the Product Owner can be said to be responsible for what is to be developed, while one or perhaps more teams are responsible for how it is to be developed. In addition, the Scrum Master has a responsibility to develop the team. This shared responsibility is sometimes attacked with the thesis that "shared responsibility is not responsibility".

The key to making the shared responsibility work is to let go of control. Managers instead need to become leaders and create conditions for teams to develop and be able to take responsibility. A start in this is to stop asking "who is responsible".

A third area that I want to address is about creating a fast flow (Lean Flow) and removing bottlenecks. Being able to "juggle many things" is considered or at least considered a good trait. But the fact is that in order to create a fast flow for work packages, you basically focus on one or a few things at a time.

Say no to stakeholders

In agile as well as in Lean, this is called "Limit Work in Progress" or just "Limit WIP". My experience is that many people understand the concept but find it extremely difficult to live up to it. One consequence is that you have to say no to different stakeholders. Saying no to stakeholders and those who understand the concept of limit WIP is a culture that is difficult to create. A good Product Owner has as one of his most important qualities to justify a no to stakeholders, but to think that way is still unusual.

This area is also covered by a "batch size" principle. That is, the work packages must be small. This, together with the principle of limit WIP, means that the flow (throughput) of work packages becomes large, which has a number of advantages. There are a couple of concepts within the agile way of working called MVP - Minimum Viable Product and MMF - Minimum Markateble Feature that aim to reduce the size of the work package. These concepts are something that is difficult for many to implement. Instead, it will be very large work packages that take a very long time to develop. When you also want to do many of these, it takes far too long before the end user is reached.

An agile transformation is about both working and thinking agile. Thinking agile is clearly more difficult.