Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Agile Adoption Approaches in the Wild

September 14th, 2011 · 1 Comment

I’ve tried introducing agile in lots of different ways, and I’ve seen it done lots of different ways. I’m not talking here about scrum vs xp or anything like that – I’m talking about the context in which an organization attempts to use agile. Here are several variations that I’ve either tried or seen, along with my opinions about their effectiveness.

Subversive Agile
The first time I tried to use agile I didn’t have anyone’s permission. I also didn’t go out of my way to give what I was doing a name – instead I just described how we were going to roll to my team without labeling it agile. When my business partner sent me a 30+ page requirements document she had written prior to even initiating the project (WaterFAIL!), I just said “Why don’t you tell me about the most important thing on that list and we’ll just start with that.” She described the #1 thing, I wrote a story, and we planned our first iteration. Only… I was the only one who knew it was an iteration.

Fortunately, we were successful, and people started to catch on. My business partner was the first person to label it – she called me up one day and ratted me out.

Her: I know what you’re doing.
Me: Um, what?
Her: I read about it in a magazine. You’re doing agile.
Long pause.
Her: I like it. I’m going to tell your department that I want all the projects I fund run this way.

Subversive agile is the second most effective means of spreading agile throughout an organization that I’ve seen because it breeds copycats that can lead to a critical mass of agilists. It also gives you time to struggle with the agile values without outside interference, which can be critical in a culture steeped in waterFAIL.

Stealth Agile
Stealth agile is just like subversive agile, except you intentionally try to disguise it as something else, usually waterFAIL. Project managers use stealth agile when they aren’t allowed to officially use agile (usually because of religious zealotry on the part of the CIO or PMO) but she doesn’t want to fail. Johanna Rothman‘s book Manage It!: Your Guide to Modern, Pragmatic Project Management
has some great pointers on how to do this well. The core feature of this approach are two sets of plans: a waterfall gantt chart for the public, and release and iteration plans for you.

Stealth agile will help your project succeed and will help your career, but unless you get outed or come clean it won’t drive agile adoption in your organization. If you are doing stealth agile, you should be looking for that perfect moment to come clean in a way that paves the way for a broader agile adoption.

Deterministic Agile
In deterministic agile, the PMO or some other group or person drives the agile adoption and they set up a comprehensive plan detailing exactly how and when agile is going to be rolled out. They analyze all the in-flight projects and decide from above which ones make sense to switch to agile and which ones don’t. They make decisions for the whole company about which practices are critical and what the standard agile deliverables are going to be. They schedule training, they find coaches, they tear down old flowcharts and replace them with new ones. In short, they get everything planned for a nice deterministic transition to agile with no surprises and no risk.

Sigh. Organizations that use this approach have completely missed the point of agile. YOU CAN’T WATERFALL YOUR WAY INTO AGILE. This approach is going to fail, primarily because no one is taking into account the time and unpredictability involved in really integrating the agile values with an organization.

Punitive Agile
Punitive agile is the last phase of a waterfall project, when project leaders shed all but the essential processes and artifacts needed to finish things up. This usually means discarding requirements documents, change control processes, and gantt charts in favor of pair programming, work backlogs, and short feedback loops. Unfortunately, it also includes long hours and intense scrutiny from management, thus resulting in the “punitive” label.

Punitive agile can be a pre-cursor to real agile, if someone is smart enough to realize that they would have been better off if they worked that way all along, minus the long hours. Unfortunately, this often ends up going the other way – at the “post-mortem” meeting team members blame poor requirements, not enough time to do proper design, etc for the difficulties at the end. This naturally results in the team committing to doing more of the things that got them in trouble in the first place – spending too much time getting ready and not enough time actually building software.

Declarative Agile
This is an agile-in-name-only approach. It’s worse than deterministic agile because not only does the organization not share the agile values, they don’t really even know what agile is. They only hear what they want to hear, make a few token changes, and then tell the world that they are agile. Usually the motivation behind this approach is more about impressing customers, investors, and board members than it is about actually improving your chances of success with an agile project.

