The company I work for has an evolving agile implementation methodology, specifically Scrum. Over the last two months, the User Experience team has been becoming more of an integrated part of this process. It's been quite an interesting ride and it is far from over.

I'm actually a process person. I enjoy figuring out how to tackle problems and I recognize that the same process rarely works for two different situations. However, I never quite realized how much of a safety net the waterfall process was. While no project uses the 'ideal' process, the many possible steps and variations form a comfortable foundation that is the basis for improvisation. There are different activities and deliverables that answer different questions and needs and these form the toolkit that I have drawn on over the past decade.

Agile is very different. While project needs and user needs haven't changed, how you can approach the problem from within an agile context is very different. Thankfully, there are some smart people who have paved the way, but there are few clear answers. UE wasn't at the origin of agile and we are a little late to the game.

I certainly won't say that anything we are doing is definitive, but I will share some of our struggles and what I've taken away from it.

Are you 'agile'? What works and what doesn't?

It's a classic struggle, up there with good vs. evil and IM vs. grammar, and that is the struggle between scope and resources. It's a familiar tale to anyone who has ever had to get anything done at any time, even if its only the weekend chore list. I had a professor who said, "Fast, cheap, and good. Pick two." You likely had a mentor at some time with a similar maxim.

While deadlines (fastness) can move, there is only so much time available, so that leaves scope (goodness) and resources (cheapness) as the two things to manipulate. Rarely do those in charge want to do less. It happens, and when it does, it can be wonderful. Typically, however, stakeholders push for as much as they can get.

Then just add more people, right? Sometimes that isn't possible and sometimes it's not desirable. There may be limited resources (cash) that prevent a team from hiring. It may be a tight market with few qualified candidates. Even if the right people are out there, it will take time to find them, bring them on board, ramp them up, and make them productive. That will add an additional drain on the existing team. In the long term, if a larger team is called for, it’s a necessary and proactive sacrifice, but if may not help, and may exacerbate, an existing short fall.

If time is finite and scope is larger than the resources available, what is to be done? Well, the short answer is cut scope. Of course, it's not that easy.

Today, I'm not going to offer anything new to help solve this problem. I'm still working on that myself. I had been frustrated with how to succinctly describe it. I was talking about scope as the unstoppable force and resources as the immovable object, but it didn't work that well.

While sitting with a colleague in a conference room talking about this, I said, "Caleb, you have kids right? You'll get this. Remember when Winnie the Pooh ate too much honey and got stuck in the entrance to Rabbit's Howse and everyone tried to pull him out?" Caleb nodded.

"We're pulling the bear," he said.

I may not have helped anyone solve the problem, but, hopefully, now you at least have an amusing way to describe it.

You may have seen this video on the 37 Signals blog, but it was so evocative for me that I wanted to add a few additional thoughts. First of all, I'm a big Ira Glass fan. If you've never listened to This American Life on the radio (or the podcast on iTunes) or seen it on Showtime (or bought the shows on iTunes), I highly recommend it. It is modern documentary story telling at its finest.

In this interview excerpt, Ira Glass is talking about finding and developing the stories that will eventually make it to the show. Watch it. It's short, ~4mins.

In their post, 37 Signals author Matt focused on the 'less is more' theme, how we have to be relentless 'killers' in order to maintain focus in our design. This is one of the reasons I started this blog. An efficient process should lead to a focused design. 37 Signals already addressed this, so I wanted to talk about some of the other points in the video.

Glass says that his team spends most of their time not in production or editing, but in looking for the story. In user experience, that is our focus as well, finding the meaningful story that dramatically improves the product for our users and justifies the development efforts. We talk to people, understand them, and figure out the plot of our users' experience and design how we will bring it to resolution.

He talks about interviewing people constantly so that you will eventually find that one person with the really evocative story that will be meaningful. If you've done usability testing, ethnographic research or some related activity, I'm sure you've had this experience. You see a trend developing and there is one person who expresses the need in such a succinct and memorable way that it solidifies your understanding of the problem. Sometimes it's the opposite, where there is not a trend, but you hear a story from one user that you may not have heard from anyone else, but based on what you know, it feels true and universal.

We only have these insights when we continually engage with the community.

One of the aspects of agile that I was drawn to immediately, was the emphasis on involving the users. It was exciting to read about an 'engineering' process that was embracing user centricity. Finally, UE and development could work together with a shared understanding of the importance of user engagement.

Unfortunately, the reality can be much more challenging. As the drive for new features increases, the time and resources available for user engagement diminish.

So what can we kill so that something better will live?

