COVID-19 was the biggest driver of culture change in the last year

COVID-19 was the largest influence of change in the culture and methods space in 2020 and the knock on effects in 2021 are driving many of the trends we see at this time.  The previous trends report was released early in the pandemic and we now have a year’s worth of content to explore how the IT world has adapted and responded. There have been many examples of great collaboration, teamwork and adapting to new ways of working along with plenty of stories of hardship, Zoom Fatigue, mental and physical health challenges and other impacts as people have adapted to working from home, managers have changed long-held beliefs about remote work and organisations have adopted new technologies to support the shift.

Source: Culture & Methods Trends Report March 2021

We can see our forests vanishing, our water-powers going to waste, our soil being carried by floods into the sea; and the end of our coal and our iron is in sight. But our larger wastes of human effort, which go on every day through such of our acts as are blundering, ill-directed, or inefficient, and <redacted> are less visible, less tangible, and are but vaguely appreciated. We can see and feel the waste of material things. Awkward, inefficient, or ill-directed movements of men <or women>, however, leave nothing visible or tangible behind them.

This could be a quote written a week ago, but it was written in 1919 by Frederick Winslow Taylor in his management book of the century The Principles of Scientific Management.

A lot has been said about Taylor’s book that eventually led to the movement of Taylorism. The most commonly held indictment is that it was mechanistic thinking, taken in an era of solely mechanical manufacturing and no longer applies to the modern world.

Winston Royce also wrote an article about software development, citing that a linear approach to development, aka waterfall, would be the wrong approach. Readers misread or misunderstood this leading to a world of in appropriate application of techniques and patterns.

Whilst Taylor’s belief systems in the book may be held up to scrutiny today, like Royce, Taylor’s work has been misinterpreted and vilified by those pushing modern management methods*.

This blog post will discover where Taylor’s Principles of Scientific Management aligns with current modern management thinking, where it is in stark contrast and the grey zones that need further discussion.

Aligned with modern thinking

The following concepts described within The Principles of Scientific Management are aligned with modern management methods:

• It is important to ensure that individuals are suitably trained to be competent for their job. This should be considered over hiring in skills.
• Competency is not just people contributing value to the product or service but also leaders.
• To have a prosperous organization, you have to have prosperous people.
• People need to be paid a fair wage (also noted as a first pillar of motivation and a basic human right in Dan Pink’s book Drive)
• Managers know that the collective wisdom of those underneath them far exceeds their own wisdom. Because of this, managers are best placed to provide a clear problem and then steer clear of going into solutions.
• Management is a co-operative activity, managers should guide, done daily, but even if guiding should be partly accountable for the outcome. Managers should not direct or coerce.
• The importance of customer is a critical third pillar of any organization – employer, employee and customer need to be considered together.
• There are no silver bullets for solving organizational problems.
• Inefficiencies are most often due to the system.
• Time and motion studies should be utilised to assess and remove waste or simplify steps. The modern take on “time and motion studies” is value stream mapping and optimization.
  One of the bigger challenges that people have to applying Lean in Software Delivery is that removing waste doesn’t apply to knowledge work and that it is best applied to manufacturing. Whilst it certainly cannot be denied that Lean excels in a manufacturing environment, waste does exist in knowledge work. For example, in software development, if you are running too many branches at once then you have merge motion that multiplies out. Another example is unstable development teams, which result in knowledge waste.
• “Sweat shop” conditions don’t make for an effective organization. Sustainable pace of delivery is important to flow and optimal value output. This means having breaks and suitable working hours.
• Productivity, that can result in a competitive advantage, is obtained through efficient usage of both humans and importantly machines/automation
• Some methods/techniques are better than others for specific problems. A large toolbox is valuable and knowing what the right tool to use for the situation is important. Use real data to give insight to what tools work best in what circumstances.
• Run experiments to find what works more effectively, this is especially true when the problem to be solved is complex.
• Quality over speed is never an acceptable trade off. Quality needs to be kept high in parallel to improvements in efficiency.

