Go Ugly Early

Adopting an Agile methodology blindly is hazardous. This post will describe my belief that “going Agile” requires a thoughtful, long term, evolutionary approach. To make my case, I want to discuss an Agile Adoption Failure Mode (or anti-pattern) that I’ve experienced and have come to call “Go Agile Early”.

I call it this because of a sweatshirt (yes a sweatshirt) that I see quite regularly on the campus of Purdue University. You see, a large percentage of my family live, work, and were born in West Lafayette, Indiana (Home to the Purdue Boilermakers). I happen to be an Indiana University graduate. If you’re not a Big Ten fan, you might not understand the pain I experience every year as my Mom, an immigration counselor at Purdue, drapes my kids in Purdue garb and fills their toy chest with black and gold basketballs and soccer balls. <yuck>

Anyway, a bar happens to grace the campus of Purdue University called Harry’s Chocolate Shoppe. This bar has a short (dare I say unsavory) slogan that seems to be printed on the back of every 3rd sweatshirt in West Lafayette: Go Ugly Early. Not surprisingly, the Purdue contingent at my family Christmas each year think this is hysterical.

OK, before you accuse me of being unsavory, let me first apologize. I’m sorry for tricking your “Id” into reading my blog post. There. It’s said. As I write this, I keep changing words and phrases because of all the sleazy double entendres that keep popping up (see what I mean). For the record, I’m ashamed of myself.

So now the hard part… <ahem>

Tiptoeing Around the Correlation – Going Agile Early

Wouldn’t it make you feel good if someone said to you, “We love these changes you’ve suggested! Agile makes so much sense. I think we should make this the standard around here”..?

Yes…? Well, it does me as well. So good in fact that it has allowed my ego to blind my better judgment. I think, “Sure, that’s a great idea! Let’s force them to do it! This will be so easy. That’s half the work gone with the snap of the CIO’s fingers. These people don’t REALLY know anything about Agile. That doesn’t matter though. I must be so persuasive. What could go wrong?”

Before I can get my hips back around from patting myself on the back, the long, slow, painful journey toward — complete — process — meltdown — begins.

Tell me if this sounds familiar. You are introduced to a shiny new framework (or process, or methodology, or technique, or yes…(person) if you happen to be at Harry’s Chocolate Shoppe at 12 AM) and you get the feeling almost immediately that this could make all your problems disappear. It seems so easy, so attractive and well packaged, so obvious! There are no noticeable sticking points. No gotchas. No downside. Could it really be this easy? What could go wrong? (I think we all know the answer to this question.)

EVERYTHING can go wrong! The mere fact that you know NOTHING about it (at the very least) should give you pause. Here is a modified timeline of a predictable outcome if you allow this train to leave the station. I’ve left out some detail but you will get the picture.

Hypothetical Failure Timeline

  1. Agile edicted to the organization with no significant understanding
  2. Projects begin and teams are organized
  3. Scrum (easily understood mechanics) is chosen for its simplicity
  4. All teams, regardless of work type or need, are forced to “go agile”
  5. The PR machine spins up in the organization and business partners are introduced to Agile (typically aren’t impressed)
  6. Burn downs and hyper planning starts (teams wonder if they’re doing it right)
  7. Managers and project managers misinterpret Sprint backlog detail as a new ability to tightly control projects
  8. The awkward transition to stand-ups, chicken/pigs, prioritization, and transparency begins
  9. Team struggle to deliver “working features” in a single iteration
  10. “Scrum-But” attitude overtakes some teams. Those teams start to sing a resounding chorus: “yes, but Agile won’t really work with MY projects”
  11. Results are misinterpreted again by management resulting in more edicts and tightening control
  12. Teams begin to look at estimates and hours as their ONLY deliverables (they forget about the business value and point at the zero next to their name in the sprint backlog)
  13. Worsening results blamed on overwhelming meetings, planning, and detail “required” by Agile
  14. Retrospectives begin to dull (no one brings anything “real” to fix any longer)
  15. Organizational impediments are now viewed as “immovable” as early efforts to remove them went unresolved or ignored
  16. Business starts to comment on “the stifling bureaucracy and controls”
  17. Someone says “Agile just doesn’t work here. We need to be more flexible and responsive.” <WHAT!>

Agile change activities go through lots of stages. Some teams adapt swimmingly. Especially when they know what the phrase “inspect and adapt” means. The problem is that most teams, when thrown into the deep end and don’t “get it”, tend to blame the process. Change agents <you> begin to slowly lose their leverage. No longer can you slowly grow understanding. You are now faced with rampant disinformation and ill-conceived management impositions. Agile starts to “get away from you”. You no longer have the ability to grow and evolve.

Be the Grown Up

To be sure, the responsibility can (and should) be shared on all sides of the decision to Go Agile Early. However, as a leader and change agent in your organization, it is your responsibility to be the grown up. When an unsuspecting client, executive, or team jump at an opportunity to dive headlong into a “methodology one night stand”, use it as an opportunity to show patience and maturity.

Explain that, while you think Agile is a brilliant choice, it won’t (and can’t) work without a reasonable understanding of all its virtues, mannerisms and short-comings from its practitioners. Explain that a slow, measured, evolutionary relationship with Agile will help determine Agile’s “Fit For Purpose” on their teams. If you don’t evolve slowly, you will lose the leverage you need to make changes and prove worth. If you can lead small teams to a level of understanding that is sustainable, then you’re chance for success is drastically improved. If you lead them half way there and set them loose, they will capitulate when things get complex and the failures immediately become YOUR problem. After all, you’re the one who suggested Agile, right? <get him!>

Relationship Advice

Don’t subvert your ability to affect positive, sustainable change. Don’t forget that you are going for a long term relationship here.

Don’t “Go Agile Early”. That’s when it really gets Ugly.

One thought on “Go Ugly Early

  1. Pingback: Philip Chang

Leave a Reply

Your email address will not be published.