I have had lots of conversations lately with CIOs and Senior IT leaders about moving to agile. There was a CIO who has invested heavily in training and support for their team, but is experiencing push back on agile practices from the executive who still expect business cases and predefined scope and benefits. A long term industry colleague who is committed to transitioning to agile, but doesn’t really know where to start and another who thinks they are agile because they have employed a scrum master and have a Kanban board and is wondering why his colleagues don’t get it.
These are just a few examples of the nature of the “transitioning to agile” conversations I have had recently. It seems that everybody is doing it or thinking about doing it. For many organisations moving to agile starts and finishes with changing the way they manage and deliver technology change. They do this by implementing the agile methodology of their choice and while this is necessary it is not sufficient.
Yes you can and will need to implement Agile and DevOps methods, but that doesn’t mean you will be agile. There is a lot more to being agile than changing your methodology and actually, that’s probably the least important thing you need to do. Implementing agile is like going on a diet, being agile is changing how you live your life day by day to support your weight, health and fitness goals.
A move to agile or DevOps is a “lifestyle” change not a diet and to be effective you need to review and change all aspects of your IT operating model if you expect to realise the intended advantages and benefits of this move. There are a number of different ways to define an operating model, but you can start by considering these questions:
- Why is being agile important? Agile is a means to an end not an end in itself. You need to understand what the end, the goal is and ensure your agile implementation is focused on that outcome.
- How will we know we are being successful? What measures do we need to be able to monitor progress? No implementation is a straight line to success, consequently we need to monitor to what extent our actions are leading to success and adjust accordingly.
- Does our IT organisation structure support our goals and new ways of working? New ways of working often require new structures, roles and responsibilities that traditional IT lifestyle organisation structures may not support. Do you need to change your structure to facilitate the new ways of working?
- Do individual job descriptions support the new behaviours and skills we need to be successful? What mix of specialists vs T Shaped employees will we need. Being truly agile requires a combination of specialist skills and flexibility. Do you have the right mix of specialist skills and flexibility and do you have people who can excel in this environment?
- Are the incentives for teams and team members aligned with our goals and preferred ways of working? Most people are smart and they will act in a way that is consistent with their incentives. So if you want different behaviour and outcomes you need incentives that encourage the desired behaviour and outcomes.
- Have we provided the team with the information and tools they need to be successful? New ways of working often require new tools and different information than we have traditionally used. For example, if you are committed to continuous deployment and continuous integration then you need to ensure the team has the tools and processes they need to make this happen.
Once you have your answers to these questions you can begin to map out all of the changes you need to make in order to transition your operating model to be supportive of agile / DevOps. There is no one right way, no recipe to follow. The way you manage the transition will be a combination of your specific goals, your organisation culture and current ways of working and your leadership style. That said, if I was a CIO and looking to transition to agile / DevOps I would most likely follow this process.
- Define your vision and goal for IT within your organisation. Socialise and agree this with executive, key influencers across the organisation and your team. This vision / goal will then provide you with all important context for all future decisions.
- Define and implement metrics to guide you on your journey, provide feedback and monitor progress. Don’t forget to use these metrics to help you correct course and just as importantly as a means to highlight progress and celebrate successes.
- Review your organisation structure and consider organising IT around business functions / processes and the systems that support them (rather than around the IT lifecycle)
- One person, responsible for both Development and Operations for the systems they manage
- Align incentive for these teams that balance development / projects, system operations and end user / IT customer satisfaction.
- Engage business owners to own the content and prioritisation of backlog (and start to become a product owner)
- Begin to reduce the average size of “projects you deliver” to speed up delivery and improve learning cycles and reduce delivery risk.
- Move to “programme funding” and programme approvals rather than project funding and project approvals, then deliver small fast “projects” within the programme.
- Focus on business outcomes and benefits.
- Stop when benefits are realised (or rescope for more!)
- Redefine roles within the delivery process to be clear about business (or product) ownership
- Manage “project” / function / use case / requirement backlog within the programme
- Formally introduce agile methods across the team and into key relationships.
- Move towards T shaped employees and T shaped job descriptions.
- Invest in tools that support rapid / continuous delivery e.g. automated testing
Finally, ensure you have the right expertise to support you on this journey. That includes agile and DevOps expertise as well as IT operating model and organisation design expertise. The extra time and money spent upfront leveraging expertise will shorten your time to benefits and save you significant cost in the longer term. It will also equip leadership teams with the knowledge and confidence required to be successful in one of the most challenging change programmes of our time.
First published on LinkedIn