As you can see from the points above, Taylor’s Principles of Scientific Management aligns quite heavily with Lean and to some extent the works of Agile, Systems Thinking, David Marquet’s Competency model and Lean Startup.

Unaligned with modern thinking

With the movement of time, however, there interestingly has been a cyclic return to concepts that Taylor is directly advocating against. These include:

• Management is a true science with clear laws, rules and principles. Scientific management is applicable to all kinds of human activities.

The Principles of Scientific Management sometimes also refers to itself as a Task Management approach. It was brought about in the industrial age and was dealing with human to machine interaction. Whilst the world back then was typically a heavily physical interaction, now days it is more of an intellectual interaction where the machine is the conduit for activity between individuals through human built programs. The statement above is why Taylorism gets labelled as “mechanistic thinking” rather than “ecosystem thinking” but it is not surprising when the problems that were being dealt with back then were either simple or complicated.

Most work place environments are complex where the laws, rules and principles are spread out over so many sub-systems of management and are often conflicting with what was the original intent behind the Principles of Scientific Management – that of an efficient individual producing quality output. We have gone awry with controls and convoluted value streams and should seek to first simplify. This isn’t to say that all things complex can be simplified down to a complicated or simple space of problems, but that there is still a lot of simplification opportunities out there, though getting management to a stage of science is probably an unlikely goal and dismissive of the human element. Enforced standardization for everything is not the answer, but in some cases some standardization may be beneficial and in other cases removal of standardization may be beneficial – the point is, you need to understand the problem space you are dealing with and the impact that standardization (or lack of) is having.

Scientific management doesn’t work in complex environments where the best outcome is non deterministic. That said, scientific management also concedes that in complex spaces, an experiment approach should be taken to find the more of the successful patterns to implement. This is not unlike a ‘Probe-Sense-Respond’ approach that Agile utilises.

• People have a natural instinct and tendency to loaf

This is certainly a divisive statement. Those people familiar with the Theory X vs Y work will recognise this statement as coming from a Theory X leader, that is, someone who is naturally pessimistic about their people, thinking of them as unmotivated and needing constant direction.

Taylor goes on to say that systematic “soldiering” (underworking) is intentionally done to keep employers ignorant of how fast work can be done. It is in each person’s self interest to not work faster than anyone has in the past before. They work as slowly as they dare.

Whilst these are certainly shocking statements, one thing of note however is that there has been a growth of science to back up some of the statements made in the area of social loafing. This is not the say that the solution to the problem should be command and control management and standardization, but interestingly the transformation approach within the Principles of Scientific Management actually had the answer – to separate the team and one by one reform a higher standard, re-integrating individuals one by one to negate the chance of social loafing. Taylor’s approach also made it clear that each individual’s contribution would be assessed and rewarded as an individual over as a team to ensure performance. Interestingly, these are two of the steps to combat social loafing.

But how does modern management approaches deal with social loafing? Agile tries to keep people accountable through setting regular small goals and helping to support the team to achieve them on a daily basis. I was once a Scrum Master in a team where one person in the team was underperforming. It was obvious to everyone in the team (including the individual involved). The person actively opted to exit the team citing that they knew they couldn’t keep up and didn’t think any level of support would get them to that state. This is exactly what is described in the book – that not all individuals are cut out for all work and even despite support and training, sometimes they should just find something better suited to them. This individual went onto a production support team and continued to perform well and happily. The more horrible version of this is the opposite effect. I was once in a job where I was pulled aside by my manager. They said, “I have had a few comments about your performance. You seem to be going fast against everyone around you. We need you to slow down the pace of your work.” It wasn’t that I was conceptually ahead of everyone, it was that I was literally putting too much output out and getting complaints because of it. I discovered that if I stopped work at 11am each day I met the pace of everyone else around me. I was forced to loaf at the pace of others so they didn’t feel bad about themselves. Acceptable performance rates are defined by the norms of the majority. I really don’t think anyone has a great solution to this problem yet.

