Change Is Scary

Understand the Emotional Impact of Change On Your Team

Change is scary no matter how you look at it. Uncertainty about what is next elicits so many levels of emotion from excitement to fear but when you get down to the core, there is one simple question most people want the answer to… How will it affect me?

Agile is a permanent state of change. Iterating is an active process of change, moving things closer and closer to a desired state of being. A great way to approach projects, processes and features but people do not change and grow this way so many are not comfortable with it; what can you do to help? In your role as Scrum Master, Product Owner, Manager, CEO, Team Member, engineer, whatever your role, you need to acknowledge that there can be an underlying fear of change at the most basic level for every person who is part of the Agile transition, a fear that may impact your Agile progress. The best thing you can do is NOT ignore it!

When I read the definition of “Fear” as a noun from the Merriam-Webster Dictionary it reads as follow:

  1. an unpleasant often strong emotion caused by anticipation or awareness of danger
  2. anxious concern : (solicitude: the state of being concerned and anxious)

The words that leap out about are “unpleasant,” “anticipation,” “danger,” “anxious,” “concern” – all words that would make me question what they heck is going on and how do I protect myself.

During the transition to Agile, or even in environment that has been doing it for a while, each iteration, each release, each tweak, provides an opportunity to improve things, change is the norm.  If acknowledged and accepted as part of the transition, it also provides a way to allow every individual member of the team “iterations” to get comfortable with change overtime, to better manage their reactions to it based on the type of personality they have and the way they work. Think about it; as you are trying new things, part of you wants to slide back to what you know, to the familiar, the new can be scary. Writing user stories, estimating, pivoting, all caught up in the Agile process, then suddenly you have a wistful moment when you remember how it USED to be (even though it did not work) and you are tempted, tempted to return to what is familiar… change is hard and moving from a linear process to an iterative process is not just about the doing;  it is about the thought process.

As your Agile transition starts, there will be the traditional resistor to change (what we do now is good enough), those that have had bad experiences with Agile in their past (insert war stories here about how bad it was), those that do not want their processes to change (they know them!), those that hate process… the list goes on. These are the folks that are actually the easiest to work with and move forward because their fears are rather simple in their source and working with them through the issues is a matter of time rather than a more systematic change at the business level.

There are things outside of your Agile processes that affect the project and the team that you will need to address because, if ignored, may hold your progress back in ways you do not even expect or suspect. Agile success requires the right environment and culture to prosper and this may mean making changes in a variety of different areas to find the right mix. Fear can be the key component in many of these issues. You need to dive into the people aspect of Agile and see what might be causing your team members fear that you may not even be aware of.

Agile changes many of the traditional ways people have worked together – encouraging conversation, how to approach the work, providing opportunities for open examination of how things are getting done and investment by those doing the work. While these are amazing statements there is one problem, people doing all of this are still people with all their core flaws, fallacies, preferences, stresses, personalities and habits. Some will wonder how to take all of that “soft stuff” out of the equation? Well you don’t! I am not going to pretend this does not add to the challenges of doing Agile but in truth it makes the success of Agile that much sweeter and much more powerful.

Where to we start?Accept that everyone reacts differently to change and it is outside your control but not outside your ability to influence.

Some of the best ways to address the people element is to ensure there that things like position descriptions, reporting structures, review processes and rewards, to name a few, are NOT left out of the Agile transition. You cannot build the most powerful aspect of Agile, a high performing team until you accept that every high performing team starts out as a bunch of individuals who come to work every day, want to know what it takes to get a raise, what does it mean to be doing the job, how to get that promotion, and finally, what is a paycheck looks like with their piece of the “team success pie.”

Take the time to think through how a transition to Agile will impact the individuals on the most basic level. Ask yourself:

  • How does the transition to Agile change their position description? Update it to reflect those changes and communicate the changes to each individual.
  • Does the individual have a traditional role s such as IT, Operations, Architect, Art Director? Does Agile change what they do and how they do it? Work with them to determine what an “Agile” version of that position’s responsibilities now looks like.
  • Do you have Agile Review Goals for that individual that align with Agile success metrics for the team and the project? Take the time to figure out how those review goals need to be updated to reflect an Agile and team based mindset, not forgetting they are still for an individual.
  • How is feedback gathered on an individual when they do most of their work with a team not for an individual manager/boss? Review feedback may need a radical change with a blend of team-based and direct manager viewpoints to best reflect the strengths and weaknesses of individuals covering Agile and discipline-base elements.
  • How are promotions, bonuses, and raises handled when team delivery and success is an Agile standard? You can’t promote the entire team, so consider the team’s performance and the contributions of the individual to that combined success.
  • How are a Manager’s day-to-day responsibilities altered when all of their direct reports (based on an org chart) get their marching orders from the team they work with not the person they report to? Org charts and reporting structures may need an Agile transition of their own.

This list includes just some of the business elements that can help improve the transition to a more Agile environment and culture.

Agile success is measured by the team getting things done but at the end of the payroll cycle, the team does not cash a paycheck, an individual does. As with the Agile process, you need to be open and communicative, make sure they know not only what Agile success means for them and how they will be measured but how they are going to be rewarded AS AN INDIVIDUAL.

Leave a Reply

%d bloggers like this: