Agile adoption: our guide to effective Agile transformations

Foreword

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 Tesco.com 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.

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.

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.

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.