Why Agile Is So Hard

By Traci Lepore

Published: August 5, 2013

“We deceive ourselves that being agile means you don’t need a vision.”

Is agile a dirty word in your company or among the members of  your UX team? Do you hear the term lean UX and groan? It’s okay—and not really surprising—if your answer is yes. Agile is hard, and we all know it. But since agile is likely to stick around for a while, I’m sure you’ve thought about how to make it easier.

However, the question shouldn’t be how to make it easy; rather, it should be about understanding why agile is so hard in the first place. That way, we can get at the root problems and maybe have some hope of turning what can be a frustrating experience into an amazing one.

By nature, designers are well-organized and linear people. Logical flow is something we can grasp easily. We work well within structure. We are perfectionists and want all the I’s dotted and the T’s crossed. We thrive on recognition and success. But being agile or lean goes against these tendencies and forces us to step into an uncomfortable zone.

There are three aspects to this discomfort that I think majorly impact our experience of the agile philosophy and methodology that I think are worth considering:

  • We deceive ourselves that being agile means you don’t need a vision.
  • We don’t understand the pace that an iterative process requires.
  • We don’t allow enough space for experimentation and failing within a safe environment.

Stop Deceiving Yourself

“The biggest problem that I see again and again with agile teams is their thinking that you can dive into sprints and figure out what you’re doing as you go along.

The biggest problem that I see again and again with agile teams is their thinking that you can dive into sprints and figure out what you’re doing as you go along. Vision is a major premise of the agile methodology. But we often forget that there is more to the work than the day-to-day grind.

It doesn’t matter how big or small your project is, you need to set a vision for it beforehand and make sure that someone is responsible for keeping an eye on that target throughout the process. Understand the end goal and define small, incremental blocks of work that will enable you to achieve it. Measure success by increments.

And the most important part—given that agile is an iterative process—is that you continually need to do ongoing work to maintain the current state of the vision. These statements may seem contradictory, but if you set the vision and forget it, there wasn’t really a point to your defining a vision in the first place. Things morph during the process, and ultimately, being agile is about being responsive. It’s okay for your vision to evolve, but it’s not okay to start without a clear vision to begin with.

Don’t let yourself get caught up in the chaos of iterating yourself into an incoherent whole. Find the balance between your ultimate vision and the natural progression of iterative processes.

The Truth About Iteration

“For iterative processes to work well, there is a certain pace and rhythm that you have to maintain as a constant.”

We call the iterations of work that we do when following the agile methodology sprints, but many times I think that we forget the true meaning of the word—and that causes a breakdown in the process. For iterative processes to work well, there is a certain pace and rhythm that you have to maintain as a constant. When iterations constitute a broken, choppy cycle, we fall down, lose momentum, and get stuck in the weeds. To be successful, iterative processes need to remember these key factors:

  • Iteration must happen quickly—without too much time to think in between sprints. If it doesn’t, you risk losing focus, forgetting the valuable insights that you need to address, and missing out on experimenting with ideas that occur in the moment. In essence, you’ll spin and lose time.
  • Iterative loops must be small enough to be digestible. If they are too large, you risk slowing the pace—or in some cases, overwhelming people with too much at once and allowing things to slip through the cracks.  
  • Feedback needs to be constant. It is almost impossible to execute an iteration that actually moves you forward without getting feedback. Lapses in your feedback loop hurt your ability to make meaningful moves in a positive direction.

If you are feeling a little scared after reading these key factors, I don’t blame you. Rapid iteration is a rigorous exercise. I won’t lie about that. It takes effort to maintain the pace that will make you most successful.

It’s not surprising then that many teams find iterative processes so hard in comparison to the more traditional waterfall process. But you don’t have to kill yourself to make this work. Remember to give yourself breathing room. Plan time to check in on the big picture. Plan empty or catch-up sprints into the process if you need to. What is key is to work in the breathing room around the iterations, not in their midst when it might upset the pace.

Why Failing Doesn’t Always Mean You’ve Failed

“The whole idea behind iteration is that you should test ideas as quickly as possible, find out which work, keep and refine those that do, and drop the rest.”

One of the biggest advantages of an agile process is the one thing that usually gets left by the wayside: the fact that quick, iterative changes should allow us room for experimentation, which means failing with some ideas. The whole idea behind iteration is that you should test ideas as quickly as possible, find out which work, keep and refine those that do, and drop the rest.

Unfortunately, human nature often doesn’t want to test imperfect ideas—never mind admit that we had unsuccessful ideas to begin with. And at times, it’s difficult to accept the reality that we must let some ideas go because they don’t fit the vision, especially when we think they’re the most brilliant ideas in the world.

We also put a lot of negative energy around failing that doesn’t need to be there. We don’t need to hold on to ideas that don’t work. And just because every idea doesn’t work, doesn’t mean you’ve failed in any way shape or form. If you find the one idea that is right through a process of testing and respond by making iterative improvements, you’ve succeeded.

And remember that ideas don’t need to be perfected before you can get feedback on them. That’s why we, as UX professionals, sketch and paper-prototype our initial concepts. It’s not worth making the investment in pixel perfection until you know something is the right idea.

If you need to feel good about your failed ideas—or maybe are feeling pressure to explain why you tried them—figure out the story of how those ideas led to the right idea. What did you learn from those failures that led you to success? Because, if you are doing feedback and iteration right, I’ll bet you can’t tell that success story without telling about the failures.

The Original Agile Methodology: Improv

“Improv is the original agile methodology.”

There’s a fantastic TV show that just came back on the air called “Whose Line Is It Anyway?” In one of the new episodes, there was a prime example of why improv is the original agile methodology. Let me explain.

In the episode, the performers were playing a game that was something like “things you can say about your favorite pair of shoes, but not your girlfriend.” One of the performers starts to do a bit and quickly goes down a very dirty and unintended path. He stops, they all laugh, and move on. The next bit the performer did played on the gaff, but by the third round, he had moved on.

This seems simple, but clearly articulates why improv is akin to agile. He tried something, it didn’t work, he acknowledged it, then tried again. The whole point of the exercise was iterative attempts at coming up with ideas. The ideas didn’t have to succeed, but they still led to some good outcomes. They didn’t agonize over thinking through the ideas that they should try. They maintained a quick pace. Essentially, they got it all right, even when they got it wrong.

Chris Spagnuolo wrote an excellent article in which he talks about key principles of improv that drive innovation. They fit very well into the conversation on agile and can also help us to learn how to be successfully agile.

  • Keep questioning what works. Agile methods do ultimately allow us to attain our perfectionist desires. But they require us to learn that we’ll get there in increments, not in one shot. It’s constantly a question of how you can make things better in the next iteration.
  • Be a risk taker and take chances. There is no reward without any risk. Rapid iteration lets us take bigger chances because we can play with ideas before committing to them. We can be more innovative if we allow ourselves this play.
  • Always be open to making changes in response to what people say and to what happens. Being improvisational means learning how to be a good listener and adjust to the current circumstances. Always being open to new information consistently enables us to understand how to proceed and adapt to the iteration process.
  • Create shared plans and agendas. Having a clear vision and goals is critical. But if they aren’t shared and understood by all involved, they have no meaning. Agile requires a lot more conversation and a lot less documentation.
  • Be fully present and engaged. You can’t be truly agile, move with the process, and keep your momentum if you aren’t always there and engaged. You let your team down the moment you step out.
  • Keep moving forward. Maintain the pace, maintain the pace, and maintain the pace. Looking backward will not get you any further forward. Agile is not a case in which objects in your rear-view mirror are larger than they appear.
  • Focus on the good of the whole. It is important to understand that the strength of the ensemble, or team, makes or breaks an improv or agile experience. Always make sure that you support what is good for the whole team and know what is in everyone’s best interest. That way, you all succeed.
  • Let yourself lose control. Learn how to let go and work with your team. Collaboration keeps the process sane. One person trying to run the show breaks down the cycle.
  • Self-organize. Understanding your role in the group and how to manage yourself makes you a better team player. Being a successful collaborator requires that you hone your interpersonal and intrapersonal skills.

The Real Truth

“Agile … requires a strong ensemble that can work together. It also requires a rigorous pace and our constant attention.”

So, why is agile so hard? I think it’s because agile requires us to learn how to become a better version of ourselves than we perhaps have been in the past. It requires a strong ensemble that can work together. It also requires a rigorous pace and our constant attention.

This shouldn’t scare us off, though. We’re all capable of honing our improvisational skills. The basic fundamentals of improv are those that actually play on human nature—such as the initial characteristics that I mentioned earlier. And maybe, by understanding the challenges that agile presents and working through them, we can make agile a little less difficult.

Reference

Spagnuolo, Chris. “Is Improv the Key to Innovative Teams?DZone, January 3, 2013. Retrieved August 01, 2013.

11 Comments

In the future, if someone asks me for a definition of “spot-on,” I’m going to refer them to this page!

Thanks, Tom! That’s a great compliment. I love hearing that things resonate.

Excellent points! This article started a long chain mail of responses between fellow UXers. All good stuff.

I totally agree with Tom G. This should be a reference doc for groups moving toward agile development.

This is possibly the best analysis of agile I have read since I became a Scrum Master. Thank you for your awesome insights.

Great article. I, at first, wasn’t sure where the article was going to go, but soon, after a while, it was hitting things on the head. I loved the details you covered about agile and practices.

Do visit me, too, as I also share some perspectives on agile on my company blog.

Your observation of a lack of vision is completely accurate and hits at the true nature of the hardness of agile. I would further refine that to say that often there is a lack of commitment to the process by those that are supposed to have that vision. Too many times, I have seen poor sprint planning lead to scrums that turn into a water cooler type of discussion of the daily activities rather than the short productive meeting that is intended.

I also believe the reason that agile can be so hard is because people latch onto the word so they can claim that they follow a process. When in reality, they don’t take the time to correctly follow that process.

Thanks all! Great feedback to hear.

Danny, I agree that lack of commitment hurts so much, because it’s impossible to be the ensemble you need to be if you want to be successful in agile.

Traci -

Thank your for your insightful article! Lots of stuff to think about here from someone who’s obviously seen a lot of agile action.

While I am well-organized, I don’t think of myself as”linear—in the following sense—and I don’t know if this will resonate with other designers or not.

I get flashes of insight all the time that come from nowhere—but are definitely a result of linear engagement in a design project. I see this process at work when I write as well.

Certainly, there’s plenty of discipline to both of these creative activities, but much like the team process you describe here, there’s a way in which, as you move into a design or concept, you begin to see shortcomings (negative) or further possibilities (positive) of your original idea as you go through the act of fleshing it out. In the process of seeing what you’ve done—akin to listening that you point out—you almost imperceptibly revise or redesign, or you amplify, or you clarify/sharpen the concept or design. But you need to listen closely and be open to this process. Perhaps this is the internal side of the external team discipline you describe so well.

The act of fleshing out in UX design or in writing is absolutely necessary. You’ve got to get it out there—either in a file containing words or in a functional design—then work it over, as necessary. Again, I don’t think I can overstate that the process of getting an idea out is absolutely critical to the process of shaping an idea into something better, because you don’t even know what you have, until you get it out there. My wife—who’s also a writer and a high-school English teacher—and I call this process in writing, “writing as discovery.” Might the metaphor of discovery in UX also be useful?

One more thought on this. The great American writer, Flannery O’Connor, said that, if your writing doesn’t surprise you—because it is a discovery of your making, and not just your readers—it won’t surprise anyone else either. (And she very much meant surprise as a good thing, within the context of this quotation.) Perhaps we, as designers, can learn something from this statement. Great UX should engage—perhaps, on occasion, even excite?—the user. There’s a way in which great design surprises users into being able to do what they’ve never been able to do before. I daresay Steve Jobs knew this quite well.

Once you add the vision thing, realize that they are increments and not sprints, then you can pretty much abandon agile/scrum altogether and just be iterative in a traditional way. I call that postagile. You can read more of my thoughts on my blog.

Great article, and every point stated was a pearl of wisdom. A lot of misconceptions around agile, but your emphasis toward its improvisational nature and the strong need to “stay engaged” ring so true.

Join the Discussion

Asterisks (*) indicate required information.