The thought that you wouldn’t use Agile in a project where requirements were defined upfront was also an oddity to me – why wouldn’t you mitigate risk and get feedback as you deliver despite thinking that you got your requirements 100% right? At one stage of my life I was a Business Analyst. I wrote the best business and system requirements. My documents, in my mind at the time, were epic odes to the perfection of thinking. I learnt very quickly that defined requirements never changing was a farce. I was human and my mind had unintended errors and gaps. 

Some would dispute that Kanban is more a Lean method than an Agile one, however I have considered it one element of a wider suite a methods, practices and techniques. This suite used to be known as an “Agile umbrella” but it is now referred to as “New Ways of Working”. It combines Lean thinking, Lean Startup thinking, Design thinking, Agile thinking, Software craftsmanship thinking and much more. 

With such a broad toolkit now at the disposal of organisations we should be solving problems everywhere. But we aren’t. We aren’t consistent, nor predictable in the outcomes of our transformations. Our perfect designs and methods are failing on implementation or their stickiness is not strong enough to handle a significant c-suite change. Maybe we are suffering from the same problem that we had when we thought we could do requirements upfront – that we think we know all the answers when really we are doing it totally wrong.

I had for a while thought that the potential solution lay in experimentation – testing and learning the processes that work for a culture. Part of me is still attached to this thought, especially as I have seen it work more often than not. After all, complexity theory says that in a complex system that ‘probe-sense-respond’ is the best approach. But what if complexity theory is wrong too?

I love Agile. I love what it does to individuals and teams and the difference it can make to them. It is just a lot harder at scale to get it working. There are schools of thought that the best approach is to descale your organisation. I’m not against this as a tactic, but to me it is an overly simplistic answer to a complex problem.

Yes there is tonnes of literature about setting yourself up for success on what you need to do when kicking off an Agile transformation, I probably have a blog or three on this already, but lately I have been thinking that in some organisations we shouldn’t be trying to do Agile transformations. I know, this is very heretical.

I’m not proposing that we give up. I now have a different hypothesis – fix the more critical issues in the organisation before trying to kick off an Agile transformation. What critical issues you may ask? If you have any of the following issues I believe you should try to fix the root cause of these before trying any form of transformation (Agile, New Ways of Working, or something else).

The ‘restructure every three months’ organisation

If your organisation restructures at least every six months (and I know of a number in Australia that restructure its people at least three times a year) then I don’t feel like an Agile Transformation is going to be successful in this environment. 

Agile requires stable teams to create productivity. Every time you restructure you:

1. Create uncertainty. This uncertainty dramatically reduces individual productivity.
2. Force teams to go through Tuckman’s model, again decreasing productivity.
3. Force work to be re-distributed to teams, creating a hold on flow.
4. Confuse stakeholders who work with teams on where work is at and who to engage/work with, also dramatically impacting flow.

The science of impact on productivity for points 1 and 2 are well understood, but I believe there has been little done to demonstrate the significance to productivity of points 3 and 4. 

I would argue that you should test and learn to what extent your restructures are successful in removing problems. If your organisation restructures more than three times in a year I don’t think there is enough stability to be able to test and learn from. 

Also, all too commonly organisations restructure to solve one problem and inadvertently create new problems, hence creating the cycle of pain where another restructure is required. Any structural pattern will have trade-offs – most organisations don’t spend the time to understand the options, trade-offs and mitigating steps for each trade-off. 

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop restructuring more than once a year (twice ideally)
2. Learn your choices and trade-offs and implement appropriate mitigations
3. Test and learn using real data – how do you know your organisational productivity and how does your structure affect it?
4. Change manage the restructure better to mitigate productivity risks (most organisations say they do this, in my experience I have yet to see one of them do it well)
5. Performance manage out your people that aren’t performing. This means having a HR group that can actually deal with difficult conversations and managers who have skills to deal with system thinking around performance (assuming Deming’s Law that 85% of issues are the system and not the person). Why did I add this one? Most organisations use re-structures as a means to remove poor performers (mostly due to labor laws) rather than doing the hard yards to remove them through the formal HR process. If organisations did proper systems and performance management a lot less restructures would be required. You could also argue that better recruitment processes would reduce poor performance issues downstream. 

