Good and Bad Reasons for Moving to Agile

There are various reasons behind moving to Agile. Some are proactive and some are reactive. Proactive motivations tend to be accompanied by a greater understanding of the business benefits of Agile and the culture change it implies. However, this is not always the case. The reasons behind the motivation can determine your chances to achieve a real transformation. Let’s take at a notional proactive-reactive model that looks at some motivations for moving to Agile and what you can do to enhance your chances of gaining the business benefits of doing so.  

• "It’s the trendy thing to do." Agile is popular, so we should do it. This is reactive and not a strong motivator for change. When another trend comes along, Agile may be abandoned. Agile may be seen as a hollow initiative and some may wait it out to see if it will go away. It will be important to investigate the benefits of Agile to see if it is right for you. Then determine if real commitment can be gained. 
• "The competition is doing it." Others are doing it, so we better do it. This is reactive. Although it may provide a driver for change, it does not provide clarity on why Agile was chosen. Some will question why what a competitor does is good for us. What happens when they do something else? It will be important to investigate the benefits of Agile to see if it is right for you. 
• "We need to reduce costs." This is a reactive and insufficient reason whereby Agile is seen as a tool to cut costs and maybe the workforce. This will not lead to the business benefits of moving to Agile. Although it may be an outcome, other benefits of Agile may be gained if you are willing to adapt the culture. 
• "What we have isn’t working." We’ve been using another process to deliver software and it isn’t effective. This is a reactive reason with little understanding of Agile, but it may provide an initial motivation for change. However, moving to Agile without understanding what it takes may lead to a failed deployment. It is best to understand the root cause for the failures in the past, because this can affect your change to Agile. 
• "We hope to increase employee morale." This is a proactive reason based on an understanding of the importance of employee engagement and empowerment to improve morale. Validate that there is real commitment to empowering employees and self-organizing teams. 
• "We hope to improve productivity." This is a proactive reason when the goal is to empower employees and help them improve productivity. The danger is that management may believe that Agile is something someone else must do to increase productivity or the real intent is to make employees work harder. The other challenge is that productivity may come at the expense of sacrificing quality. It will be important to investigate all of the benefits of Agile, not just productivity. 
• “We aim to decrease time to market.” This is a proactive reason in which Agile is seen as a way to shorten release cycles. If there is an understanding that this implies a change across the organization to get from market idea to release and it is meant to satisfy the customer, then this is a good starting point. It is still important to discuss the benefits of Agile to see if it is right for you. 
• “We want to deliver customer value.” This is a proactive and genuine reason if Agile is seen as a way to engage the customer and understand value. Validate whether there is a real commitment to delivering value and an understanding of the need to change organizational behaviors and processes to get there .
• “We believe in the Agile values and principles.” This is a proactive and genuine reason where Agile may be seen as a positive change in company vision and behavior. Validate a drive toward continuous customer engagement and employee engagement that can help gain the business benefits that Agile can bring. 

In all of these cases, you need to validate commitment to the values and principles and the culture and business change it entails. Once the initial motivation is understood, we can work to adapt it with the goal of better gaining the business benefits of going Agile.  

Hiring for the Culture of your Future

As an Agile Consultant, I occasionally help companies hire for talent as I’m transforming companies (e.g., an Agile transformation, business transformation, digital transformation or similar). When I’m helping with interviewing or hiring talent process, the interviewers circle back together to discuss the candidate. I often hear things like “They don’t seem to fit our culture”. Sometimes, there is a question built into the interview questionnaire asking, “Are they a cultural fit?”. 

When a company is satisfied with their culture, I can understand that you would align with the concept of hiring for cultural fit.  However, when you are working through an agile, business, or digital transformation, this implies that you are also transforming to a different culture with new ways of working. When you say “hire for a cultural fit” it needs to be to the new culture that you want.

For example, if the culture is more command and control where work is prescribed upfront, then the work culture tends to be very individual driven (I have been assigned my task and I will work on it) with little feedback is asked for (do the work and get it done by the deadline). If you are transforming to Agile ways of working, you need a much more collaborative and team-oriented culture where people are pairing up on tasks, helping each other, and where feedback is expected. Hiring for the former (command and control type culture) will not help you get to an agile culture of collaboration.  

If you are going through any type of transformation as a company, include a theme or work on re-evaluating the hiring process. Take a look at your standard interview questions and adapt them for the culture that you want. Also, describe the type of people that will fit your future culture (e.g., collaborative, team-oriented, etc.) and share this with the interviewers.  This will help embed your current culture with the people that will support the culture you desire for the future.    

Patterns of Resistance in your Agile Journey

Resistance is a common reaction to a change initiative. As organizations attempt to grow or improve, it must change. Change can occur for many reasons. When moving to an organization that is embracing Agile, there is often a need for a significant culture change since Agile is effectively a culture change.

Agile brings about a change in mindset and mechanics, which affects both employees and customers. Whereas change can create new opportunities, it will also be met with resistance.  Agile change really isn’t any different than any other culture change, ergo the resistance will have similar patterns.  There are many reasons for resistance. Here are some of the patterns:  

Here we go again! It is comforting when things remain the same. Employees have seen change efforts come and go without any true commitment and may attempt to wait the new ones out.

• What can you do?  The commitment to change must be clearly stated.  The change initiate must be treated as a program, with clear motivations and rewards for change.

Fear of the unknown.  Change is often defined by a journey into the unknown and it natural to resist what we don’t understand.  For most, it is unclear what the change will entail.  

• What can you do?  Leaders should provide a vision of what the new world will look like 

Lack of communication. Employees need to know what is occurring to them. As information trickles down from the top, the message can be lost.

• What can you do? Plan for continuous communications at all levels is important.  Include various communication channels and messages from as many champions as possible. 

Change in roles. Some employees like to retain the status quo and do not want to see their roles changed. When roles are vague, some don't know where they fit in the new culture, making them feel excluded. When they have no say in their new roles, they can feel alienated.

• What can you do? Discuss the role changes with employees.  Give them time to adapt to the roles or give them time to try new roles.   

Competing initiatives. Introducing an agile initiative when there are already multiple initiatives occurring can lead to employees feeling overwhelmed, causing them to resist. Hardly an auspicious start!

• What can you do?  It is important for management to prioritize initiatives and focus on the higher priority ones.

Change for people, not leaders. When asked “Who wants change?”, everyone raises their hands. But when asked, “Who wants to change?”, no one’s hand goes up.  This can be particularly true with leaders.  Leaders want change to occur within their teams but are not particularly interested in changing themselves and this may be been prevalent in past change initiatives.  

• What can you do? Acknowledge the change that the leaders must make and convey the leaders’ commitment to change. 

New management's need to change something. New leaders often feel they must show they are action-oriented. They may reason that the change that worked in their previous company should work here. Some know their term is short, so they are not interested in long-term change. Some are unaware of what it takes to affect culture. Employees who are used to this scenario may resist. 

• What can you do?  Avoid what may appear to be random changes.  Ensure the Agile change is aligned with better business outcomes and not just to do Agile. 

It will not always be possible to identify and manage all types of resistance.  However, it must be treated as a real and tangible activity.  It is better to start addressing resistance to change in a pro-active manner. The more you review and enact the "What can you do?" tips, the more likely you will increase your changes of a successful Agile change (or any culture change).   

Have you Crossed the Agile Chasm?

In 1991, Geoffrey Moore refined the classic technology adoption model with an additional element he called the “chasm.”[1] He advanced a proposition specific to disruptive innovation that there is a significant shift in mentality to be crossed between the early adopter and the early majority groups. Disruptive innovation is the development of new values that forces a significant change of behavior to the culture adopting it. In this case, Agile is that disruptive force that insists on applying a set of values and principles within a specific culture of “being Agile” to be successful and for the organization to realize the full business benefits of Agile.

At first glance, it would appear that many companies have adopted Agile. I believe, however, that this perception is specious, in view of the further observation that the majority of companies that are “doing” Agile have not actually adopted the new values and principles and not made the cultural shift to actually “being” Agile. Such companies look at Agile as a set of skills, tools, and procedural changes and not the integrated behavioral and cultural change it truly is. In other words, they think they have crossed the chasm, but they have not made the significant change of behavior required to make the leap.

