Making an Agile Adoption Stick

April 22, 2011

Studies are demonstrating that the most significant barriers to further Agile adoption are:
  • The ability to change organizational culture
  • General resistance to change within an organization
  • Management
(VersionOne State of Agile Surveys, 2008, 2009 and 2010)

My last post discussed the need for educating and garnering management support as key ingredients to improving the odds of success of an Agile adoption. In this post I’ll cover a few techniques that can help to smooth the Agile transition and make it stick (with a Scrum bias, since that is what we use). And if Agile is going to take, people have to truly understand what it is, agree to changing behaviors, and continually apply themselves to learning, inspecting, and adapting.

Working Agreements
Why keep these at just the team level? This is especially true early on, when everyone is getting used to Agile and breaking some old habits. We didn’t do this, but we did incorporate elements of this into our "Agile Expectations" document (covered next). I don't see how it would hurt to establish a simple agreement between an Agile team and management.

Management commits to…
  1. Staffing the team with team members who have the appropriate skills to make the project successful.
  2. Assisting the ScrumMaster in the removal of impediments to maximize its progress.
  3. Making subject matter experts available to the team when those experts are needed.
  4. Allowing the team to be self-organizing, respecting the autonomy of the team and the Scrum roles along with the boundaries of those roles; management will not assign separate duties outside of the team goals to team members, nor will management direct the team in its work or change its priorities in mid-sprint.
  5. Investing time and money in reading, providing training and/or professional coaching, and participating in discussions geared towards continuous improvement and building a greater understanding of Agile development so that the company enjoys greater business success.
The team commits to…
  1. Working as a team to deliver quality software at the end of every sprint, demonstrating this software to key stakeholders.
  2. Making progress visible by using “information radiators” so that the team can manage its work and stakeholders understand the team’s progress.
  3. Raising impediments to management that are truly issues outside of the team’s control to resolve so that action can be taken to maximize the team’s progress.
  4. Listening to the input and concerns of stakeholders and working with them to address those concerns in an Agile/Scrum context.
  5. Investing time in reading and participating in training and discussions geared towards continuous improvement and building a greater understanding of Agile development so that the company enjoys greater business success.
Both management and the team agree to live by and support the values and principles of the Agile Manifesto.

Conduct an Exercise to Set Expectations
Agile development is change, and getting everyone on the same page about change is never easy. Different people have different perspectives, and those perspectives can differ radically when people at various levels of the organization are involved. It helps to develop a common understanding to avoid painful problems later.

We conducted an exercise with our management team early on in our adoption of Agile development. I crafted a working document that I called “Agile Expectations” that our management team collaborated on over a period of a few weeks, outlining the key expectations that everyone had about Agile development as well as the key benefits that we hoped to obtain.

The document produced as a result wasn’t dramatically different from any other Agile literature out there, but that wasn’t the point. The point was to get the management team involved – thinking and talking about Agile development – to develop a common understanding and appreciation for what it meant to be Agile. It was definitely better to work through this early on versus contending with conflicting and counter-productive behaviors later.

Working Groups
Agile development is a gradual change, with most organizations starting small and building into it. Working groups can be established to share experiences and drive changes required to support Agile development. Managers in particular can make a significant impact in this regard.

As we gained experience with Agile and it was adopted across our development organization, we began by examining our performance management process and determined that aspects of it ran counter to Agile development. (We also determined that other parts were cumbersome, and that this was an opportune time to advocate for change.) For example, Agile development must be a team first, individual second mindset. Individuals shouldn’t have SMART goals that essentially place expectations and work on individuals that impact the ability for someone to fully engage with his or her team or (in the worst case) run completely counter to the goals of the team that an individual is on.

We created a working group of managers to focus on these issues and eventually drove change that simplified our performance management process. Likewise, some of us got together to work through what it meant to be a manager in an Agile world, and what types of competencies Agile managers must have in order to be effective.

I’m sure that you can think of other options, but continued and successful Agile adoptions will need a common understanding, conversation and collaboration across the enterprise. Agile development doesn’t just affect the project team, there are implications that reach deeper into the organization.