Category Archives: Coaching

7 “Easy” Steps For Convincing Senior Management to Support a Hard Change

Puzzled manager

We’re often asked how do you convince senior management to accept new agile ideas and strategies.  Examples of such ideas include:

Why is This Important?

There are three reasons why it’s important for agile coaches, and Team Leads/ScrumMasters for that matter, to know how to convince senior management to support new ways of working:

  1. You need their support.  There are many aspects of an agile transformation that an agile coach doesn’t have the authority nor the resources to change.  As a result you need to collaborate with others and very often earn the support of the people who do have the authority and resources.
  2. Agile transformations are complex.  Agile transformations are about more than just transforming software development teams.  The 2016 Agility at Scale study found that 96% of agile teams need to collaborate with other teams external to them to get their job done.  The implication is that these other teams that they are collaborating with – including your business stakeholders, governance team, data management, internal audit, security group, and many others – need to at least be able to interact with your agile teams in a reasonably flexible manner if not work agilely themselves.
  3. Agile transformations are fragile.  If you want to transform your IT department, and more importantly your organization, then you’ll need to transform all aspects of the department/organization.  All it takes is one or more groups to refuse to work in an agile manner and suddenly your transformation is at risk.  The implication is that you need to get good at convincing others to support your efforts if not change themselves.

Why is This So Hard?

There are many reasons why senior management may be reticent to consider this change that you believe to be very important:

  • They have other priorities that you may not be aware of.
  • They have many other issues to deal with, this is just one of them.
  • They may be very happy with the status quo and don’t recognize the problem.
  • There are other people advising the exact opposite.
  • There are people who are entrenched in the existing way of working, and that may include senior management.
  • They will need to convince their peers regarding the benefits of the change and they may not know enough to be able to do so, or may not have the political capital to effect the change.
  • Change can be disruptive and it may jeopardize their existing commitments which incidentally might be tied to their compensation plan.
  • The manager realizes that this change has greater ramifications than you may believe.

The Seven “Easy” Steps For Convincing Someone to Support Change

Here is an approach that we’ve had work in practice for us.  You will very likely need to work through all of these steps, pretty much in order, to be successful.  These steps are:

  1. Pick your battles wisely.  Ask yourself whether this issue is the most important thing that you need help with from this person.  There will be only so much willingness to invest time and effort in supporting the changes that you believe to be made, and not all requests are going to be supported.  As Rod Bray, CDAC, likes to say: “Choose the hill that you’re willing to die on.”
  2. Know the topic and the language around it.  Chances are that you will need to be able to explain whatever it is that you’re asking for help on, what the trade-offs are, why its better than the current approach, and what the impact of the change will be.  To do this you will need to understand the trade-offs are of the current approach and understand the issues and language of the topic.  For example, if you’re asking for help to change the way that IT projects are funded, are you able to speak intelligently about the existing annual-based budgeting process, project-based funding, and perhaps even the implications of CAPEX/OPEX?  Or, if you’re asking to improve the current approach to IT governance, do you understand the existing governance process, what it’s trade-offs are, and what the potential impacts of applying traditional governance to agile teams may be?  If you don’t have this fundamental understanding of the topic then you will very quickly sound like you don’t know what you’re talking about, so why would management want to support you?
  3. Plan the conversation.  Although you very likely have some very great ideas, if you spring them on others they will very likely be threatened by them at first (human beings are psychologically wired to treat surprises as threats).  A better approach is to first ask permission to discuss a new idea that you have, and even share an overview of the idea beforehand so that they can think about it a bit, before you get together to seek their support.
  4. Explore their concerns.  Once you’ve pitched your idea to them they will very likely want to discuss the trade-offs with you, in particular the impact on other groups and the time and effort required to support your change.  The implication is that part of your preparation before you make your pitch should be to think about what concerns they may have with your suggested approach so that you have arguments to counteract any concerns.
  5. Ask them to share their actual experiences.  It is very common for people to become attached to ineffective ways of working.  This sounds strange on the surface, but people are like this.  Whenever we run into someone who believes in a strategy that we know to be ineffective – fixed price funding, documentation-based governance, detailed up-front modeling, significant amounts of manual testing to name a few – we ask them how well it’s working for them in practice.  Very often they’ll tell you about the positives, but if you know the topic (and better yet the history of that strategy within your organization) then you can start exploring the negative aspects with them too.  It’s particularly useful to be able to bring up several past projects where that strategy was applied yet it didn’t work out so well in practice. The point is to help them to recognize that their favored strategy isn’t working as well as they’d like, and that there is a need to rethink your current approach.
  6. Educate them.  Walk them through the trade-offs, both good and bad, of your suggested approach.  Be prepared to discuss the trade-offs of the current strategy, and in particular relate those trade-offs back to the experiences that they just told you about.  You may often discover that they didn’t realize that there are other options available to them and that they’ve been ignoring the problems with their existing approach.  Help them to understand that they have a better choice available to them.
  7. Convince them to run a small experiment.  Making a large, whole-scale change is scary.  If the new approach doesn’t work out then you’ve got a serious problem to deal with and the manager who sponsored the change may be punished for it.  But, running a small, contained experiment to see if the new strategy works in your environment isn’t very threatening and better yet is a fundamental risk management strategy.  So start small, get a visible win, learn from the experiment, and the roll out the change more widely.  It is important that you “negotiate” the changes as they will be more likely to try it if you let them know that the change is an experiment and they will have the opportunity to revert back if the expected benefits do not materialize.  Note that some organizations are leery of running “experiments” but are very willing to run “proof of concepts (PoCs)” – go with the terminology that works in your organization.

