Enabling Agility

Archive for April, 2009

Many companies who have had formal Software Development Life Cycle processes are now making the transition to Agile software development methods. Because these organizations are used to a great deal of process formality, they may be tempted to define a rigid process for Agile, but to do that is to miss the point. Agile is inherently a learning process where experimenting and improving process is a core principle. Being agile vs following a rigidly prescribed Agile Process will enable a company to be be more resilient in the face of change, and in today’s environment change is happening at a very rapid pace.

What Does it Mean to be Agile?

Let’s start with the Wiktionary definition:

Having the faculty of quick motion in the limbs; apt or ready to move; nimble; active; as, an agile boy; an agile tongue.

So what’s an agile organization?  First, there is the ability to quickly notice and respond to something, be it an opportunity or a threat.  But I think think the definition of organizational agility needs a little more, because a reactive organization can respond quickly, but often inappropriately.  So how about this?

Organizational agility is the systemic ability to rapidly notice and effectively respond to emerging ideas and situations.

I added the word “systemic” because I think an agile organization, is agile at all levels of the organization, from front-line worker to CEO.  Consider the Ritz-Carlton hotel.

The Baldridge Award-winning Ritz-Carlton hotel chain empowers (and even encourages) any employee at any of its properties to “fix” any guest problem on the spot. Employees are empowered to implement or create any customer satisfaction solution that will cost under $2,000. Ever stayed at a Ritz-Carlton? The commitment to customer service radiates from every employee.

Northern, Mark (2004, November). Everyone Loves Their Own Ideas.
Fast Company, Issue 88

The top management team can’t be everywhere, seeing everything and responding to everything.  It takes the whole organization to be agile.

Why Do Companies Want to Become Agile?

Companies often become interested in becoming more agile when they notice that they aren’t getting what they want out of their current processes.  They find that it takes too long to get an new idea funded and too long to get a product to market.  They are over budget and under delivering.

Agile product development practices are seen as a way to become more agile, so they are brought into the company, usually using a pilot project to see how they work. Often the pilot will be quite successful. The team is excited, the market folks are pleased with the fast turnaround, silos are broken down and collaboration rises.

And then someone says “this is great”, let’s write the process document for exactly how Agile works, and have everyone follow it”. Unfortunately, that way of thinking can take the company away from the agility they were trying to achieve by bringing Agile into the company in the first place.

The Inherent Conflict Between Agile and Rigid Process

Human beings design processes based on their experience.

“Hmm.  The last guy that went into the woods over there got mauled by a bear.  Maybe I won’t go that way.”

“We need to keep people from getting killed by the bear.  Let’s put up a sign to keep people from going on that path.”

We figure out things that work and don’t work and try to make use of that knowledge productively in the future.  Nothing wrong with that. Particularly if we keep using new evidence to modify the process over time.

“OK, so Bill, Mary and Yoko all sneak down the path every day, ignoring the sign.  It has been five years since someone got mauled by a bear going that way.  Maybe the bear died or went somewhere else.  The path is, frankly, the fastest way to go.  It is probably OK to take down the sign and let people walk that way again.”

When we start to believe in a process and no longer pay attention to reality and adjust the process when it needs adjusting, we get into trouble.   Most of the stifling processes we force our employes to follow originally had a good reason for being created, but the processes weren’t updated when there was new information.

So the intent of building a rigid process – to reliably and repeatably get a good result – is fine, but in reality, it doesn’t always work.  In fact, Meg Wheatley and Myron Kellner-Rogers argue that stability arises when an organization has the freedom to regularly experiment to find what works.

If we do not exercise that freedom to change, the organization cannot maintain its stability.  … Stability is found in freedom – not in conformity and compliance.  We may have thought that our organization’s survival was guaranteed by finding the right form and insisting that everyone fits into it.  But sameness is not stability.  It is individual freedom that creates stables systems.  It is differentness that enables us to thrive.

This need for flexibility might be particularly true today, with the incredible rate of change brought about by the severe recession and the rapid introduction of new legislation intended to combat that recession.

Why do People Follow Bad or Out-of-Date Processes?

The simplest reason is because the organization they are a part of reenforces and rewards following the process.  People are asked to write status reports based on the process, show process documents to get approval to the next stage of funding. Additionally there may be formal process audits.  Doing something other than following the process is difficult.

Note: people sometimes take actions that make it seem like they are following the process, while following a different, often more effective, process in the background.  This is obviously wasteful.  But when processes don’t work, or work very poorly, it is often the only way to get things done.

Is this Empowerment Thing Real?

Having been managed to a set of formal processes for years, people are usually hesitant to try new behaviors.  After years of being to what to do, the idea of being a self-organizing Agile team is pretty unusual.  People will be watching the management team to see if this newly-granted empowerment is real.  The slightest hint that it isn’t for real is likely to drive people back to the familiar ground of following instructions.

If the agile culture change is successful, you’ll notice that people being agile – observing what’s going on and rapidly adapting to the changing circumstances.

