I made that choice in the past, several times. I admit it. I took the blue pill! The pill of convenience... It went by different names: Scrum, Kanban, Lean Startup, SAFe... I wanted answers. Not to question myself. It seemed so simple...
Blue pill: it involved picking an agile framework (preferably the most popular) and implementing it, straightforwardly. In hindsight, it allowed me to maintain my certainties...
Red pill: the truth is, I didn't even see that pill; I didn't really realize I had a choice. Yet it was right in front of my eyes, but it seemed too difficult to swallow with its values and principles. It contained more questions than answers...
However, one day, I decided to try it, truly, completely, sincerely... And here's the world I believe I'm starting to discover:
Becoming Agile is not about implementing the right framework or practice but learning as a collective, continually questioning oneself.
Allow me to share this experience with you. Perhaps, you too will realize that you chose the blue pill and that there is another, more interesting choice.
The current confusion (blue pill)
What is commonly referred to today as an "agile transformation" usually involves adopting and applying a new organizational model. In reality, the true way for an organization to become agile is to create a collective dynamic among employees who will have to live and actively participate in the change. They can then consciously choose an agility model, which will probably be an important step in the transformation, not its origin. It will be just a step because remember that agility is not an end in itself [1].
"Alone we go faster, together we go further." - African proverb
Daniel Mezick defends this idea of non-i
posed agility well, explaining that agility only works if it is the result of a freely and willingly adopted approach by those involved. Indeed, the essence of agility is to rely on the autonomy and self-organization of individuals, who will not invest if they don't want to. It seems quite obvious, but it's worth reminding...
"You can lead a horse to water, but you can't make it drink." - English proverb
If frameworks like SAFe or even Scrum are beautiful toolkits, we tend to want to put them in the hands of people who haven't asked for them. Certainly, SAFe, for example, takes the trouble to explain that the transformation "leaders" must create awareness within the rest of the organization, but almost nothing is said about how to achieve that!
The other problem with imposing such an approach is that the "leaders" immediately place themselves in a superior position, assuming that they understand better than others that: 1. "we need to change" and 2. "we must, therefore, apply this operational framework." In reality, these two statements can be challenged because the need for change may be debatable, and the solution even more so. Thus, faced with this temptation to "push" the collective, all we will get is resistance...
Hence the interest in a collective dynamic in which "leaders" would focus not on their convictions but simply on mobilizing people around questioning, then calling on collective intelligence to co-construct thinking and an approach rather than imposing them. But if the "leaders" are right, the need to change and the new target will take longer and be more difficult to emerge, but the collective will already be engaged in this process, which will then have much, much, much more chances of success.
The challenge then becomes:
- Explicitly state the right question to ask
- Invite the collective to rally around this question,
- Find a suitable collaboration format.
A disruptive approach (red pill)
The Open Space Agility (OSA), approach, created by Daniel Mezick, is to my knowledge the only one entirely focused on how to get a group of people to change their way of working.
It must be realized that ALL other so-called "agile" approaches give you the target to achieve for organizing work in advance. Apparently, to work well, you would need "Release Trains" (SAFe), "Feature Teams" (LeSS), "Sprints" (Scrum), a "pull flow" (Kanban), "TDD" (XP), "MVP" (Lean Startup).
OSA does NOT tell you how to work well (and be Agile) but gives you an approach to find your own way to get there. That's the red pill! It is then not excluded that teams implement all or part of existing frameworks, the goal not being to reinvent the wheel. But if they do, it is because they will have tested and validated the effectiveness of a particular practice, not because they are applying a directive or trying to please the hierarchy...
The main ingredients and elements of success for OSA are 4:
1. Large participatory workshops
Contexts that need agility are inherently complex. To solve complex problems, the best strategy is to encourage interactions between individuals and let solutions emerge. The open space is the excellent workshop format that allows a large number of people to work together on the same issue while giving them the greatest freedom to define topics and how to address them.
2. The power of invitation
Choose your side! According to Mac Gregor, you are either Theory X or Theory Y. If you are Theory X, agility is not for you anyway, move on. If you are Theory Y, then you easily understand that forcing people cannot yield good results in the long term and will instead destroy their commitment to work.
As paradoxical as it may seem, the freedom you provide by sincerely inviting people and giving them the choice to participate or not will generate a high level of engagement from those who decide to take part in the experience. Daniel Mezick draws a parallel with games, explaining that forcing someone to participate in an open space would be as ridiculous and counterproductive as forcing someone to play with you...
Make sure to start an OSA process with leaders who understand the importance of the invitation and do not hesitate to test several versions before dissemination. Obviously, also plan to respect people who would decline your invitation.
3. An Agile approach in itself (iteration, experimentation, adaptation...)
How long will it take for your collective to transform? What are the main obstacles it will encounter? What will be its main motivation levers?
None of these questions has an obvious answer. What is certain is that the path will probably be long and full of obstacles. That's why OSA helps you create conditions to allow the collective to try, grope, experiment, while fostering interactions and staying focused on results... Open spaces then follow every 2 or 3 months, and a big communication effort is made to reassure about the right to make mistakes while valuing successes.
4. Keep it simple
Contrary to what the "big picture" of Open Space Agility (which aims to be the opposite of the famous SAFe big picture) might suggest, OSA is actually very simple! Schematically, it is about setting up a very light framework and, above all, letting go!
One of the first OSA diagrams (the 6-month periods have been reduced since to 100 days)
This simplicity will have many virtuous effects:
- Allow the greatest number to understand and appropriate the interest of the approach since we won't drown people in tons of jargon and complicated processes.
- Give a sense of trust and freedom, as there are no imposed subjects or participation.
- Provide a sense of mastery, as participants themselves will decide what they will experiment with and how they will do it.
Relevance, autonomy, mastery... Bingo! We find the three criteria of intrinsic motivation identified by Daniel Pink. This simplicity will generate motivation and promote everyone's involvement!
Favor people and their interactions (red pill) rather than processes and tools (blue pill)!
Beyond the nod to the Agile manifesto, this phrase sums up that supporting people is more important than pushing practices... It's been stated since 2001!
So, it's up to you to explore these points of reflection, to which you will need to respond with a certain distance:
- In your opinion, after reading this article, which pill have you already taken?
- What motivated you in this choice?
- What would prompt you to act differently today and why?
- What would your agility look like if frameworks didn't exist?
- How surprised would you be by the answers to these same questions if they were addressed collectively by your team? And by your company?
Note down the answers to these questions somewhere, embark on the journey, and revisit them in a few months. You might be surprised!
Moreover, it is a much more interesting starting point to bring to light why an organization would need to be agile and what that would mean in concrete terms.