We wish that we could tell you that we’ve had a 100% success rate with this strategy.  Sadly we haven’t.  We have done very well with this, but sometimes it doesn’t always work out the first time.  Or the second time, and sadly sometimes not even the third time.  Your goal should be to get them thinking about new ways of working and to give them the time that they need to decide to support you.

Agile is supposed to be easy, right?

The Agile manifesto is only 4 lines, there are only 12 principles for agile software and the original Scrum Guide was less than 20 pages, so how hard can Agile be?

 

Chess has only a couple of dozen basic moves so how hard can it be to get to checkmate?

 

 

How many times have you heard?

  • All you need to be Agile is to get the team doing a few funky ceremonies

Or the approach to evolving a team from forming to performing:

  • If the team isn’t performing after a month then the manager is not effective.

Despite the apparent simplicity of Agile, transforming to Agile is hard and the learning curve is very steep.  Depending on the team and the individuals, a transformation from waterfall to a high performing Agile team can take anywhere from 6 months to a year or more.  That’s not to say that they won’t be productive over that period of time.  In fact, they will start delivering business value at the end of the first iteration, but the team will be in constant growth and development over that period of time because not only do the people have to learn a new process, they also need to learn a new way of thinking as well as a new way of working as a team.

1.0 A new process

Aside from being excited to work with the thought leaders in the agile world, the reason I joined with SA+A is because of the Discipline Agile Delivery (DAD) decision framework and the way it captured all the tough stuff that I had been wrestling with for years.  With many years of experience building agile teams, I considered myself somewhat of an expert with answers to a lot of the difficult questions.  When I reviewed the DAD framework I realized that the answers I had gained from my own personal experience would not apply in all circumstances or for all teams.  Context counts.  The DAD Agile/Basic and Lean/Advanced project lifecycles have three phases: inception, construction and transition.  Each phase has a collection of process goals, and each goal encompasses several process decision points.  And, each decision point has a collection of options to choose from.  These process goals, decision points and options have been empirically assembled by analyzing many agile teams to see what makes an agile team successful.  This framework gives a team the ability to define a process that works for them.  Is this difficult to do?  Absolutely!  Defining a process to use is always difficult. BUT…..  The framework provides some guidance. Each goal option has default options that the team can use to get started and the options are listed in preference order so the team can easily pick an initial option.  As the team evolves and matures they can chose the more advanced options and evolve and mature their process.  Does the framework include all possible options?  Definitely not, but the options are certainly extensive.  The framework has evolved over time and continues to evolve as the coaches and thought leaders gain more experience and work with more diverse teams.

No matter which lifecycle the team has chosen to use; whether the team is using classic Scrum (Basic/Agile) or Kanban (Advanced/Lean) or a tailored process created using a framework such as DAD, the team is going to need practice and discipline to get it right.  That means, executing the lifecycle, doing periodic retrospectives, updating the process and then repeating again and again until they get it right.  Changing behaviors is hard and the team will struggle to be successful.

2.0 A new way of thinking

No matter how you cut it, transforming to Agile is a cultural change and culture changes are hard.  Not only is it hard for those who want to make the change but almost inevitably there will be pockets of resistance from people are happy with “the way we’ve always done it”.  Unfortunately, political infighting is the biggest risk to innovation. It is going to happen, you may as well brace yourself for it.