The payoff for this approach is superficial and short-lived. Worse still, it gives agile a black eye by promising improvement but not delivering any real change.

Agnostic Agile
Agnostic agile is characterized by an unwillingness to establish a preference for agile over other software development approaches. In and of itself, this isn’t a bad thing at a personal level. If you don’t have experience with agile, you probably shouldn’t just jump on the bandwagon without some gradual experimentation to see for yourself if agile will work. I’d rather work with a skeptical but willing new agilist than an inexperienced zealot – it’s easier to teach the former than the latter.

The problem is when agnosticism is institutionalized and standards for choosing which projects are agile and which are waterFAIL are set up. Often this includes the creation of a committee to make those decisions. For some reason, whenever I ask advocates of this approach which projects should be agile and which projects should be waterFAIL, the answer is always the same: small straightforward projects can be agile, but big risky projects need the risk management features of waterFAIL.

Sigh. People who advocate for this approach are being passively resistant. They are really only pretending to be agnostic because they are not confident enough to oppose agile openly. They try to relegate agile to projects they don’t care about out of political expediency in hopes that they will be able to preserve the status quo but satisfy whoever is pushing the transition to agile.

I have mixed feelings about this approach. To me, the “goodness” or “badness” of this approach depends on how agile is being driven. If it’s being driven from the bottom up by subversive agilists, this might be a major victory. Run with it, then let the successful small projects convince more people until there is critical mass to try it on a large project. If the agile transition is driven from the top it’s an different matter entirely. This sort of passive aggressive resistance should not be tolerated. Take a stand.

An Agile Agile Transition

Guess what I think the most effective way to transition to agile is? Agile! The most effective agile transitions are driven by the agile values, first and foremost. Here are the key characteristics of this type of transition.

An agile agile transition is supported from the top with the critical decisions being made at the bottom. The leaders of an organization provide permission, resources, and support for experimenting with agile, but they don’t try to dictate how it is executed or make strategic decisions about where it is applied. Instead, they make a conscious decision to trust their people and let them decide. THIS IS FREAKING HARD TO DO FOR LEADERS.

Leaders focus on removing obstacles to using agile as their teams encounter them. One of the first obstacles is usually knowledge about what agile is and how it’s supposed to work, so they provide training. The first agile training session is a great litmus test for things to come, especially if enrollment is open to anyone in the organization. The people who want to be there are your best candidates for trying agile first.

Leaders make public shows of support for agile. This happens for two reasons – to tell agile teams that they have permission and to reduce resistance by others. This shouldn’t be dramatic or come off as a marketing campaign. Instead, when leaders are asked about it they should say things like “Yes, we are trying to improve our chances for success by experimenting with agile and we expect everyone to cooperate”. Couching the transition as an experiment is important because 1) it is honest and 2) it gives people time to learn for themselves.

You eventually make it clear that agile is the preferred approach. Why eventually? Because until it is clearly successful, you don’t really know that agile is the preferred approach. Until it works, you need to remain skeptically engaged.

You don’t dictate which projects use agile and which don’t. Instead, you let the teams that want to do agile do it. Following the enthusiasm dramatically increases your odds of being successful and give the unenthusiastic time to learn, grow, and change.

Deliverables, processes, and tools are not standardized until the last responsible moment. Let teams try different things, then get back together, compare notes, and decide on a common approach.

People are given time to struggle with the agile values. If you have been immersed in waterFAIL for decades, as many organizations have, the transition to agile is going to require a lot of change. I’m not talking about pure process change – if it were that simple everyone would be doing agile successfully. Value change is very, very hard and is fraught with emotion and resistance. Leaders and coaches need to be prepared for this and available to help team members through it.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Agile

1 response so far ↓

  • 1 What Meetups Mean to Me | Erich Stauffer // Nov 2, 2011 at 11:30 am

    […] interested in what Agile is, review the Agile Manifesto or visit David Christiansen’s blog, Technology Dark Side. Speaking of affiliate marketing, David makes $2000 a year from advertising Rally Software on his […]

Leave a Comment