My experience in the field leads me to posit a refinement on Moore's chasm concept as applied to Agile. First, there is the real Agile chasm between those on the left side who have made the organic behavioral changes consistent with the values of being Agile―and those on the right side who are just doing” Agile mechanically. Second, there is a fake chasm, which many organizations pride themselves on having crossed by virtue of adopting some mechanical features of Agile, whereas they have not been willing or able to make the behavioral changes and adopt the values required to cross the real chasm. Although many companies say that they are doing Agile in some form, a large proportion of these are actually doing Fragile ("fake Agile") or some other hybrid variant that cannot deliver the business benefits of Agile.

I cannot overstate this point: many companies and their teams are mechanically doing some form of Agile without having actually crossed the Agile chasm, not discarding the behavioral baggage that is keeping them from behaviorally and culturally being Agile. Until a team attains the state of being Agile, the business benefits that Agile can provide will be elusive. I contend that the industry has barely entered the early majority of true Agile cultural transformation, and many companies continue to struggle to leap the Agile chasm.  What have you noticed across the Agile landscape?  Have companies crossed the Agile chasm?

Note: If you are looking for more insight in crossing the Agile chasm, consider reading the book Being Agile. This book lays the foundation for those who want to cross the Agile cultural chasm, understand the behaviors that need to change, and gauge progress along the way. It provides an Agile transformation roadmap to the destination of achieving better business results.

---

[1] Geoffrey A. Moore, Crossing the Chasm (New York: Harper Business Essentials, 1991).

Are you Ready for your Agile Journey?

The common pattern in approaching an Agile implementation is to begin by conducting Agile practices training typically on Scrum or another Agile method.  While this will allow the team to begin mechanically applying Agile practices, it doesn’t address the culture shift that must occur, a culture shift that helps to inform the mind and shape behaviors, a shift toward "being Agile".  I term this approach of focusing on the cultural aspects of Agile as “readiness”. 

Readiness is the beginning of the process of acclimatizing the mind toward Agile values and principles and what they really mean.  It includes making decisions on the elements for your implementation. It emphasizes collaboration, customer centricity, adapting to the market, and more. Although it is important to lead with readiness, this framework may be used iteratively depending on whether you plan for a more holistic implementation or iterative deployment of certain elements.

This first starts with the premise that Agile is a culture change.  The implication is that Agile is more than a change in mechanics or learning a new skill.  A culture change is a transformation in belief and behavior that we learn our way toward value.  It requires a change by more than one person, and instead by a number of people within your organization.  As you can guess, this takes time.

Over the years, I’ve established what I term the Ready, Implement, Coach, and Hone (RICH) implementation framework specifically focusing on readiness activities that help you prepare not only to adopt the mechanical aspects of agile practices but more importantly, begin a meaningful transformation of behavior toward an Agile mindset. 

Readiness starts the moment someone asks the question, "Is Agile right for me?” The goal is to work through this question, understand the context, and figure out how Agile might be deployed. Essentially you are being asked if you are ready to be an adaptive organization who recognizes that customer needs and market conditions change regularly. Readiness can start weeks and even months before you really get serious about moving down the agile path. However, it can also begin when you are ready to commit.

What are some of the “readiness” activities?  These activities can help you shape the implementation according to the context and need of an organization. Readiness provides us with an opportunity to:

• Assess the current environment and current state of agility
• Lay the educational groundwork of agile values and principles
• Understand and adapt to self-organizing teams and away from command and control
• Shift the focus to delivering customer value and away from an iron triangle mentality
• Discuss the business benefits that agile brings
• Gauge the team and management willingness

Readying the mind should not be taken lightly. It is important to understand the ‘what’ and ‘why’ prior to discussing the how and when.  It is important that teams understand and really embrace the Agile values and principles.  Does senior management believe in the principles?  Do the teams feel they can operate in an Agile manner that aligns with the values and principles?  In fact, I dare say that if the team acts in the manner that expresses the Agile values and principles and forgoes the mechanical application of agile practices, then there is a greater chance that Agile will survive and thrive within a company and your company will more easily derive the business benefits that agile can bring.  

Since there is already an overwhelming amount of material that focuses on “how to implement Agile” from a "doing" perspective, may I suggest a different approach.  Provide the time to prepare the mind toward the Agile mindset and then incorporate this mindset into the culture, education, and decision-making process for your proposed implementation. With that goal in mind, let the readiness games begin!  How ready are you?

