Agile adoption: our guide to effective Agile transformations


Change of any kind is a complex business and an Agile implementation is no exception. But Agile can be both the change you want to make and the change process to deliver you to the goal. In this guide, the Headforwards team share their knowledge and insights on effective adoption of Agile gained through more than 11 years’ experience supporting our clients with their own Agile transformations. 


One of the advantages of shaping a company from scratch is that you can build it the way you want it from the ground up. When Toby Parkins and I were first talking about what Headforwards could be and how it could operate, we were already Agile practitioners, and we were determined not to simply embed Agile as an approach, but rather make it a culture of our business.

I had seen through my own experiences working as a Development Team Lead with that corporate structures can stifle the effectiveness, creativity and enthusiasm of teams. To be clear, they were (and still are) a great organisation, with great people who achieved great things. I learnt a lot through my experiences at Tesco. However, from a strictly Agile perspective, their traditionally structured organisation impeded bottom-up Agile adoption. Headforwards was consciously built in such a way that bureaucracy was kept away from our software development teams, enabling them to self-organise and deliver value to our clients.

But what can you do if you haven’t got the luxury of building your business from scratch?

Most businesses want to become more Agile. It’s a crucial advantage in a competitive and increasingly turbulent economy and era. Headforwards has supported many businesses in becoming more Agile, from small teams to global corporates. Working with a company like Headforwards can be a quick hack if you want to get the benefits of Agile right away, but evolving how your business operates internally is a much longer and more complex change process.

Whether you’re starting with improving the practices with a single team or working to convince colleagues of the value of a full transformation, we’ve outlined some of our lessons and learnings over the last decade-plus in operation.

May the Agile force be with you.

Craig Girvan,
Headforwards co-founder and Agile evangelist

How Agile are you?

Agile can be both the change you want to make and the change process to deliver you to the goal.

Change of any kind is a complex business, and an Agile transformation is no exception.

Big changes can get lumbered with extensive planning processes and see organisations caught up in months or even years of preparation. With large, established organisations in particular, legacy structures and behaviours can make change difficult. It can therefore be an expensive risk to assume one big bang plan and its outcomes will happen as you expect.

We could develop an entire guide on the different approaches to change and their varying benefits. But when you strip it all back, Agile can be both the change you want to make and the change process to deliver you to the goal.

Genchi Genbutsu:
Go and see for yourself.

To truly understand a situation you need to visit in person.
The nature of the phrase is less about the physical act of visiting a site but more to do with a personal understanding of the full implications of any action within an environment as a whole.

Toyota Production System

Irrespective of whether you’re at the very beginning of your Agile transformation or you’re in a state of semi-Agile being, it’s important to really understand your baseline. We recommend two ways of doing this:

1. Your Agile Score

Measuring how Agile you are doesn’t need to be complicated but we do recommend giving yourself a numerical score. As a starting point, break down the elements of the Agile Manifesto and principles and put them into a spreadsheet. Add in symptoms and attributes of the principles and determine where your organisation sits on a scale.

For example, if we take the principle:

The most efficient and effective method of conveying information to and within a Development team is face-to-face conversation.

If your organisation is largely communicating by email, you might choose to give it a low score in this area.

The scores can be put into a graph to map your current Agile profile.
Add in symptoms and questions to get a greater overview of how the organisation is operating.

2. Go and see

One of the core pillars of the Toyota Production System, Genchi Genbutsu, which can be translated as ‘real location, real thing’ has a lot of value in an Agile transformation process.

You might not have a factory floor, but spending time in and among the team will reveal the reality of how departments and teams interact: what processes are being used, any barriers to progress that exist, and where Agile behaviours might begin and end. This becomes more complicated now people can be any combination of fully or partially remote, but the same rules still apply.

It can be more effective to use an external partner for this part of the process, so employees don’t adjust their behaviour or hold things back. But whoever leads this task should speak to a cross section of people throughout the organisation with a broad range of roles and responsibilities.

You should be looking to achieve a true understanding of how the organisation works, what Agile is to the teams and its value, and how processes work in practice.