• People need to be financially incentivised or incentivised for a promotion to work more effectively

Dan Pink’s ‘Drive’ book and the studies referenced within highlight that people need basic rights incentivisation to be motivated to work, but that extrinsic rewards like bonuses do not work in knowledge work environments. ‘Drive’ does note that this works for simple problems, especially manual problems so it isn’t surprising that Taylor came to the conclusion that bonuses are an effective way to motivate individuals, but it is clearly a statement that doesn’t work for problems requiring human thinking. Some organizations are already taking the step to remove bonus systems not just because of this but because of the time effort invested in it and because of the conflicting environment it creates. It should be noted that when Taylor talks about incentivization, he specifically says that quarterly or yearly bonuses are not the solution and are not frequent enough to make an impact on behaviour. So whether you take Taylor’s opinion or Dan Pink’s, the point is neither of them are advocating for quarterly or yearly bonuses that 90% of the corporations still use.

• Hard work can only be achieved through uniform process definition and adherence.

Again, we now know that motivation has a huge factor on performance and hard work and that mastery, autonomy and purpose play a huge hand in intrinsically motivating individuals. This is not to say that process is bad, but intrinsic motivation is the trump card. Those who follow Agile believe in “individuals and interactions” over “processes and tools” because it is through motivated an connected teams that delivery teams best succeed. If you have to deliver work as a team, then you need to be a team and no process is going to solve deeply personal issues between two individuals.

• People cannot train or learn by themselves. A manager’s job is to define the process and train others.

People want to improve. They want to solve problems and get better as a person with a trade/craft. Forcing only one way of learning on them is quite limiting by today’s standards and again Dan Pink’s “Drive” book describes the importance of self-discovery of better ways of working to being a significant enabler to intrinsic motivation. Taylor made this statement because of the complexity of knowing the better way being unobvious to most people. In fact, they recommended getting the highest performers together and studying them to find the patterns of performance to find a new value stream. Experiments were run and then the value stream was further tweaked through constant refinement. Logic wise, it is hard to argue with the approach – amplify the patterns that are working. This is actually what happens in Agile as teams share patterns of success with others.

The step wrong that Taylor made was in thinking that there was no way to self-organize to find these patterns themselves. Modern management methods have just given us a set of tools for individuals in teams to share patterns and learn from each other without managers having to be involved in the process. That said, Lean strongly advocates for “Leaders as teachers”, is this very different?

• Management take over all the work that they are better suited to, specifically this includes all the work plan to deliver against (activities, and timeframes).

I have seen a manager once create a project plan for their team of fifty people to deliver it to. They did it overnight with their buddy. You can imagine how horrible that plan was. The project that ran against that plan was seven months late and twenty-five million over budget. Nothing ever runs to plan which is why in Agile the belief is “Responding to change over following a plan.”A plan is important, a plan that is responsive is better, a plan that is made with the people who are doing the work is best. If you don’t include people in on designing and adaptations of the plan then they don’t feel accountable for the outcomes.

• Principles of Scientific Management is all about individual goals and individual tasks.

It does this because it believes it is the most fair approach for people and organizations. It believes that herding and working as a gang is a bad thing (most likely due concerns to loafing) . This is probably acceptable for simple problems but for a complex problem where multiple specialists are required we need to find ways in modern organizations to have teams working successfully together. Because of the heavy focus on individual tasks, it could be said that Scientific Management seeks only resource efficiency and not flow efficiency like Lean does, but I think it is less about individual utilization and more about simplifying everything down to single piece, single person flow.

• Lastly, and probably most importantly, the Principles of Scientific Management is incredibly disrespectful in a number of instances to human beings. With comments like workers being stupid or idiots and “you do what you are told to do, when I tell you to do it, and don’t talk back”, it stinks of Theory X command and control attitudes. Respect for human beings is a significant pillar in most modern management methods.