To read more about the importance of readiness and additional readiness activities in detail, consider reading the book Being Agile. 

Agile’s Little Secret – It Makes You Money

Agile tends to be introduced at the team level and it’s the Agile teams who are expected to adopt Agile.   While there is various amounts of buy-in from management, some don’t seem to understand that it takes an organization to embrace Agile in order to gain the business benefits.  In other words, management has a strong role to play including adapting their behavior, embracing the Agile values and principles, and leading a culture change, in order to gain the business benefits of Agile.  It requires significant buy-in to achieve a culture change.  But this doesn’t always seem to happen. 

Some of this is not management’s fault.  Part of the issue is that Agile gets introduced to them is various ways – as a way to improve productivity, as a way to speed up development, as a way to increase quality, but in most of these cases, those introducing Agile to them fail to mention the significant buy-in they need to make.  While each of these ways have different levels of merit, it often doesn’t convey enough of a reason for management to motivate a change in their behavior and their organizational culture.    

   

How about changing the message?  Though there are many benefits for going Agile, it occurred to me that to get serious executive/senior management attention and buy-in to Agile is to give them a reason that is near and dear to their heart.  Explain to your management that Agile can increase revenue—in short, it can help them make money (or more of it).  In my experience, this gets them to actively listen, versus the passive listening they may exhibit when they think Agile is an engineering method or something the engineering team and others must do.

Yes, Agile can lead to an increase in customer sales, ergo an increase in revenue. This is all true if the organization is truly allowed to “be Agile”.  This means that teams continually demonstrate working software to customers and they are allowed to continually adapt their requirements to customer needs.  Then teams can more closely align with what customers find as valuable.  The more value customers see in your products, the more likely they will buy (or buy more).  Maybe, just maybe, if you convey that Agile can make them more money, they will listen and buy-in to what it really takes.     

Benefits of Agile Coaches for your Agile Transformation

Many companies begin their introduction to Agile by trying it on a project or two.  If they believe they have ‘enough’ success with Agile, then typically more projects deploy Agile.  The challenge is that at some point the company is unclear on what level of Agile deployment has occurred and what type of Agile is really being adopted.  Senior Management may hear things like “we are Agile” and not really sure what that means.  Worse yet, because of the inconsistency of understanding Agile, some teams will say things like, “we don’t need to document anything because we are Agile”, other teams will say “we don’t need any management support because we are self-organized”, while others will say “we can’t tell you what we’re building until the end of the project because we are using Agile”.  Now what do you do? 

This becomes even more challenging when the company begins to realize the amount of effort they are haphazardly spending on Agile adoption.  Sometimes the company learns that they are spending twice for the same thing like training and/or tools and often overspending because they are not leveraging the volume discount strength of the whole company.  This is particularly relevant to medium and large companies.  

Whether you realize it or not, when you have multiple teams heading in roughly the same Agile direction, you have already embarked on an Agile transformation.  So the question is, do you want to let the change occur in an unorganized and ad hoc manner or do you want to manage that change in an organized way and gleam the most benefit from the effort.

I do not believe there should be a prescriptive way to deploy Agile.  However, there needs to be some way to ensure the teams are working on the highest customer value work. An enterprise level approach can help.  This ensures that the company reduces the muda (a.k.a., waste), leverages and reuses what it can, and ensures all teams are building the highest customer value work.      

When you find yourself in the situation where there are many in your company wanting to adopt a certain tool, process, method, and/or culture, or if it is already happening in an ad-hoc manner, it is highly recommended to initiate an organized approach to the enterprise change.  In Michael Spayd’s “Evolving Agile in the Enterprise: Implementing XP on a Grand Scale”, he recommends that an “effective Change team” is established.  In my experience, seasoned Agile Coaches and/or an Agile enterprise leadership team provides significant leadership for the change effort.  The Agile Coaches/Agile leadership team (aka, change team) provides the framework for the enterprise but still allows for adaptability and decision-points by the teams so they feel ownership of their working process.