The ‘implement change without change management’ organisation

If you are in an organisation that rolls out change poorly then trying to roll out an Agile Transformation is going to be impossible without good change support. Poor change management includes:

1. Change plans that are never implemented
2. Change plans that don’t target the right groups
3. Non existent change plans
4. Insufficient change plans (for example an email or two is done but nothing to embed a real capability change)
5. Lack of focus on behavioural value differences. Immunity to change talks about behaviours that are hard to shift because of unconscious needs. This requires a individual or a persona based approach to change management rather than a whole collective approach.
6. Rolling out a change that has been ill-considered or not piloted

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Look at the capabilities and process by which you do change management and get real data from people (not managers) within your organisation as to how successful previous change initiatives have been
2. When you find that they haven’t been as successful as you have previously thought, find out why. Do some root cause analysis and fix these problems
3. Check to ensure that your change management processes can handle an incremental approach to delivery

The ‘waiting for the next CEO’ organisation

I haven’t seen this pattern often, but it tends to be in extremely bureaucratic organisations or in government organisations that have a fixed date of leadership tenure. In this type of organisation the CEO has had challenges in their leadership style. This includes:

1. They do not create a safe space; failures are not tolerated
2. They make outlandish promises to shareholders on what can be delivered and when, without ever checking with the people who will do the work if it is achievable. They often do this under the guise of creating a “strong vision” or “stretch targets”
3. They don’t connect with their organisation beyond their direct reports

The impact of this is an organisation full of apathy and disconnectedness. People within the organisation don’t want to invest their time in the vision or any changes driven top down. Consequently they do the minimum they must do to fly under the radar resulting in the organisation staying in a holding pattern whilst they wait for the CEO to be exited.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Have strong conversations at the C-Suite layer or even the Board about how the CEO is performing and how their behaviours impact the productivity of the whole organisation, how it sets an example for the leaders underneath them.
2. Think about having an ‘Undercover boss’ mechanism to get real feedback on problems and insights of people deep in the organisation.

The ‘new shiny’ organisation

Are you in an organisation that has trouble focusing? ‘New shiny’ organisations tend to act like a cat chasing after a laser light – everything else gets zoned out. The biggest issues with this type of organisation tends to be:

1. That once something is kicked off there is little focus on delivery or execution of the work
2. Which results in lower benefits realisation, lower value to customers and a delivery system filled with waste
3. And whilst the ‘shiny’ might be Agile, something new will come along and you will end up having an implementation that no longer has any focus or intent to follow through on
4. Then there are the real problems of the organisation that are never really prioritised as the new shiny keeps everyone’s attention.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop starting and start finishing. Learn how to create focus through to value realisation before kicking off something new. 
2. Have a mechanism for being able to understand what the core problems/impediments are in delivery, ranked by waste and track very frequently the steps being made to resolve them. In essence, focus on delivery optimisation.

The ‘we don’t have time to be smarter’ organisation

Are you in an organisation that is so busy that there is no time to work smarter? People are always in meetings. They have meetings on top of meetings. They have lots of people doing the same thing. Each area solves their own problems, but the same problems exist all throughout the organisation. 

Fundamentally this is an organisation that has no slack (teams loaded 100%) and a fixed mindset. To be fair, there will naturally be individuals who in the organisation still have a growth mindset, but the organisation isn’t culturally setup to encourage continuous improvement and to encourage learning.

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Stop behaviours like cutting project costs or time frames. I see this all too often – executives think a project costs too much, slashes the budget or time and forces the team(s) to deliver under this pressure and think they have saved the company millions. Every time I see the project ends up costing the original figure and time, but because teams were forced to think they had less time they cut corners, reduced quality and introduced technical debt. It is a false economy. Work ends up being costing more over time due to the operational maintainability of the solution.
2. Introduce slack time into the system – load teams up to only 80%. Slack allows the system of work to handle unplanned exceptions and gives people space to think critically about the what, why and how of their actions before starting them. It also gives people space to look more broadly to other people and other organisations for solutions to problems.