Taylor’s writing is symptomatic of the era and time that it was written in – it faced problems that are different to ones organizations are facing today with attitudes that would easily get you fired by today’s standards. But everything isn’t rosy or wrong, so let’s take a look at the perspectives that need more discussion.

Could go either way

The following perspectives from the Principles of Scientific Management are worth discussing further:

• Underworking (deliberately working slowly to avoid doing a full day’s work) is the greatest evil.

Loafing is just one element of underworking. The more common type of underworking I see is apathy, where people either don’t care about what they do or are unengaged. The causes for this are simple, but solving it is less easy.

Firstly the purpose of the work could be disconnected from how a person perceives it, for example, an employee cannot see link to activities to the bigger goal, or they don’t believe in bigger goal, or their activities or the goal changed from when initially brought on board. Secondly, it is possible that there are interactions at work that have led them to feeling disconnected – either through struggles with other people or struggle with the system that they are doing work in. Thirdly, sometimes people have so much going on in their real life outside of work they just don’t have the cognitive space to give everything to their job during working hours. Whatever the reason, none of these should be considered “evil” attitudes.

• Managers should plan at least one day in advance, with written instructions, describing the detail of the task to be accomplished.

Detailed task instructions is pretty ridiculous in today’s modern corporation. A more modern approach is to set a clear goal and outcome and give people the space and support to get there themselves. What I do find interesting about this statement is the “at least one day in advance” bit. This suggests that Taylor’s take is that plans can be quite rapidly adjusted and just in time based. In Agile, teams plan in Sprints that are a week or up to four weeks planned in advance. Teams also do Daily Standups which is intents of a plan for the day for each individual (though this isn’t the key intent of a Standup).

• You should train and transition people into new ways of working by having an individually tailored approach, creating a new target state one person at a time.

This was one of the more intriguing statements to me. When we transition people into new ways of working, yes there is individual coaching, but we also tend to transition whole teams. It reminded me a little of the Monkey and Banana Syndrome, where a new norm is established one person at a time with little explicit expectation setting on how you are manipulating the people. It is important whenever you introduce new ways of working with people or teams that it is something that they want to try, but also, that the reason why is made clear to all involved.

Conclusion

It is not uncommon to hear from people implementing new ways of working statements like “That’s not Agile” or “That’s not Lean”. In a similar manner, the Principles of Scientific Management has equally suffered from poor application and consequently received a worse image than it probably deserves (Theory X style language aside). In a similar vein, Taylor also conceded that a transformation wasn’t a quick solution, but a multi-year journey, acknowledging that the human change element was one that would take the longest time. Interestingly, Taylor also recognized that transformations often took a pattern of being easier once one quarter to one third of the organization had made the change – this is more commonly referred to as crossing the chasm.

But has Taylor’s Principles of Scientific Management helped us or hindered us? The fact that so many of the beliefs are still valid suggests that it has been helping us, but I can’t help but think of the opening statement, that was Taylor’s cry for change, remains unresolved – our forests are still vanishing, our waters going to waste, the end of oil is certainly in sight. We still have people blundering, inefficiently working, often with little appreciation. The question is, is Agile and Lean or any other modern management method getting us further along – probably yes, and with more respect and connections to humanity, but not fast enough.

* Note: Whilst ‘Modern Management methods” is quite a broad generalization, for the purpose of clarity it includes the work from approaches, frameworks and concepts from Agile, Lean, Lean Startup, Design Thinking, Dan Pink’s Drive, Complexity thinking eg Cynefin/VUCA, David Marquet’s Turn the Ship Around, and Systems Thinking.

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.

Source: Opinion: What 2017 Has in Store for Culture & Methods

Source: http://www.infoq.com/interviews/agile2015-hamman-adkins-spayd