Advice for Companies who Like Formal Processes

My advice is to do the least amount of standardization of the Agile practices as possible, trust your people, and to adapt the existing organization to support Agile instead of having Agile adapt to the organization.  If you really want an agile organization, you’ll have to let go of some of the formality that you’ve had in the past.  If you try to standardize too much, you risk losing the benefits that had you adopt Agile practices in the first place.

There are a few areas that commonly require a little adjustment, status reporting and project funding are two common ones.

Take status reporting as an example.  Organizations that follow a waterfall methodology will typically report progress against each of the phases of the project (requirements, design, development, test etc.).  To ask an Agile project to report against these milestones doesn’t make sense, and it sends a very strange message to the team.  ”We want you to be curious and resilient if the face of change.  We have no plans, however, to do that ourselves”.

Let Agile teams report using standard Agile means (e.g. a burndown chart) and waterfall teams report using their normal means.  It may take a bit of explaining for a company president or product manager to understand what they are looking at, but only a bit.  Once people understand Agile, they’ll realize they have very high-quality information on the status of projects.

Funding is another place where there may be a need for new process.  Some organizations require approved documents to move from one stage of funding to another.  Instead, consider having your unit of funding be for three-month releases, where something is delivered into production.  That’s really pay for performance.

Summary

If you’ve decided to become an agile organization and adopt Agile practices, give the new culture the care it needs to flourish.  Live with the discomfort and uncertainty of looser processes than you are used to.  Standardize on the least number of new processes you possibly can.  You’ve hired great people.  Give them room to breathe.  Let them be great.

If you’ve made it this far, thank you!  If you have a moment would please leave a comment?  I’d like my blog to be as helpful as possible.

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.

There are two Kristyns.  The first worked at a large, well-respected firm, did her job competently, but nothing extraordinary.  The second Kristyn is extraordinary. She is unemployed, and a volunteer Producer/Director of “The New England Job Show”.  It is a new cable program to help people find work, produced, directed and run buy people out of work.  Articles have been been written about the show and carried by the Associated Press.  Good Morning America, Chronicle and Fox are planning to do pieces on the show.  There is interest in expanding the program to help more people statewide. Kristyn is a masterful networker, connecting people everywhere she goes, always looking for new possibilities.

They are both the same Kristyns, only separated by about 5 months.

So what’s different?   If she were to get a job tomorrow, would Kristyn go back to her cube, keep her head down and do her job?

I doubt it.  I don’t think you’ll ever see Kristyn in a position where she’s unable to make a difference in the world again.  Ever.

I asked her what was different.  In her previous job, she’d tried to make things better, but never got much support to make the changes she wanted to make.  There was a lot of talk about change, but nothing changed. When she was laid off, she realized she had to do something special to get noticed.  And she did.

How many of the keep-your-head-down-and-do-your-job Kristyns do you have in your organization who would do extraordinary things with only a bit of nurturing?

For an organization to be truly agile, it is critical to have people who are enabled to give their best.  The next product idea, the killer customer-service model and the next great marketing campaign are probably out there.  You just need to give them room to come out.

In their book a simpler way, Margaret J. Wheatley and Myron Kellner-Rogers write:

Fuzzy, messy, continuously exploring systems bent on discovering what works are far more practical and successful than our attempts at efficiency … They slosh around in the mess, involve many individuals, encourage discoveries, and move quickly past the mistakes  The are learning all the time, engaging everyone in finding what works.  The system succeeds because it involves many tinkerers focused on figuring out what’s possible.

Go find your Kristyns and let them loose.  They are everywhere. And they will make your organization great.

I’m committed to people experiencing joy, self-expression, partnership and accomplishment in their work.  That statement is my guiding principle.  It helps me decide where I’m going to focus my time, my effort and my education.  So how did I get interested in Agile and how does it connect to my personal statement of purpose?

The first Agile project I encountered was far from ideal. The QA team didn’t understand how they fit into the Agile process. They attended daily stand-ups (on the phone) waiting patiently for requirements so they could start testing at the end of development.  There was no team room; everyone worked at their desks. Shortly after the software was deployed, it had to be pulled out of production and reworked because its downstream effects hadn’t been fully considered.  Somewhat messy, as first tries can often be.

I was curious to find out what people thought about the project on the business side and gave several of them a call.

The overall business owner considered it the best project he’d ever worked on with IT. He loved knowing what was happening every day, and the close collaboration between the developers and the business people. Someone on the team told me he appreciated talking about ideas for a feature with a developer in the morning and often seeing it work that same day. A user said how happy she was with the software; that it gave her an easy and intuitive way to do something that had been hard before.

I knew that there was something really right about Agile if a project with this many challenges had left such a positive impression.  There was a rare level of enthusiasm.  Joy, self-expression, partnership and accomplishment were present.

These conversations flipped me from being interested in Agile to being an evangelist for Agile.