Tackling the Cultural Shift Towards Agile

Here’s some food for thought: chances are, if you are practicing Agile, it’s becoming one of your primary processes for software development.

According to the State of Agile Survey 2013 from VersionOne, over half (52%) of companies surveyed use Agile for 50-100% of their projects. That’s pretty substantial, especially considering what it takes to train an entire organization on a core business process. The need for Agile adoption and understanding by most of the key stakeholders involved in these projects is becoming even more important.

But how do you change an entire company’s mindset? How do you create that cultural shift to Agile? That’s where the challenge lies.

The respondents in VersionOne’s survey who came out as the champions of change for Agile were management at the top (63%), Dev or IT staff (17%) and lastly executives (8%). This means your direct managers are going to be the ones who spearhead the change for Agile in your organization. In order to help guide you on the path to cultural change, this article will address the roles of ScrumMasters and Agile Coaches in facilitating this change. We’ll also talk about the hardest habit to break in a traditional team, and ways to lead the team to ownership using the ABO Continuum.

The ScrumMaster and Agile Coach – The key to the cultural shift

Depending on the size of your organization, you will have someone on your team who is knowledgeable about Agile and most likely has been trained in its processes. For smaller organizations this will probably be your ScrumMaster. At larger organizations you may have a dedicated Agile coach who is training a group of ScrumMasters and other key stakeholders.

Both of these roles act as the champion and caretaker of the Agile methodology. They are there to help guide and build Agile processes and Agile teams. These are the key players who will never write a line of code or document requirements for tests or features, but their role is critical to developing software.

ScrumMasters and Agile Coaches typically do the following for the rest of the team:

  • Help the development team track true status
  • Encourage the automation of redundant, repeatable tests
  • Mentor the team on Agile processes and demonstrate their value
  • Help the team break work into small chunks that can be delivered quickly
  • Ensure that work being delivered is in tune with customer needs

These aren’t formal, direct managers. Instead, their form of leadership relies on influence and collaboration. The ScrumMaster or coach will leverage the respect they earn from the team as they establish a history of working together on projects. This is vital in order to create change in your company. Executives who decree that development teams become Agile will likely struggle with success, meeting resistance from IT teams. The ScrumMaster or coach acts as a champion, siding with development teams, and fostering an Agile mindset in order to prompt change from within.

The Hardest Habit to Break: Planning

One of the most difficult habits a ScrumMaster or Agile coach has to break when working with a traditional software development team is the idea that you have to plan everything. Typically, the work of identifying features and specifying requirements is conducted up-front, exhaustively. Usually a project manager wants to address every possible question in the specification before development begins, so that the work will not be interrupted by a missing requirement.

In Agile planning you want to plan “just enough.” You determine which features you want to build in the near-term, and produce just enough code to demonstrate the feature to the customer. This allows developers and testers to work on just enough to get the job done right, cutting down time and resources.

The difficulty in this form of working is, of course, the uncertainty. It’s hard to answer “I don’t know” when your CEO asks, “What are we going to launch next summer?” However, given that most waterfall projects are delivered late and overbudget, perhaps “I don’t know” is just as accurate an answer.

The ABO Continuum – Use It to Embrace Change

In 1998 Arthur Andersen published, “Best Practices, Building Your Business with Customer Focused Solutions.” One of the best solutions outlined was the ABO Continuum, which identified the vital elements required when introducing change in an organization, and how to ensure ownership of that change to make it happen.

The continuum outlines three major phases an organization will go through when making changes:

1. Awareness

In the awareness phase information about the change is shared among stakeholders early and informally. For example, the Agile champion could mention to the team that executives are discussing improvements for the development process and ask what the team thinks about this.

Every individual has their own timeframe for evaluating a change. Some will adapt quicker than others. The earlier you make the team aware of a potential change the better your chances of getting them to “buy-into” the change when it is happening.

2. Buy-in

In the buy-in phase you begin implementing the change. Awareness has already been created and you are looking for the team to consider the change and use it. This is where the team will see the value of the change as a positive and accept it.

3. Ownership

In the ownership phase, the team has tried the change, begun to believe in it and adopted it as a standard practice. They do not need management to encourage them to use it. They believe in it and will use it without being prodded.

These three phases can be applied and used for the roll out of an Agile methodology. This continuum will allow executives and employees alike to embrace change and make Agile processes more acceptable across the board.

Change takes time

Agile adoption won’t happen with a wave of your magic wand. There is no set timeframe that dictates how long it will or should take until your team is truly Agile. Each individual has their own way of coping with change so there will be mistakes. Be forgiving and allow frameworks and processes to take shape organically. However, when you feel like you are getting there, be sure to look at these signs to know if your team is truly Agile.

Leave a Reply

Your email address will not be published. Required fields are marked *