An obvious place where Executives and Agile Beliefs diverge is when it comes to Agile Transformations. Executives tend to favour top down big bang implementations whereas Agile Practitioners prefer bottom up safe to fail experiments.
This is not really the executive’s fault as they are driven by the need for fast results. Executives generally have a tenure of five to ten years. This is a surprisingly short period of time to effect significant lasting change in any established, traditional organisation.
The difference between traditional methods and Agile is that traditional methods tell you how to write software. Agile methods do not. As Tony Grout says “Agile methods are the simplest practice that will tell you the problem you need to solve“. Whereas traditional methods force the team to mold around the practice, Agile molds practices around the team and the context that they operate in. In other words, one size DOES NOT fit all. It takes time for a team to develop a stable and effective method for their context. It is not simply a case of the teams learning a new method, its a case of the team using Agile practices to create their method.
The change is bigger than just the development teams
Its not just the teams. The program management structure that manages the risks of the cross team development needs to be developed using Agile techniques. Whether you adopt Flow, LESS, Nexus, SAFE or DAD, its not just a process. All of the people operating the system need to learn a new way of working, and even harder, a new way of behaving. People need to learn how to learn “work with” rather than “work for”.
At the portfolio level, the organisation needs to bring all the business heads together in order to agree on the organisation’s backlog. This allows engineering to start managing its skill liquidity using a tornado graph to support investment and divestment of capacity. The organisation can become a team of teams and focus on its customers and it external competition rather than focus all of its energy on internal rivalries.
And this brings an uncomfortable truth and realisation to the CEO and Chief People Officer. Getting a business executive to give up their goals in order to help a fellow executive achieve theirs for the greater good of the company means that the (executive) reward system needs to be upgraded. An upgrade to reward collaboration and reward focusing on the goals of the overall organisation rather than sub-optimal local goals. It will take the HR function a number of attempts before they find the right path to a new successful reward system.
The organisation will need to implement a risk management system that allows business leaders and IT leaders to collaborate on managing the risks associated with investments involving IT. Not just copying a blog post but training audit and assurance functions in how to tell the difference between a well run project and one that presents a serious risk to the organisation.
The simple matter of funding becomes a issue at some point, though later than most think. Although the finance department needs to build a new way of funding projects, a more urgent imperative is to find a better way assessing the value that investments in IT deliver.
As well as learning to collaborate as a team, the executives need to learn how to create safe to fail cultures that promote learning. Executives need to learn an entirely new set of skills and behaviours. They need to learn how to create a new culture and tools for changing culture such as story telling and walking to talk. They need to learn how to see culture, the culture they need and the culture they need to move away from.
But before anything can start they need to build trust and respect with their fellow executives. Not something that happens over night.
And they need to do this fast, during their short tenure of five to ten years. No wonder they prefer big up front design, top-down transformations run by consultants who can be blamed for failure.
Starting an Agile Transformation Fast the obvious way
Doing it fast is easy. You select a method…. LESS, NEXUS, SAFE or DAD and simply roll it out. You hand out copies of the relevant book. You hire clever consultants and coaches, and you hire trainers to roll out standard training.
That “works” if you assume that an Agile transformation is “obvious” in Cynefin terms.
You will start fast and fail even faster, though perhaps only after you have spent a lot of money on consultants and coaches and training.
The upside for this strategy is that your bosses will perceive that you are a “get it done” individual who is making a difference. You will have a big up front design for your transformation. A big plan from a big name consultancy to get to success.
In the words of Helmuth von Moltke the Elder…
“No plan of operations extends with certainty beyond the first encounter with the enemy’s main strength” (or “no plan survives contact with the enemy”) and “Strategy is a system of expedients”.
Starting an Agile Transformation Fast the complicated way
Instead you may consider that an Agile transformation is “complicated” in Cynefin terms and seek “experts” or get a big name consultancy to undertake an extensive analysis.
- If you are unlucky, you will encounter consultants who will show you powerpoint slides with lots and lots of detail of successful transformations at similar organisations, a brightly painted roadmap, and a standard process that involves time boxed analysis or capability assessments. They will have an army of graduates and cheap developers micro-managed by “get it done” leaders to help you transform.
- If you are lucky, you will hire one of the small handful of people in the world who have real experience of creating genuine Agile transformational change… And they will tell you that an Agile transformation sits on the boundary of “complex” and “chaos” in Cynefin terms, with large elements of “obvious” and “complicated”. P.S. If you are wondering which stone to look under to find these people, you could do worse than start here.
You will learn the goal or destination in an Agile transformation is “complicated” which only an expert or analysis can tell you. Big name consultancies are good at providing a business case and delivery plan to help you secure funding and “commitment”. They will provide a nice “complicated” powerpoint diagram showing all of the elements of the new organisation. It will be a beautiful diagram with an even more beautiful story told by beautiful expert story tellers in beautiful suits with beautiful hair. It wont work of course, but it will be beautiful.
The good news about assuming the transformation is “complicated” is that if it doesn’t work, you can always blame the experts and their beautiful diagrams. This is a particularly popular strategy in risk averse cultures.
Finishing an Agile Transformation Fast the Complex / Chaos Way
Although the goal is “complicated” the transition from where you are now to where you want to be sits firmly on the border between “Complex” and “Complicated”. Although everyone might agree that the destination is Paris, the path you take will be different dependent on whether you are in Versaille, or London, or Tokyo, or Cape Town, or Athens, or Olympia, or more likely Olympus Mons.
Experienced agile practitioners will tell you that tales of success are inspiring but you need to dig beneath the polish and look at the failures. Success is more likely if you avoid the failures rather than try to emulate the success.
You will need to set up a portfolio of “safe to fail” experiments. Experiments that tell you the best place to apply LESS, the best places to try SAFE and DAD and Nexus. The best places to organise using the Spotify Model and the best to organise using the Buurtzorg Model. In order to make the experiments “safe to fail” you will need to speak to people with real experience of applying these approaches so that you can learn about the known failures. You won’t find out about failures from a sales brochure or a shiny powerpoint. You find out about them from people who trust you.
Executives attempting an Agile Transformation need to build a lot of trust and that takes time. It takes time to build trust with the Business Heads, and the CFO, and the CRO, and the CPeopleO, and the COO… Especially as the CIO is often not considered important enough to be on the board of non technology companies, often reporting to the CFO or COO.
When instigating a Lean Transformation Students of Taiichi Onho would insist on the board, lead by the CEO making a significant change to the production line. Taiichi Onho’s students would lead them from the boardroom and make them publicly dismantle a key part of the production line. If they were not prepared to do that, Taiichi Ohno taught them to walk away as they were not ready. If an organisation is embarking on an Agile/Lean Transformation, the first act of the board should be to appoint the CIO to the board (if they are not already on it). The second act should be for the board to go to the place where the transformation will start and dismantle the desks and dark cubicles with screw drivers and allen keys and , and replace them with collaborative spaces. The board should collaborate with the teams to create the Kanban boards that they want to see when they “Go the Gemba” to sit with the teams so that they can remove impediments and blockers for the teams. If the board are not prepared to do these things, they should abandon the transformation before they start.
The board need to understand that the transformation is not the destination. They need to understand that the transformation is the journey. They need to nourish and protect their experiments, removing impediments and blockers for them. At Agile2007 in Washington D.C. one of the participants stated that “Agile is a commitment to personal growth and learning as well as a company’s commitment to growth and learning.” The board need to make their trailblazers feel safe on their learning journey and shape a culture that supports growth and learning. The board need to be involved and make sure that improvements are happening. The board needs to ensure that value is delivered along the journey and not just at the end. A constant movement towards a better organisation.
A tale of two approaches
The Agile approach to transformations is to start small and gradually grow the size of your “safe to fail” experiments as you succeed. Start small and build your knowledge. Grow your people and get them to engage with the Agile community outside of your company. As you build your knowledge, build your infrastructure and risk management systems to support the new way of working. The key to success is growing the knowledge and experience of your existing people so that its your own people who do the scaling and not external consultants.
The executive approach is to hire a big name consultancy, create a top-down big up front design of the organisation and implement it in a big bang approach. Of course the bang normally comes just after the consultants have taken their fee. It is normally driven out of IT as an IT initiative without the need for proper engagement with the business. The IT executives do not need to learn anything new as they are doing it to their organisation rather than with the organisation. The good news about this approach is that the experts or consultants can be blamed when it fails.
Perhaps if CEOs were given the proper amount of time to roll out a transformation and given the proper support of their colleagues on the board (assuming they are on the board), they might try a more sensible approach.