| There's a worrying pattern that many of our clients have been sharing with us: A feeling of rush in adopting Agile methodologies such as Scrum, DevOps, XP, Crystal, LeSS, SAFe. All of them imply changing operating structure. This feeling of being considered laggards is not to blame, as there are many big players setting the scene for them to go fast in this direction, selling Agile as the best approach to cut costs and deliver faster. Who wouldn't want that? It's a common belief that it's a good idea to copy structures from famous successful transformations like Spotify and their tribes/squads, Zappos and its holacracy/circles... name your model here. Complex organisations approach transformations in a habitual way, one that worked for many years in the past: Identify the best practices, assess which one fits the best (based on expert's opinion), command departments to adopt it, set a challenging timeframe, control whether all elements are "check boxed". Unfortunately, this approach, which was born from a different type of thinking, inspired by self-organisation, striving for resilience and powered by purposefulness, is not working anymore. By just changing structure, we are not helping people to work more effectively. We are not enabling people on how to self-organise on a daily basis. In fact, the more we prescribe how people should work, the more we reduce their accountability for coming up with solutions on their own. Our clients tell us that adopting new approaches such as Agile makes you fail in the very beginning of their experimentation and this is frequently not acceptable to senior client management, leading to alarm and blame, closely followed by a retrenchment and a return to a more traditional controlled approach. In fact, for real learning to occur, learning that is crucial to developing an agile mindset, we must leave room for failure. Unfortunately most companies are uncomfortable with this notion. Failure is seen as weakness or incompetence. But therein lies the rub. If you are not failing regularly in small and not so small ways, you are merely pretending that you are doing well, pretending you are learning, when in actual fact there is little or no learning occurring at all. | People, both as implementors and in changing their own behaviours, are key to change, but the environment, the business goals and infrastructure are also major contributors/impediments to a positive outcome. If you take a compliance-based approach, switching operating models without training and support, you will still carry your behaviours to the new model, leading to just a re-label of the new methods while still behaving and executing in the old way. You may not see any benefits beyond compliance, even worse, it will cause disruption on the existing way of work without leading to any benefits. The pioneers of successful transformations mimicked how nature scales as a self organising, multi functional, evolving mechanism. You must give the process enough time to change important things, connections between people, the flow of work. The change must have a real purpose, a meaning that people can understand and buy into. Rather than saying "we need to be agile because everyone else is doing", "we need to respond with working solutions, faster than our competitors", we need a vision for the world after the transformation and a clear understanding of the business value. We need to tell a good story. Our experience shows that you can't teach self-organisation, it has to be experienced, learnt by doing, by failing, learning from the failure, adapting and doing it again. Together is better. You can't do it alone. We can facilitate for you, guide you away from common pitfalls, identify dangerous habits from the previous model and teach alternatives to them. |
RSS Feed