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 7 major principles which mark and design an Agile organization:
- An inspiring vision as an end goal of what the organization wants to achieve. For example, a rocket ship flying landing on Mars is the overarching vision for SpaceX.
- Self-organized, cross-functional and competent teams – most organizations create cross-functional teams (and if it is only for the full technology stack), some achieve self-organization thanks to strong agile leaders or Scrum masters. Rarely, organizations understand the concept of competence as a team (rather than individual competence).
- Iterative and increment product or service delivery. Iterative describes frequent deliveries (in Scrum, e.g., we use Sprints); incremental means to add more value with each iteration. An iterative approach only makes business sense if we add value each iteration. Otherwise, the iterative approach is a self-service.
- A continuous improvement cycle, so the team knows what to change. Agile can only fail, if we think we are good already and we stop improving. Therefore, continuous improvement needs to be in the DNA of the team. Important to note that improvement does not mean to just hunt failures or issues, but to actually improve (for example, to keep learning also from successes).
- Customer Value-driven Requirements which are introduced just-in-time rather than just-in-case. One of the issues with companies is living in their bubble and not providing a service or product which actually fulfills a desire or a need from customers. Therefore, the priorities of any requirements need to be organized according to customer value.
- Transparency throughout the collaboration, so all the above can be achieved. SAFe is excellent in making dependencies between teams transparent and addresses them. But this is not the only way to make things transparent: Document and communicating the reasons why features are requested and how they will affect the business are already a good start towards transparency. Start small.
- The Role of Management needs to change. Traditionally, Managers are responsible for giving directions and managing individuals. But if the above 6 principles are followed, and we want to really develop self-organization, Managers have to create a trustful environment. Instead of managing the individuals, Managers need to manage the environment instead, so teams can be self-organized.
If we understand these 7 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.
How not to get started with Agile?
Most organizations plan their Agile transformation or journey like they would plan any project in their organization: They define the future state, what 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?
Don’t plan agile; Be 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 7 principles of the Agile organizations as described above, and then work your way towards higher agility:
- Why do you want to be Agile?
- What effects do you hope for, when becoming Agile?
- What are your fears when becoming Agile?
- What are the biggest constraints in yourself and in your team’s to achieve any of those 7 principles?
- Which of these 7 principles are already visible in the organization?
- Which are the furthest away?
- What is the only 1 thing you could do in the next week to get closer to the 7 principles described above?
- Who can help you, when that becomes difficult?
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.
