Enabling Agility

Archive for the ‘Deciding to Use Agile’ Category

If you are an Agile evangelist within a company, you probably spend (or will spend) a fair amount of time talking with people across you organization about Agile and its benefits.  When I was in this role I ran into a full range of responses from heated skepticism to full embrace.  Having the opportunity to talk with hundreds of people provided me with a wonderful laboratory to see what worked and what didn’t.  Here are some of the thing I learned.

Understand and Speak to your Audience’s Frame of Reference

I found that I was significantly more successful, unsurprisingly, when I put more of my attention on my audience’s perspective than my own.

When you are talking with a group about Agile, the people in you audience have probably worked hard to get where they are, and they have a level of pride and attachment to who they’ve become.  Almost involuntarily, they are comparing what you’re telling them to their view of the world to see if it fits.  If you are not speaking to them with an understanding of their issues and values, you may not be very successful.

You’ll be particularly unsuccessful if you directly threaten their position in the organization and the things that they value.

(click to view full size)

Here’s another example.  Imagine you are speaking to a group of mid-level managers about Agile and you say:

“With Agile, it’s all about the team.  Self organizing teams who determine their own work process.  We break down the rigid silos and get much better results.”

My guess is they’d be threatened, think you are dangerous and would trying to figure out how to get you escorted out the door.  You’ve practically said “sorry, what you do isn’t valued, there’s a new way that’s better.”  Not the result you were looking for.

Here’s an alternate approach.

“Organizing work in a complex organization is a challenge.  As a group we’ve risen to that challenge effectively in the past.  Yet we’re in a recession and we’re being asked to respond even more rapidly to a constantly changing world.  There’s enough evidence to indicate that Agile may be a powerful new process for our company.  It is an uncertain path.  We don’t know if it will work for us and what the long term implications are for our structure.  But we’ll take one step at a time.  We’ll experiment thoughtfully, discuss the results together and collectively decide how to proceed.”

There are a few important things here:

• You are acknowledging them for what they’ve contributed to the company.
• You are honest about the uncertainty.
• You’ve let them know that they will have a role deciding how to proceed in the future.

Before you make your pitch, think of the people who will be in the audience an how your message might be received.  Do your homework first.  Figure out in advance which people in the audience are most likely to help or hinder your cause, and set up some time to meet with them individually whenever possible.  In these individual meetings, listen a lot and talk very little.  Find out what is important to them, what they know about Agile, what they think it might offer and what concerns them.  Use that to shape how you talk with the group.

When something comes out of someone’s mouth that sounds like an objection, consider this important data.  If you don’t effectively address the concern, you might not get the opportunity to proceed.

Cognitive scientists have demonstrated that 20% of what you hear comes from the other person and 80% is what you fill in with things from your own perspective.  You are at an enormous disadvantage when you are really trying to understand what another person has to say.  But understand you must if you want to be an effective change agent.

Have Room For Your Audience to Say Yes or No to your Proposition

My preferred approach to discussing Agile with a new group is to let them know clearly that they are in charge and that any decision they make is up to them.  I describe the challenges that other organization have seen that have led them towards Agile, and then ask if they face the same challenges.

If some items resonate, they’ll usually want to talk more.  If a lot of things resonate, they may ask how they can proceed.

This I found to be far more effective than attempting to sell Agile.  When the only answer I’ll accept is “yes”, my audience’s instinctive reaction has be to try to protect themselves and we end up in a tussle.

For this process to be effective, I have to OK if the groups says “no thank you, this isn’t for us”.

I also have to be clear about what will work and will not work.  If a group wants to try Agile without product owner, or without a full-time team, I simply let them know it won’t work, why it won’t work and suggest they not try.

The Connection to Pigs and Singing

In the early 80s, I was given a rubber stamp as a “present” from my boss and a peer.  On the stamp was a quote from Robert Heinlein: “Never try to teach a pig to sing; it wastes your time and it annoys the pig.”

Their point was that I was wasting time trying to change people into something they weren’t and had no interest in becoming.  These days I try to avoid the temptation (although it is still there), put the attention on my clients, on their issues and let them choose.

If pigs are singing around me, it’s because they want to.

