Transitioning to agile ways of working is not easy. The transition may take a long time and the results may not be visible straight away because changing people’s mindset and culture doesn’t happen overnight. It is important to realise the benefits of Agile transformation and the reasons for it.
Many teams start adopting agile ways of working by implementing and facilitating Agile ceremonies e.g. daily standup, sprint planning, demo meetings (or Show and Tell), and retrospectives, or they select an agile method, usually Scrum or Kanban. An extreme example is also when organisations restructure their teams and replace Project Managers with Scrum Masters and Product Owners. This is, however, a very disruptive process which will not necessarily make your teams more agile.
Before you decide to begin your Agile journey you need to understand ‘Why’ you want to do it and what your long term vision is, then ensure you understand the core Agile values and principles.
I’ve worked with teams who were trying to implement agile ways of working before but actually, they didn’t seem to understand why they were doing it and what the value was. I think that’s usually caused by a lack of shared understanding of what Agile Transformation is or vision of what we’re trying to achieve as a long-term goal and how the business could benefit from it.
Here’s my step by step guide on how to start Agile Transformation.
The first step is key and it is to start with “Why” – Why are we doing this? A great place to start is listening to this video of Simon Sinek ‘Start with Why”. An Agile adoption should not be an ultimate goal but a way we can achieve our goals and business objectives. It’s the means to satisfy user needs and respond to the rapidly changing environment.
The next step is changing our behaviour by implementing agile techniques which closely link to Agile values and principles. At this point, it doesn’t really matter what agile methodology you use as you need to understand the core Agile values and principles to benefit from Agile adoption to the highest extent. At this stage, you may also need to get everyone’s buy-in and support in transitioning to agile ways of working. The more supporters you have, the easier the journey will be.
Perhaps, some of the team members you work with must have heard of ‘Agile’ but they don’t necessarily have a clear understanding on what it is and what all that Agile jargon means, therefore you need to break down the language you use and split it into component elements and talk about the benefits and values an Agile adoption can give to your organisation rather than use ‘Agile buzzwords’. For more on this, read my article about Agile: Beyond the buzzwords.
After gaining a shared understanding and breaking down the agile language you should have an easier start to implementing agile techniques and ceremonies to improve cross-team collaboration, communication, continuous improvement, and feedback culture – but again these capabilities need to closely link to the core Agile values and principles.
You’ll very quickly be able to notice a difference in the team’s behaviour and the habits they’ve built. In order to become more agile, the change needs to happen at every layer (see the Agile onion below) defined as tools and processes, practices, principles, values and as a result mindset.
Credit: The Agile onion (Adventures with Agile)
The Agile onion is a great way to visualise the change that needs to happen across all layers starting from behaviour to a new way of thinking and understanding.
Effective change requires changing every individual’s way of thinking even in seemingly small areas, for example, when you’re stuck with your work and need to ask for help. Surprisingly, many developers and engineers don’t ask for help even if they’re stuck for a prolonged period of time. They prefer to solve their problems on their own or ‘google’ a solution rather than ask a colleague sitting next to them. If that’s the case, they need to get rid of their fear of asking for help or asking ‘silly’ questions. Asking for help doesn’t mean they’re not skilled enough or haven’t spent enough time trying to solve a problem or issue on their own. On the contrary, they need to start collaborating with their team and other teams across an organisation to avoid organisational silos.
Another example is when the teams don’t actually know what the word ‘blocker’ means or are just afraid of raising any concerns or doubts. A ‘blocker’ doesn’t need to be a big problem. It can be a small delay in anything you do or waiting time which is considered as waste.
Finally, be framework agnostic. Many teams implement agile methods and adhere to them at all times. Instead of sticking to one particular framework or methodology, see what works for your team and the product or service you’re building. Select these techniques and practices that you think will be the most beneficial for your team and a wider organisation. If you don’t know which method will be more suitable, try to do short-term experiments and ask your team for feedback to find out what works for them. In addition, measure it to see if it brings value by using a lean approach: ‘build – measure – learn’.
Sometimes, Agile transformation is executed in a Waterfall way and many organisations, as well as senior managers, try to roll it out across all teams in the same way.
Ultimately, use common sense and select this set of practices that make sense to your teams and organisation even if they use different methodologies and approaches. There’s nothing more harmful than executing Agile Transformation in a Waterfall way by telling teams how they should work, or rolling out ‘Agile’ to all teams in the same way, using the same methods, agile metrics and managing the change top-down.< Back