Consider these questions for development teams:
• What are they doing?
• What are they not doing?
• How is the team organised? (seating)
• How accessible is the person who knows what the team needs from the software?
• What does the interaction look like?
• What tools are they using to communicate?
• What are the ceremonies like?
• Where are the meetings?
• What does the vibe feel like?

Collate all the information and identify any key themes starting to appear. We have seen clients map every single detail of organisational processes onto walls so that team members can see what’s happening and interrogate why certain actions are taking place. This can be an alternative way of getting the sense of the big picture and spotting issues and impediments to Agile.

Case study: Time spent in reconnaissance is seldom wasted

Working with a large corporate with the brief to support their Agile change process, we took both a Go and See and a scoring approach to better understand their starting point. We set ourselves up in a meeting room in the company HQ, observing the teams and identifying the right people to speak to. We plastered the walls of the room with post-it notes full of our observations, grouping them appropriately as themes appeared and using them as the basis for recommendations and quick wins.

We witnessed teams being next to each other physically, but due to the organisational structure, to communicate with each other they had to go up three levels, across two different points and then come down another three levels.

In many instances, when you’re embedded in an organisation as an employee, you can’t see the wood for the trees. You think you know what’s happening, and you might understand the organisational structure on paper, but in reality, who is reliant on who and what is getting in the way? Time spent in reconnaissance is seldom wasted.

What to expect: typical challenges

Every organisation is different but there are typical challenges worth looking out for.

Input from the right people

Embarking on an Agile transformation requires conversation with the right people. Consulting with Delivery teams and even the wider organisation in general is recommended. If you want processes to be used across an organisation, consultation can help with buy in and developing a better plan. If there are parts of the organisation already using Agile, gaining their input should be a priority.

Effective communications

IT and technology leaders often work on strategy but risk failing to engage and communicate it with the rest of the team or business. Finding ways to make communication and engagement easier will mean it will be less formal and you’ll get better, more regular insights.

Common language

In Agile transformations, another easy win is making sure everyone is using the same language to talk about the same things. Using the same word to describe different things, or different words to describe the same thing can cause confusion and unnecessary conflict in and across teams. Agreeing on your chosen lexicon is not to be underestimated!

Focus on the how

Having some form of plan is of course needed, and in some organisations, you might have had to build a business case for your Agile transformation. However, try to emphasise the how of the process change – the initial steps to take, rather than the destination.


We go into this in more detail in the next section, but sponsorship of an Agile transformation from the business leadership is essential. Business leaders must understand the value of an Agile transformation and back the process for it to be achievable.

Preparing for transformation

When you’re planning and preparing within the context of Agile transformation, you’re not trying to precisely define an end point. In fact, what you’re looking to establish is the most effective starting point.

The most effective starting point will depend on your organisational context: how big the business is, how Agile or not you already are, and a host of other dependencies. But there are also common factors most organisations will need to consider.

1. The role of leadership

Large, hierarchical businesses will not be able to achieve an effective Agile transformation if they think it will be a grass- roots project. Transformation – whether Agile or otherwise, needs to be sponsored and have the backing of the C-suite or the majority of senior leaders if it is to be successful.

An Agile structure shifts the decision making to those who are best placed to make the decision – often, that’s not the senior management. Therefore, it is vital that the move to Agile is thoroughly understood and embraced by the C-Suite.

Organisations need buy-in from a high-level stakeholder who can clearly communicate the value to fellow executives. If the direction doesn’t come from the top, people at different levels of the business will have conflicting priorities and progress will be slow or non-existent.

The leader should:
• Be a servant leader.
• Recognise the investment of people’s time; this is not something that can be tagged on to the end of the day or completed during lunch breaks.
• Be someone who can clear any blockers – “forget about asking me for permission, just go and talk to whoever you need to talk to.”
• Have the authority to give something priority.
• Be responsible for a substantial amount of budget and therefore have the means to enable the transformation to happen. Often the Financial Controller is a good choice of leader.

The leader must be informed of progress throughout the journey.

2. Creating a shared vision