It has been quite some time. I wanted to give Drew's comments some thought before responding, but the gap has more to do with sleep deprivation than soul searching.

I thought I'd look at what kind of companies are driven by the sales process. From my experience, these are companies that are typically either consulting companies, start-ups with few clients, or large products that depend on a small number of very large deals.

Consulting companies are a no-brainer. If you don't succeed in the sales process, you have no deal, no money. Ideally, salespeople work to build long term relationships, but it doesn't always happen. These are also the cases where I've seen annual budgets come into play on the client's side. A client may have a limited budget for a period of time, typically the fiscal year, and they are going to use a significant part of it on professional services for the proposed engagement. This makes them feel like they need every feature they can possibly imagine delivered over the course of the engagement. Their rationale is that if they don't get it during the 3 or 4 months they're paying for consultants, they will have to wait until the next time budget cycle. Of course, most of the engagements I've seen have been waterfall and not iterative. That would be one way to address the concern.

For start-ups with few clients, the need for revenue and to please these few clients and partners often leads to acquiescing to many demands. I've been on the partner side in the past, where I've heard it said that the risk of working with a new company is often offset by the price and the ability to dramatically impact the product development. This can also happen with companies whose product management or product vision has not quite matured.

Large, expensive products often have long sales cycles and sell fewer licenses per year. The power of these deals often can exert significant influence over the product design in order to satisfy the customer. I've also seen product companies with no strong user experience expertise engage with clients with no strong user experience expertise. As you can imagine, this resulted in the product company having a list of clients that their sales people were not allowed to reference because the implementations were so poor. If they were asked about one of these clients, there was a canned response they gave and then dropped the subject.

For companies with mature product management and many smaller companies, it seems less likely that any single customer will exert enough influence to significantly effect the design. So why are there the same problems? In my comment, I hypothesized that these organizations are still choosing to develop/refine features based on existing knowledge, rather than spend time validating or performing new research. Why is that? Are we really under the pressure we think we are? How important is the first-mover advantage?

One of my favorite examples is from the removable hard drive war. At the time, Syquest was the clear leader in the space. When most people still used 1.4mb floppy disks, Syquest offered 44 and 88 megabyte cartridges. They were large, but they worked well. Then along comes the Iomega Zip Drive in 1994. It was fast. It was cheap. It held 100megs in a fraction of the space of a Syquest disk. It was also a piece of crap, and yet four years later, Syquest filed for bankruptcy. So it would seem that being first means a lot.

On the other hand, we've got Apple's iPhone. Launched in 2007, it was late to the game. Smartphones had been around for anywhere from 5 to 14 years, depending on what you consider the first one. Little more than a year later, it is the most widely used mobile browser in the US. That may not be a measure of financial success, but clearly, they have put out a product that has changed the way the mobile computing experience is measured.**

So where's the fire? Or more importantly, is there a fire? Should we rush to market like Iomega or take a slow and careful approach like Apple? Which approach do you prefer? Have you experienced both? What do you think are other salient success stories? Jason at 37Signals thinks urgency is poison. What do you think?

**Disclosure: I don't yet use an iPhone. I'm patiently waiting for the next version.

This is a bit off topic, but April 3rd is Cheese Weasel Day. This is one of my favorite holidays. Read on.

Unknown to most, April 3rd is Cheese Weasel Day, the holiday where the Cheese Weasel brings dairy goodness to all the good boys and girls in the tech industry. While the origins are murky, it seems to have started around 1992 when a weasel was spotted carrying a Kraft Single. This, they assumed, must be the Cheese Weasel, and therefore, that it must be Cheese Weasel Day. What was the weasel going to do with the cheese? He must be off to put it under the keyboards of good tech workers everywhere.

The practice of the holiday seems to spread through word of mouth. I first heard of it when I showed up to work on April 3rd many years ago and a fantastic spread of exotic cheeses was laid out in the middle of the office. It wasn’t until a few hours later, after the food coma had started to wear down, that I started to think about the legend, “The Cheese Weasel leaves cheese under the keyboards of good tech workers… cheese under the keyboards… keyboards.” I looked, and there was a cheese single, still wrapped. I wonder how long it would have lasted had I not found it.

The holiday does seem to be growing. Each year, more and more sites show up with a reference to the holiday or the song (yes, there is a song). One site even offers Cheese Weasel Day (CWD) ecards. The methods of celebration vary. Some prefer to celebrate with the best cheeses and freshest baguettes, while others eschew that practice and insist on keeping with the tradition of cheese food singles.

For many years, I brought cheese to my office on CWD, but this year, I forgot. I will make amends soon, and you can too. Spread the joy of dairy goodness!