In some companies it’s possible to try Agile software development on a small out-of-the way project.  This is one of the easiest ways to get started.  You try something, show results and then move up to a larger-scale project.  But in some companies, there isn’t anyplace out-of-the way, and every project must engage with complex organizational structures and processes.  In these companies the best strategy for success may be to choose the opposite kind of project: one that is critical to the company and visible.

Why?

Your first Agile project will probably be one of your most difficult.

• A dedicated, full-time team is critical for success.  Most organizations who are not structured for Agile, have their people spread across many projects.  This will be one of the most difficult obstacles to overcome.
• A strong Product Owner, with deep understanding of what a customer needs, is critical for the project’s success, yet it may be difficult to find someone to fill this role.
• A dedicated team room works best for Agile projects.  This might be difficult to secure.
• The role of testers changes dramatically in Agile.  Testers are part of the Agile team.  Instead of testing at the end of the project, they are testing regularly, alongside the developers.
• The team needs the ability to regularly test new software in an integrated environment.  In many companies that is difficult to arrange or the controls around the test environment make it very difficult to test multiple times per day.
• It is likely that the management team will have a format for status reports intended for waterfall projects.  Agile teams usually can’t complete these reports since their measures of progress are entirely different.  The management team will have to learn a new status reporting methodology.
• There is documentation, but it will most likely not be the same documentation that has been produced in the past.  It will take a while for the rest of the organization to get used to the changes.
• Functional managers have been accustomed to moving team members between projects like interchangeable parts, but this will really hamper progress on an Agile team.  This will be a challenge for the functional managers to accommodate.
• People are probably used to having a comprehensive set of requirements up-front.  Not having this will likely make them uncomfortable.
• Even though project plans are often wildly inaccurate, people are used to having them and will be may be uncomfortable without one until they learn how things are managed on an Agile project.

With all of these challenges you’ll benefit from strong senior management support.  You won’t get that level of support if you’re working on a low-visibility project; the burden for solving most the the challenges outlined will fall to the team.

My recommendation is to find a project that is critical to the company and get the management team on board.  Let them know what the challenges will be and enlist their support.  If possible, have them communicate what you are doing and why you are doing it to the rest of the organization.  Use the management support when you need it.

It takes work to change an organization, but if you choose the right project and get the right support, you are more likely to be successful.

Agile is particularly good for managing projects where you have significant uncertainty about what you want to build and how you plan to build it.  It can help you cut time-to-market and costs while increasing customer satisfaction.

Here’s an example.  Imagine you want to enter the market with an analytics product that provides your customers with insight into patterns and trends within their employee population. You have various sources of data available (payroll, performance management, organization structure, industry pay ranges, state and region demographics) and a general idea of the things your potential customers might be interested in learning. This is a perfect project for Agile.

Why?

Agile is an iterative process. You build a little, you show results, and you use that feedback to guide what you build next.  Your potential customers probably have some general ideas of what they would like to see, but won’t really know until they get their hands on a system they can play with.  It would be pointless to try to get all of the requirements right up-front, because your potential customers won’t be fully able to articulate what “right” is until they see something. Much of the time you’d spend putting together a comprehensive requirements document would be wasted, since the requirements will change significantly as the project progresses.

Similarly, trying to fully understand the architecture and data requirements up front is also going to be difficult.  You certainly will have some idea of what data you’ll want and how you’ll want to structure it, but you will probably have to evolve this architecture as the business requirements evolve.

You would be less likely to choose Agile for a project where you were performing a set of tasks very similar to one you have done in the past. For example, if you have call centers in five locations, and you are adding a sixth, it probably makes sense to update the project plan you’ve used for the other call center build-outs. You have a really good idea of the requirements up front and how to execute against those requirements. Limited iteration is needed.

If you have a project where you have significant uncertainty about what you are building and how you are building it, Agile is likely the right way to go.  Using a waterfall approach on these types of projects will typically lead to excessive effort defining up-front requirements, significant rework, decreased customer satisfaction,  higher costs, longer time to market, and decreased sales (if it doesn’t do what the customers need, they won’t buy it).

I want to thank Ken Schwaber for providing me with the core idea for this post in his ScrumMaster course.