Based on our consultations and readings, most Agile transformation have one major flaw: Agile is seen as a transactional state to achieve. You either are Agile or not. This makes the results of your Agile transformation measurable (and achievable), but can have dangerous effects. If we visit, for example, the SAFe website, we see immediately something, which could resemble a silver bullet: You “just implement” all those elements and change the roles and your whole organization is Agile. The underlying reasons, why any of those elements rightfully exist, is usually not really understood. Without understanding the reasons being the SAFe, Scrum, Less, and such frameworks, the teams get frustrated and tension develops. Agile from a bird’s-eye view looks successful, individual teams are struggling.
If we are looking at the Agile Manifesto and translate that manifesto into organizational thinking, we come to the realization that there are 6 major principles which mark and design an Agile organization:
If we understand these 6 principles and why they exist, then it is much easier to understand why we need to introduce Scrum for our Agile delivery. Interestingly enough, most organizations measure their Agility not towards principles, but towards actions and events. Their maturity in Agile is measured, for example, whether you have a retrospective or not, and not what the outcome of the retrospective is. In general, when working with organizations, we learned that they rather measure what is easy to measure and not what makes sense.
Most organizations plan their Agile transformation or journey like they would plan any project in their organization: They define the future state, how Agile should look like. They define a risk management plan and introduce milestones. In the end, they want to be ready to have better feedback cycles, more independent teams and higher engagement.
But isn’t it ironic? Nothing in their transformation plan actually invites for anything, what they want their final state to be. If their goal is to have shorter cycles of customer feedback, why does their project plan to achieve that, not include any feedback cycles? If their final state is to have more empowered team members, why are the team members not included in the whole process? If they want more independent teams, why do we dictate to them how they have to do Agile?
Piloting Agile and then looking at how Agile gets carried through the organizations seems to be the go-to solutions for Consultants in Agile organizations: Pilot Agile with one team and then see how they inspire others. And yes, we have seen that working, but we also have seen that failing. On the other hand, we also have seen Big Bang Agile transformations working: From one day one, everybody needs to work Agile (this however rather on small teams).
One problem with Agile transformations and plans for Agile journeys is that organizations are a construct of human interactions. This makes organizations complex – the bigger the organization, the more complex. If one thing works in “team a”, it does not automatically mean, it will work in “team b”.
Instead of planning for Agile, Be Agile yourself. You are an executive at a company, and you want to introduce Agile? Get the 10 most influential people on each level of your organization together and meet once a week. Don’t plan, but ask yourselves a series of questions around the 6 principles of the Agile organizations as described above, and then work your way towards higher agility:
Obviously, answering those questions does not really give us a detailed plan. It also does not provide for a sense of security. For some of us, it is scary, and it might create discomfort when we honestly respond to these questions. Also, our sense of having a certain answer to each of the question will challenge our discipline. The questions only make sense if we have this feedback cycle to answer those questions regularly: Every week or maybe every 2 weeks. Regularly, anyways.
It is such with every complex adaptive system: Every time we answer those questions, we have new information, new clarity and different point of views. Participants will get the answers to those questions into their PI Planning (Planning for Product Increment), their Sprint Planning, their Scrum of Scrums, etc. And every time, there will be feedback coming back, which will change the course of the answer over time. The clearer you become on how Agile is impacting your every days’ decisions, the more you will realize what Agile really is. Personally, I remember the epiphany of Agility as a cathartic experience. Agile is not a transformation, Agile is an ongoing journey. Therefore, don’t focus on frameworks or tools to achieve those, focus on the principles and see, how you can get closer to those principles, with every day a little closer.