The Agile enterprise leadership team should include talent that has experience in Agile enterprise change such as seasoned Agile Coaches and those who have organizational level change experience.  Some members can be matrix-ed in from internal organizations.  They should function as a team and can be distributed according to the areas within the organization that they will support.   It is often best to bring in either full-time regular talent or external long-term consultants to ensure that they don’t just make recommendations, but live through the challenges of the change as they help product teams, senior management, and others.

What are some of the benefits of Agile coaches and/or Agile enterprise leadership team?  This leadership can help you establish and manage the following: 

• Agile Vision - create a vision for where you can go.  A strong Agile coach has been to where you want to go. Without this experience, a company may never get there.  This may include a focus on the Customer to build the right thing and on the Employees to build the thing right" or similar.  By having a central Agile leadership team to focus you, you can better gain buy-in or at least get folks to understand why you are going in this direction.   
• Agile Transformation Roadmap - identify common activities to help a product team come up to speed with Agile.  This includes establishing a set of “ready for deployment” materials to help teams get ready for the change to Agile.  By having Agile Coaches help you, it will save time and effort from each product team having to figure out the adoption activities themselves
• Agile framework and practices - collaboratively establish an adaptable set of Agile methods and practices with the rest of the organization.  By having central Agile leadership coordinate this, it will save time and effort from each product team having to establish Agile methods and practices, although they will need to tailor them for their specific team. 
• Agile terminology – establish a common working language for Agile so that members from across the organization can communicate and interact effectively with each other.  By having central Agile leadership establish this, this reduces the miscommunication issues that will arise across the organization regarding various and sundry definitions of Agile terminology.   
• Agile training – establish a common set of Agile Training aimed at various levels of the organization (e.g., Scrum Team, Scrum Masters,  Product Owner, Middle Mgt, Senior Mgt).  By using a managed training deployment approach via the central Agile leadership team and education group, we will have consistent training and can get a better understanding of who has and hasn’t been trained.  By providing an in-house training approach, this reduces the cost of utilizing multiple vendors.  This increases common Agile understanding across the organization and product teams.
• Agile Communities – establish a common organizational Agile website with links to internal and external Agile communities.  Having the central Agile leadership team establish and support this, ensure that there is a managed approached to sharing online Agile related information and resources (framework, practices, etc.) across the company site that is kept up-to-date.    
• Agile Coaching - A key aspect of the leadership team is to provide Agile Coaching via the Agile leadership team to projects/product teams across the enterprise.  They may start with a small core of dedicated Agile Coaches and then can leverage existing Agile talent across the enterprise in establishing an Agile Coaching Circle.  Coaching significantly reduces the effort involved with “correctly” getting a team to adopt Agile and more importantly ensures they do not regress into their old traditional habits. 
• Agile Adoption measures – establish a common and reasonable set of adoption measures to see what progress is being made in the Agile adoption within the company.  By having the Agile leadership team manage this, we have common adoption measures to ensure that the leadership team and product teams are meeting the organization objectives for Agile adoption.  Senior management can more readily get a pulse of the Agile status across the organization.
• Agile Challenges Point of Contact (PoC) – establish a central point to manage Agile related challenges and issues.  This would include website, email PoC and the establishment of an Agile FAQ.  The benefit to having a go-to centralized Agile leadership team to manage this is that they can both become aware of these issues and then resolve the issues and challenges before they cause an impact.
• Agile Vendor Liaison PoC – utilize the Agile leadership team to become the PoC for managing the company relationships with the various Agile vendors.  By using a central Agile leadership team ensures that the organization or company is gaining the most leverage from the volume discounts and negotiations for Agile related materials and tools.  

Finally, when employees within a company see that many are going Agile, sometimes it is comforting to see that the organization is providing support in the adoption effort.  It is even more comforting when those employees that haven’t yet gone Agile see that there is ready support for their deployment.   It is particularly problematic when the employees are seeing wide variations of “agile” being deployed some of which is not really Agile, and they wonder when the organization may provide some guidance in this matter.  Introducing Agile really is a culture shift.  If you are thinking about adopting it or already are, then it can be a benefit to have Agile Coaches and/or a centralized Agile leadership team to help you navigate to a success adoption of Agile.  

Good luck on your Agile adventure!

Note: this was originally written in 2008 with minor updates in 2012.