Indeed, over the last few years, what started as a movement towards agility purely in IT, has become a highly prized organisational capability. It allows for a high pace of value delivery and helps create the environment for innovation.
That does not make it easy. There is no silver bullet. IT has learned many lessons since the emergence of ‘techniques’ such as Extreme Programming (XP) and Scrum.
However, to someone new, or even experienced, there are a bewildering array of acronyms and favoured options available. But what is going to work best for you?
For this conversation, we will focus on a single project and pick up some of the factors that make a real difference to the success of agility. It is a wide ranging subject and we will give a high level pass through these factors, recognising that there is a lot to unpack in each.
To start with, let’s refer to the team more than the project. As an IT person, it is interesting to reflect that much of what we will talk about is people!
Why and what is success?
In any project that is moving towards using agility, make sure everyone understands why. This means the big picture and why it is important to the organisation, not just what the project is setting out to do.
You need to be clear on the problem you are setting out to solve and be selective on how you measure the success. Poor choice of measures will act against the behaviours and results you are looking for.
There are many benefits to be gained by this approach. One to ponder: you get better decision making and ability to adapt if you understand the why (not just what and how). This is not new news to many and definitely worth calling out.
Context dictates what works
These all combine to create your unique context. For agility to be successful, this means assessing how to achieve success by tailoring what will work for you.
Also, go in with a mindset that you will not have all the answers. This means experimenting and learning as you go (which is a great way to start to build strategic capability).
Treat this as culture change
This is not just a case of trying out a few new processes or implementing the favourite tool to manage a backlog. Treat this as a formal change management activity. Be deliberate in the adoption of new ways of working for the team, and the organisation around it. If you have an experienced change management / adoption function, they can play a vital role here.
Remember to support the team throughout the journey to high performance. For any team, this will not happen overnight. This is especially true of a move to agility.
Leadership – define what you want
Projects do not exist in a vacuum (obvious statement really). You need to consider the ecosystem and how it can help (or kill) the project. A key cohort to consider is the leaders.
It will challenge any leader’s sense of personal worth and how they add value to the world. Recognise this and help them to understand their role, where they create value and their sense of self-worth.
For example, agility means operating with levels of uncertainty. It means being comfortable not having all the answers. How comfortable are you at saying ‘I don’t know’?
Also, ceding a level of control to teams will be uncomfortable for many. Saying that teams are empowered does not capture the range of possible feelings following through on that. Fortunately, being clear on how your control frameworks will change and what guiderails the team can operate within, helps leaders see how they can still exercise their responsibilities.
Not everyone is comfortable in this sort of team. There can be many reasons. Recruit carefully and be mindful that some people can add more value in a different team.
It is easy to get caught up in the new world. Be deliberate about what brings strong value from the past and what needs to explicitly change now. It’s a real opportunity to break down any functional siloes and amplify the value from combining the talents of the team.
One key request
Do not lose the voice of IT. This is about real collaboration and valuing the voice of everyone, creating the space for meaningful contribution. Additionally, the voice of IT needs to be strong to work with the stable backbone (see next). This allows you to make sure you manage the complexity of IT, without accruing technical debt that will be costly in the future (build for tomorrow not just today).
The next important factor is about learning. When you are working with uncertainty, help people to feel safe. Create an understanding, desire and environment where people can be open about what needs to be learnt and how to do this quickly (and cheaply).
Provide a stable backbone
IT engineering (including DevSecOps) provides the rigour and discipline for the team to achieve the pace and collaboration needed. Do not retrofit this later. Make sure the tools, processes and standards are in place before the team need them. Of course, this needs to iterate as you learn. Get into good habits early.