« Back to blog

Agile is Better, Not Perfect

“Have no fear of perfection – you’ll never reach it.”

― Salvador Dalí

“I’m a perfectionist.”

Some people say it with a sense of pride as if they’re the only people who like to deliver quality work and everyone else is sloppy. God forbid someone ask them to hurry it up; those people must not understand what it’s like to be perfect. The label of perfectionist, to me, is equitable to control freak, and neither one is a good thing to be on a team. Perfectionism is anti-Agile; it can slow or halt a project.

The confusion about perfectionism being good or bad stems from a simple misunderstanding of how perfection works. There are times when perfection arises and can be admired, but the key thing to understand is that it disappears as quickly as it appears.

Perhaps the perfect design has been made. But Oh look! Here comes Steven; he notes that the budget for the project got rearranged and there is less money for development, so feature X needs to go. That perfect design is now wrong. There can be a lot of moaning and groaning and finger pointing, but after working in design for 20 years, I can tell you for a fact – this is just how projects go. New circumstances come up, mistakes are made and people take risks that don’t pan out. Instead of being surprised and angry when things change and mess up your perfect plan it would be much better to understand that this is all part of the process of creation.

For us at Beehive, this means that we try to be as Agile as our circumstances allow. I’m not going to go into a full run down of how an Agile process works; there are a million and one places on the web to review that information. To quickly cover the basics for those of you who are not familiar with the process: it’s about breaking a project into parts that get done in short bursts (2-4 weeks) that are then checked, tested and refined. In order to have something that is in a testable state, silos need to be knocked down and people need to work concurrently. A product then can be released in phases to get feedback in order to make sure the project is going in the right direction. There are some benefits and some difficulties in working this way.

Benefits:

  1. Safe environment: People feel more comfortable making suggestions and comments if we all work on the project together from the start.
  2. Buy in from all stakeholders: As the project moves forward the participants understand why decisions and compromises were made so that a perfectionist doesn’t walk into the room and try to halt the project because they don’t understand how it came to be the way it is.
  3. Emergency Brake: A project path can be shifted before the resulting product has taken on a life of its own. (We’ve spent two years and $600,000 on it…let’s just pretend it’s what we need.)
  4. Risks are ok: There is an understanding that there is probably more than one solution, but instead of trying to come up with every solution for every possible circumstance you can move quickly because you pick a solution, not necessarily the perfect solution. Then you use feedback to build closer to the best solution for the need.
  5. Speed: Momentum keeps things going at a quick pace so the products that are released are relevant to the marketplace. (If the marketplace shifts every year, you can’t take two years to make a product.)

Difficulties:

  1. Change scares people: Historically, most projects have been done in a waterfall process (you do your part, then I do my part, then I pass it to that guy over there). Having to share control of “your” part can be uncomfortable at first.
  2. I need it in writing: One of the goals of agile is less formal documentation. This requires an element of trust that a lot of us just don’t have yet. (This goes both ways…you trust that I was listening and I trust that if I do get it wrong or need to change something you won’t freak out.)
  3. I am a Roadblock: Agile is meant to be collaborative. In order for a collaborative project to move forward, everyone needs to be ready to participate when they are needed. In our overworked society, people can have something sitting in their inbox for days before they even look at it, which can hold up a project.

In a pure Agile process these difficulties are addressed, but a pure Agile process doesn’t necessarily work for everyone. Maybe it doesn’t work because your company doesn’t all work in one office or maybe you have clients that are tied to their own process. The value of Agile lies in its flexible, adaptive nature. Often times it becomes essential to adapt your process as well. When you live in an Agile environment, that can be achieved in order to deliver the best results.

Image via Dbenson and VersionOne, Inc.

from BostInno http://bostinno.com/channels/agile-is-better-not-perfect/