The ‘we’ve tried it six times before’ organisation

Some organisations have already tried Agile many times over and failed. They have this really strong belief that ‘this time it will be different’ which may be true, but all too often, little is done to retrospect on why previous attempts have failed.

If you are in one of these organisations, before implementing your next Agile transformation you should:

1. Do a root cause analysis on where implementations have gone wrong (it could have been one of the previous types of organisational patterns that has caused this)
2. Share with the C-Suite and the board these findings
3. Get buy-in with this group on how this implementation is going to be different and how it is going to address those root cause issues
4. Test and learn whether it does address the issues before rolling anything out.

The ‘we have five consultancies in here’ organisation

I am not saying that consultants are the problem – just that lots of different consultant groups who are unaligned is a really big problem. Consultancies, much like coaches, can help to give you perspective that you don’t ordinarily have, they can provide expertise and global knowledge and help drive a greater focus towards value. But if their perspectives differ then you are going to be creating deep factions of power in the organisation that are working against each other. Often they also don’t have visibility of what each other is doing. 

If you are in one of these organisations, before implementing an Agile transformation you should:

1. Think about consolidating/reducing the number of consultant groups
2. Create visibility about what what each group is focusing on, or ensure that the work is fully mutually exclusive
3. Determine if there is a lack of alignment between groups and hold workshops between invested parties (ie the people who are working with the consultancies) to reach alignment.

The ‘we have managers (not leaders) everywhere’ organisation

You may have picked up through some of the suggestions above that a few key techniques are being consistently utilised. Agile requires a different type of manager, a leader who can help to change the culture of an organisation, who can think critically of ‘the way that we do it now’ versus the possibility of the future of the organisation. A key enabler to Agile that you should consider prior to kicking off an Agile Transformation is a Leadership Transformation. A Leadership Transformation should: 

• Focus on lean wastes and flow analysis, systems thinking, and root cause analysis capabilities across the organisation
• Focus on the difference between management styles (Taylorism, Theory X vs Y, Management 3.0) and what works in the organisation now versus what is needed for the organisation going forward (which does depend on a really clear vision for the organisation)
• Educate managers on options on how to structure it’s people and what the impact that structure has on communication and flow
• Educate managers on options of governance and finance and what the impact that these options have on flow, engagement, and values
• Provide managers incentives to focus on new behaviours (though be careful as extrinsic motivation can backfire)

This leadership transformation creates the internal pull for an Agile transformation, but importantly puts leadership on the journey sooner so that they can be more effective in supporting an Agile transformation through the right behaviours. 

A final note

Agile Transformations are tremendously hard. Don’t make it harder by setting them up for failure before they have even started. 

In the VersionOne 11th Annual State of Agile Report 2017 the importance of Executive Sponsors is highlighted both to the success of scaling Agile and to mitigate challenges.

This importance has grown dramatically over the last five years as Agile transformations have moved past the realms of just changing teams, projects and even programs and have expanded into the whole organisation stratosphere of transformation – trying to address the problems of governance, finance, HR and leadership within the enterprise.

I’ve seen a vast number of Executive Sponsors over the years, some amazing and inspiring, others competent, and sadly a few who were dropped into the role (or used it for a launchpad to boost their career) who didn’t believe in Agile.

But what does a good Agile Executive Sponsor do?

They are a role model, with a vision, a growth mindset and willing to invest their time and reputation against making the tough calls and re-wiring the culture of the organisation. How does that translate to activities and behaviours on a day to day basis? Highly effective Agile Executive Sponsors will:

1. Live and breath agile
2. Set a vision and not stop talking about it
3. Make the hard calls
4. Give space for reflection, learning and improvement
5. Stop starting and start finishing
6. Go to the place of work, and
7. Invest a considerable amount of their time to removing impediments.

Let’s look in more depth at these seven key activities and behaviours:

Practice what you preach