The roles are changing from traditional roles (such as: developer, business analyst (BA), system analyst (SA), quality assurance (QA) and project manager (PM), to new unfamiliar roles (such as: product owner (PO), team lead (TL), architecture owner (AO) and team member).  The traditional roles may be deeply embedded in your HR hiring and performance review processes. Transitioning to the new roles will require a realignment of skills and abilities that is bound to cause great consternation amongst the team members.  Often this is a very difficult transition for project managers, in particular, because they find that a lot of the traditional tasks (i.e. work breakdown structures, planning, estimating, etc.) are now the responsibility of the whole team.

The team needs to start thinking in smaller deliverable pieces.  The concept of delivering a complete system from known specifications at the beginning of the project has been the fallacy of traditional development.  The cost of delaying delivery to the very end of the project and the lack of ability to meet actual customer needs can be eliminated by delivering minimum functionality early and augmenting with new and improved functionality iteration after iteration in close collaboration with the end customer.  But moving to this model of continuously delivering can be a tough adjustment for developers.  Even (or maybe especially) for seasoned developers, the concept of starting to build and deliver not knowing all the detailed specifications up front can be very unsettling. Getting comfortable with this model takes time and experience before developers cease to fall back on old behaviors.

One of the pillars of agile is complete transparency with the business and the stakeholders into the team, the process they are using and the delivery of the business functionality.  With the business embedded in the team on a day to day basis and iteration reviews to demonstration and approve all the deliverables from each iteration, there is no hiding problems when they occur and no hiding late deliveries or failed iterations.  On the flip side, the business is there to celebrate the wins and recognize the deliveries at the end of each iterations and they are part of determining the velocity of the team and adjusting the schedule to match the velocity.

The new way of thinking also requires new tools.  Tools that can build dashboards to automate and display the development intelligence metrics that provide transparency into the team’s performance.  Tools that automate configuration management, continuous integration and continuous integration as well as automated testing.  All of these endeavors are hard and required skilled individuals to lead; none of these comes for free.

3. A new way of working with others

More people skills are required by everyone.  People are now going to be working much closer together physically and will be interacting and collaborating on a much more frequent basis.  Experience working together (often for many years) may give an advantage to some team members, however, they still need to learn how to work together as a team.

3.1 Team Development Phases

Tuckman’s team development model includes the phases: forming, storming, norming, and performing. These phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.  The number of iterations required to move through the phases will vary by team depending on factors such as: company culture, skills, experience, familiarity with each other, leadership (or lack thereof), external influences and coaching etc. Teams may also plateau in a phase before entering the next phase.

Agile teams will go through the four Tuckman phases:

  1. Forming. All teams will go through the forming phase. Typically this take 4 to 6 iterations for the team to: understand the lifecycle process, understand how to work together, understand what the team goal is, and most importantly to get comfortable enough with each other to risk the possibility of conflict.  During this phase, the team’s velocity will vary considerably especially for the expected failed iterations although there should generally be a trend upward in the velocity.  Retrospectives in this phase tend to be very cordial and factual because everyone is avoiding conflict.
  2. Storming. The storming phase can be very upsetting to both the team members and team managers. Often managers will step in to solve the storming issues without realizing that it is a necessary phase for the team to work through on their own.  Conflict, disagreements and personality clashes must get resolved before the team can move to the next phase.  Unfortunately, this phase is a make or break phase and it is hard to predict just how many iterations it will take but it is not usual to expect 3 or 4 pretty rough iterations.  Some teams will completely disintegrate during this phase and it is certainly not unusual to have a decrease in velocity during this phase.  Some members of the team may find they have basic incompatibilities and need to move to another team and this change in team membership can revert the team back to the forming phase.  The retrospectives tend to be very interesting and intense during this phase as they deal with the inter-personal issues of the team.  You can pretty much expect that there are going to be some hurt feelings no matter how safe an environment you have.
  3. Norming. The norming phase is when the team comes back together stronger and more cohesive for having weathered the storming phase. They have resolved their issues and have developed a new synergy where the team just “works well together” and it is fun to be part of the team. The team velocity should trend upward and then level off as the team hits its capacity consistently.  With the new-found synergy of the team, the retrospectives can focus on process improvement and optimizing the operation of the team with the hope of transitioning to the performing phase.
  4. Performing. The performing phase is the goal for all teams but very few actually get to this phase. Not all teams can get to the high level of performance of a Special Ops team where each member knows exactly what their team mates are doing and what they need to do to work as a cohesive unit.  A team in performing phase no longer needs a coach or supervision but can operate autonomously and efficiently.

3.2 Team changes everything

With self-organizing teams, decisions are now made at the team level rather than at the PM or manager levels.  This can be a difficult transition for both the team members and the managers.  Team members are often use to others making the decisions for them and wait for decisions or are reluctant to make decisions.  Managers often feel disempowered when decisions are no longer in their hands because the decisions are made by the team.

The team still has the responsibility to do the traditional activities such as; analysis, design, development testing and deployment.  However, under the new model, the team also takes on the inception responsibilities of: developing user stories, sizing the stories, estimating the stories, creating the product and architectural vision, and developing the release plan.   During construction the team also has to: plan the iteration, do look ahead planning, and have an iteration review (i.e. demo) with the stakeholders.  To keep the team working together they need to have the daily coordination meeting (i.e. Scrum) and to keep the team growing and evolving of course they need to do the retrospective at the end of each iteration.

Thinking, analyzing, planning and building just-in-time is a new way of thinking for a traditional team.  The inception phase in particular can be a difficult adjustment.  Designers and developers are used to doing all the analysis and design upfront.  Doing just enough analysis to be confident of a solution and then writing the user stories to do the work and build the plan is a difficult transition.  Writing user stories so they can get started and learn as they go is a very difficult transition.  Building just the simplest framework and then adding required features and functionality as needed requires practice, training and reinforcement.

There is much more focus on delivering quality because the team is responsible for development, delivery as well as product support.

4.0 The Bottom Line

Chess has only a couple of dozen basic moves and so it is simple to learn the basics.  However, after 3 moves there can be several billion moves available making it so complex that it can take a lifetime to master.  Transforming to Agile is a lot like that.  It looks very simple on the surface but under the covers it can get very complex very quickly.  That’s where the value of a good coach comes in.  You need a coach who brings a lot of experience to the table who will be open and honest with you about what needs to be done and how to get a successful transformation.