The business in its entirety must have a shared vision of what the future, and the definition of ‘good’, looks like. IT leaders cannot define what the future will look like without any engagement with the other departments.

A shared vision of the future is not the same thing as having a defined outcome and plan. Instead, this is about getting clarity on what you’re trying to achieve. Until you start to make changes, you won’t know where the destination is, and it’s most likely not where you think it is.

3. Building a transformation team

To get from a collective understanding of what ‘good’ might look like, to enabling the organisation to get there, the formation of an Agile Transformation team is an effective strategy.

The team – with representatives from across the business, should be organised around a regularly refined Transformation Backlog – creating a prioritised list of what needs to be done. Inputs could come from anywhere – teams, conversations, old plans containing relevant ideas.

The team should come together and process small chunks of their destination, putting it out there, testing it, and reviewing how it has gone, before moving onto the next one.

One person should be identified as the owner of the backlog; that person calls the shots on the priorities of the backlog, owning the transformation journey – much like a Product Owner in a Scrum team.

That person decides on the top things to do on that backlog. They don’t put the items into the backlog, but rather detail all the work that needs to be done and draw up a list of tasks needed to be able to complete each of those high priority backlog items.

Better still, the Transformation team enter a planning session where they discuss the next top backlog item and identify the tasks required to complete it. Tasks are not defined by a Product Owner, but by the team.

Getting started

All organisations will need to start in different places, but we coach our clients to accept the status quo as it is right now and take the first steps towards starting to improve and move towards being more Agile.

You should have a good idea from your baseline activities what the impediments to Agile look like in your business. Actions and steps don’t need to be complicated and in fact in many cases are deceptively simple.

In one of our corporate clients, we identified that their hierarchy was an impediment to Agile; the Development teams couldn’t get simple answers to questions without going through layers of management. Our advice was simply to ask the Product Owner from the business side of the team to sit with the development teams in IT – whether a couple of days per week or full time, so that communications were direct and responses were almost immediate.

A solution that involves small iterative changes is far easier for a business to deal with than overhauling entire processes and working practices. This is an example of where the fundamental principles of Agile can be implemented into the culture of any transformation solution.

Where to start

This is again, hugely dependent on your organisation. A lot of organisations start with Development teams because their requirements are changing more frequently than for example, Product teams. But Agile transformation is about collective effectiveness across the whole business, not just within some of the teams. Despite Development teams often being a logical starting point, don’t be surprised when you quite quickly hit a ceiling where the impediments to the teams delivering to an Agile methodology come from other areas of the business.

Getting things done

Prioritising work is particularly useful on transformation projects. There’s an endless number of ways to do it, but we have found the Eisenhower Matrix useful with some clients. Urgent and important tasks, you must do, and important but not urgent, you must schedule.

Agile coaching

Depending on your business, you may find supporting your organisation with Agile coaching beneficial. In some instances, the benefits of Agile are widely understood and the bigger issue is getting started on the transformation. In other teams, Agile coaching can really support the organisation in delivering the transformation effectively.

Securing the future of the transformation

Agile is about your organisation having the ability to adapt gracefully given changes in goals and context.

For a system to work, it needs to continually adapt, and it needs to adapt in a graceful way. An Agile Culture team – perhaps the original Transformation team, could facilitate continuous tweaking of internal systems and processes in accordance with changes in goals and context.

Less time and energy will need to be spent working on the transformation, but a body needs to be in place to ensure changes are dealt with effectively.

About Headforwards

Our track record in Agile comes from almost 12 years specialising in Agile custom software development. Through out work with global clients including AXA, NTT Global, local authorities and the fintech and health sectors, we have first hand experience in facilitating high performing Agile software development teams and supporting our clients on their own Agile transformations. Our services span IT consultancy and advisory, custom software and the implementation of digital transformations including data and BI.

To find out how we could support your business, get in touch.

Headforwards™ is a Registered Trade Mark of Headforwards Solutions Ltd.
Registered Address: FibreHub, Trevenson Lane, Pool, Redruth, Cornwall, TR15 3GF, UK
Registered in England and Wales: 07576641 | VAT Registration Number: GB111315770