Thanks to John @ crunchgear for reminding me.

The problem is sales! (well, inheritance, but it's not as catchy, so I'll say sales. See this post for more.) Is this because sales people are a bunch of greedy, selfish, blood sucking leeches? Occasionally, but mostly not. Most salespeople worth their frequent flier miles do have some regard for the organizations they work for and the people who will ultimately deliver what they have sold.

I think there are two primary issues. The first is explained by the old adage, "you get what you measure," which could be modified for salespeople as, "you get what you pay for." How are these people typically compensated? Usually, their pay is tied to a percentage of the selling price. So they are incented to sell as much work as possible for as high a price as possible. Nothing in there about project success. There are a few places that do compensate based on customer satisfaction, but few look at the long term success of the project. No one hangs around that long. Can you imagine how things would change if a person's commission was based on client satisfaction, on-time delivery, the final margin, and whether the project met the long term business goals set out in the beginning of the project?

That leads us to the second cause, which I believe is historically long delivery cycles. People are used to long waits in between releases. If it will be a year or more before changes can be made, you better believe I'm going to try and get every feature I can into this release. The irony is that most of these features aren't used. Jim Johnson of the Standish Group noted that 64 percent of the features in a typical system are rarely or never used. (1) On the one hand, that boggles my mind, but on the other, I'm not surprised. Just think of how much faster the next release would come if you didn't have to design and build that 64% of features that will hardly see the gentle click of the mouse.

Here's the rub. Given a fixed time and budget, the more features I want, the less time I have to spend VERIFYING THAT THESE ARE THE RIGHT FEATURES TO BUILD! Let's follow the logic. The longer it is between releases, the more I need done now. The more I need done now, the less time I have to validate that what I'm doing really solves my users' problems. I'm starting to wonder if it's much more than 64% that goes unused. We know intuitively that less is more, but now we attach a business value to it.

The latter is one of those problems that agile/iterative/lean/etc. development is intended to solve. You get less, but at regular intervals.

That begs the question of how can exert influence when we are fighting a poorly conceived compensation structure and the weight of years of experience? Thoughts?

(1) Johnson, "ROI, It's Your Job."

Before jumping on others, assuming this is their fault, let's take a moment and look at ourselves.

My job is to be an advocate for good user experience, but more than that, it's to contribute to a successful project delivery. It's good to remind ourselves, and our team mates, of that. Often, the business owners are concerned with getting their features in the next release, the engineers just want to build something that works, and we want to design the best experience possible. The conflicts are obvious. Something that is important to the business may not be desirable for the users. The great design we come up with may be very difficult to implement.

So step back. We're all in this together.

To be successful, we must balance the business needs, the user needs, and the technical needs. These are the three legs that our project stands on. If one is short, we fall.

This doesn't mean give in to the needs of the other groups. It means show some sympathy for the pressures they face. Try to understand what is driving them and their needs. This helps us make better design proposals and will likely make others more sympathetic to what we are trying to do.

Do you think this is the way to go or are there enough others fighting for what they want and we should defend our turn?

Sorry for the delay in posting. I've been battling the flu for a week now. I'm much better, but not yet healthy. However, I can finally concentrate enough to write something coherent.

First of all, I want to thank those who wrote for their thoughtful and articulate comments. I think you nailed some of the core issues from a variety of perspectives. I won't address all of them individually here, but they will give me material for a number of posts.

To some extent, this has validated, and also refined, my idea of the biggest root cause. What is clear is that it isn't part of the traditional design process. Novel ways to gather user research don't help you convince someone of the need for it in the first place or that a project should sacrifice time used for feature development for validation instead. Improving requirements gathering, use cases/stories, wireframes, etc. aren't what is holding us back.

Initially, I would have said that the root cause was the sales process. That perspective comes mostly from a consultant's point of view, but its the same in product companies as well. Everyone has customers. Sometimes those customers are who you sell your product to. For others, the customers are internal. Before design begins, promises are made. That's where our problems begin. The sales process. The commitment phase. I'll-say-anything-just-sign-here. Whatever you call it, it's a problem of inheritance. We are given conditions to work within that handicap the project before it has even begun.

Do you agree? How much impact do you have upstream on the conditions your design team inherits?

In upcoming posts, we'll look at why this happens and what we can do to effect positive change.

I was going to start out by addressing what I see as the biggest cause of frustration in the course of creating useful, usable, and beautiful work. However, I too have learned from the Zuckerberg fiasco, so I would like to ask you what you think is the most significant root of the problem that prevents you from creating the best solution. Leave your thoughts as comments. After a few days, I'll see how your experiences compare with mine and post some thoughts.