Doing Agile “Right” vs. Being Agile

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 limbsapt or ready to movenimbleactive; 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.

Adventures in Change Management

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.


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.

VN:F [1.9.1_1087]
Rating: 8.5/10 (8 votes cast)
Doing Agile "Right" vs. Being Agile, 8.5 out of 10 based on 8 ratings

12 Responses to “Doing Agile “Right” vs. Being Agile”

  • Rory:

    Excellent post, and right on. I understand why companies are wary to change. I really like the idea of letting agile be agile, you can’t be too structured.

    As a blogger, I really like the rating stars you have here. Hope I can find those to add to mine!

  • Ron Holliday:

    Great post!

    Most organizations want to apply rigidity to process in order to shut chaos out.

    The more rigid we make the process, the further from the edge of chaos and less adaptive we become.

    Are “burn-down charts” really agile?

  • You’ve questioned burn-down charts in the past. Can you elaborate?

  • Alex:

    Transitioning to Agile is difficult. I see the same problems of management sticking to the same processes yet “allowing” their teams to use agile methodologies on their projects.
    Additionally, a big problem we have here is these teams asking for guidance. We only have a handful of people willing/able to provide that guidance. And not all of them agree. Is that ok?
    Jeff Sutherland suggests that teams follow rigid processes (say, strict Scrum) until they’ve demonstrated enough knowledge/skill to run the sprints themselves, then they can go ahead and adapt as they see fit. Do you not see value in some level of standardization, at least until teams are comfortable with the freedoms they’ve been afforded?

  • Hi Alex,

    Not sure I understand your first point. Do you mean you have a number of people with Agile expertise who offer different opinions on the same question?

    When you are training teams, I’m fine with process standardization. I’d call it “Training Wheels” so people understand that they can be discarded when they’ve learned the skill. That’s different from the management team wanting standardization since they’ve had it for waterfall in the past.

    – Bob

  • Alex:

    To your question, “yes.” But in the spirit of your point, I think that those differences shouldn’t be a problem as long as we do things that are right for the project — we have that freedom to change.

    And as for training wheels, that makes sense.

  • I would have the “training wheels” period be a team choice. As a coach, I’d let them know where I thought they were as a team, and suggest going into a “training wheels” period. I’d set an explicit time when we’d reevaluated this decision. Since people are so used to having freedom taken away, I think you have to remind them that they have freedom.

    If the team needs that level of direction, and are unwilling to sign up for it, I can always decline to be a coach.

  • Juanita:

    Great Post!!

    Most organizations adopt agile, apply rigidity to the process and then resort to tailoring to make the process less rigid. This happens due to the conditioning they have that compels them to standardize – which defeats the purpose of Agile.

    What would you do in the first place to remove this conditioning?

  • Hi Juanita,

    Conditioning comes in various forms and the approach depends on what you are up against. You inspired my next post that I’m currently writing. I hope to get it out soon.

    Thanks for your comment.

    – Bob

  • Alison:

    Thanks for the thoughtful post. The difficulty comes in striking the right balance between providing structure or framework and the flexibility to allow teams to experiment, particularly in enterprise organizations. That is definitely something that we are struggling with.


  • Hi Alison,

    One approach you can try is to set up structure with a specific date when you plan to reevaluate that structure. If it still seems like the right approach for your organization, keep it longer. If you are diligent about questioning all your non-value-add work on a regular basis, you can keep your processes lean.

    – Bob

  • Ron Holliday:

    Hi Bob,

    I hope you and Eileen are doing well.

    “You’ve questioned burn-down charts in the past. Can you elaborate?”

    Burn down charts were invented as a means to buffer management in the early days of SCRUM. Circa 1997-98. They are not agile by any means of my imagination.

    Software development is knowledge work – IOW it is a knowledge acquisition and encoding activity – and therefore can never be predictable.

    Cheers good buddy! Ron

Leave a Reply