As an Agile Executive Sponsor, if you are asking teams and people to change their behaviours and activities, the first person that has to change is likely to be yourself. How much are you living the values of both the organisation and Agile? How often do you check yourself to ensure that you are living by those values? Ask yourself these questions:

Behaviours

• Do you collaborate to get insight when making decisions or make decisions by yourself?
• Do you delegate decision authority down or make it centrally come to you?
• Is strategy defined collaboratively or defined by yourself?
• Are you seeking input on the strategy from a diverse set of people, regardless of hierarchy, or is it done by yourself and your immediate reporting line?
• Are you making yourself available to anyone in the organisation for feedback and insight or do you get insight only from your reporting line?
• Are you giving yourself time to reflect and improve or are you too busy to stop and think?
• Are you coaching and mentoring rather than advising and telling?
• Is your work, decisions and assumptions transparent to everyone or just limited to the people you have conversations with?
• Do you share information and encourage others to do so as well or you ask for reports to be made for you?
• Do you proactively seek the root cause of issues and look for patterns or you react and try to fix things as they arise?
• Do you see failure as a learning opportunity or do you remove trust on failure?
• Do you encourage simple, lightweight approaches to solve customer and business problems or do you ask for a plan before committing to trying anything?
• Do you treat all assumptions as hypotheses to be validated or encourage solutions to be built because you already know the problems?
• Do you ask for help or is everything on your shoulders?

If you answered “yes” to the left hand side of the questions then you are fast on your way to becoming an Agile Executive Sponsor who practices what they preach.

Activities (aligned to strategy of transformation)

• Are you having stand-ups?
• Are you attending showcases?
• Are you removing roadblocks raised to you?
• Are you participating in ceremonies that encourage continuous improvement and innovation?
• Is your plan flexible and adaptive as your discover new insights?
• Are you attending customer tests?

If you said ”yes” to these activities then you are setting up the environment around you to work in a more Agile manner.

Set and grow a clear vision

Agile Executive Sponsors don’t set a vision by themselves. They aggregate many people and many narratives to be able to understand the current state, the constraints in the system, the appetite for change and build a vision for the next state with these in mind. They set a very simple high level vision and focus on only the next or or two steps that need to be made immediately.

The vision isn’t just talked about once, it is re-iterated many times opportunistically through conversations and clarified when needed.

The vision isn’t set in stone but can adapt and change as both new information comes to hand and as experiments are run.

On a day to day basis the Agile Executive Sponsor seeks out narratives and stories by people which indicate that there is a misalignment on the vision and seeks to bring people together to re-establish connectivity to the vision.

Make the hard calls

This seems to be the most challenging of Agile Executive Sponsor capabilities. There is a paradox of behaviours and activities in conflict – on one hand as an Agile Leader you are encouraged to care deeply about people because you know that it is through highly engaged people that magic happens, and yet enterprise transformations call for a significant shift in capabilities and roles in the organisation. Some roles will remain unchanged, some roles will cease to exist, some roles will be consolidated and simplified and new roles may be created.

Making the hard calls may mean changing who remains in the organisation. It may mean having crucial conversations with senior leaders in very traditional parts of the organisation to shift their focus, to challenge their thinking and their behaviours. Your influencing skills have to be strong.

There will be winners and losers in an enterprise Agile transformation. This sounds rough, but it is a harsh reality. Not everyone is going to like what you are attempting to do, but whilst it will be hard there will be many people around you to support you, if you ask for help.

Create slack for reflection, learning and improvement

Changing an organisation from a fixed mindset to a growth mindset (also known as a learning organisation) doesn’t happen overnight. There is often an overwhelming pressure for delivery above all else. It is relentless, and in its wake learning and slack are the losers.

After making the hard calls, one of the biggest challenges for Agile Executive Sponsors and leaders is how to give space for reflection, learning and improvement. Here are the top tips for Agile Executive Sponsors to create slack:

• Don’t load up teams and people beyond 80% allocation. In Agile teams this is done through a technique that may not be immediately obvious – yesterday’s weather – where teams load up their planned velocity for an Iteration based on their previously achieved velocity. The hidden assumption in this is that the previous velocity takes into account unknowns and re-using that velocity will automatically build in slack for the Iteration. The reality is this tends to be true 50% of the time. Why 80%? Studies have shown that 80% gives enough space to handle unforeseen urgent items.
• Encourage goals that weight learning equal to delivery. KPIs are often unilaterally or predominantly focused on delivery – is it any wonder that learning tends to take a back seat to delivery when this occurs?
• Understand that working smarter rather than working harder will have an incremental payoff that will take time. As learning and improvement grows, capability will grow and teams will find better ways, quicker over time.
• Slack and introspection are as equally important to yourself as they are to Agile teams. With slack, people tend to think more creatively about problems which results in better solutions.
• Understand that personal change takes considerable time and re-enforcing of behaviours.

Stop starting (or restarting) and start finishing

One of the most frustrating experiences I have ever had with enterprise Agile transformations is the one where the vision, goals and activities of the transformation were continuously changing. Just as change was starting to happen the goal post moved again (and again).

It’s okay as an Agile Executive Sponsor to not get your vision right from day one, it’s okay to change and adapt the plan, but if all it turns into is talk with no change after a few months then there is a big issue with your transformation.

Agile Executive Sponsors get fearful that they have to do a change perfectly for everyone at once. Instead, focus on a small change through multiple experiments across multiple teams. Use this information to work out what changes work better and then amplify the patterns that are successful.

Agile Executive Sponsors also think they need to have lots of different work on the go – just like delivery teams, it is better to focus on getting the few changes done well than trying to do everything at once.

Go to the place of value (gemba)

In today’s age of distributed teams it seems to be a common excuse that leaders can’t go to their teams as they aren’t sitting together. If their teams reside in the same city it really is an excuse and one of the highest priorities of an Agile Executive Sponsor should be to move people and teams together.

Lean uses the term ‘Gemba’ to refer to the act of going to the place of work where value is created. Agile Executive Sponsors should make a constant effort to sit and move around the teams who are delivering work in order to gather insights on the challenges that teams and individuals face through overhearing conversations and being available for direct conversations.

But it isn’t enough to gather insights, highly effective Agile Executive Sponsors will follow through and solve these problems.

Remove impediments

Removing issues that are either blocking teams or slowing teams down from delivering should be the primary day to day activity that Agile Executive Sponsors focus on. They will need to integrate all of the above six practices together in order to successfully achieve this. Start small and simply, getting some early runs on the board of solving issues. An Agile Executive Sponsor must be fully empowered by the CEO in order to achieve this, otherwise they are highly likely to fail in a system that is still heavily dependent on positional power to enact change.

This doesn’t mean that the Agile Executive Sponsor personally has to solve all the issues, rather they have the connections, pathways, influencing power and tenacity to follow through on delegated issues as they are raised across the organisation. The biggest challenge an Agile Executive Sponsor will face is that there will be so many issues how to best prioritise them – using both Agile techniques and insights gathered to prioritise.

Conclusion

Transformations take a long time, are fraught with many issues as adopting new changes is hard for everyone. Aside from performing these seven habits, Agile Executive Sponsors will need to have a tempered balance of both patience, resilience and tenacity. Too much patience and the transformation will stall, too much tenacity and the change will be fully rejected, too much resilience and people will be change fatigued.

In a few weeks we will take a look at Agile Leadership and see how the role of a Manager changes in an Agile organisation.

A note on enterprise transformations

I have seen some great Agile Executive Sponsors who started an transformation by not being very strategic or proactive and instead focusing the transformation in a one step at a time fashion. Primarily they did this for one of three reasons:

1. They don’t have the authority to change elements outside of their boundary of influence
2. There was limited organisational appetite at the C-Suite for an enterprise change
3. There was limited understanding at the C-Suite about what an Agile Enterprise Transformation meant

These executives were highly successful in the areas that they championed the change in, but in all instances the change stalled and was limited in its effectiveness. As an approach, if one of the above three problems exists in the organisation it is highly likely that a such a champion does need to step up and perform a smaller scoped transformation so that insights can be gathered at the C-suite level before a wider scale change is endorsed.