Blog (Right Sidebar)

Is ‘Good Enough’ Good Enough?

Fast, good, and cheap. Pick two.fastgoodcheap

This is the familiar instruction represented by the project triangle. A project that is of high quality and delivered quickly will be costly. One that is done well with limited resources will likely take time. An inexpensive project delivered quickly will suffer in its execution. Keeping this in mind, compare waterfall with agile.

Waterfall demands a certain level of quality. All of the upfront research and design, as well as the many gates and checkpoints insure that when the product is released, it meets the expectations defined up front. Waterfall projects can be good and fast, or good and cheap, but the underlying notion is good. Now, experience tells us that the definition of ‘good’ can vary greatly on waterfall projects. ‘Good’ can mean that the end users find the product useful and usable, or that the project is predictable, i.e. that the budget is met with the expected scope, or that the target date is hit and the expectations of scope are managed. I’m sure each of you has experienced many variations on what stakeholders consider ‘good’.

Agile chooses fast and cheap. Sprints are short and teams are small. There are many good reasons for this. They are well documented elsewhere, and include getting working software to users faster, being able to address high priority problems quickly, and abandoning features with little value. With this approach, the mantra for each sprint is ‘good enough’. When choosing fast and cheap, what is sacrificed will be quality. At least initially, this may be true, but agile counters this by adding many revisions following quickly on the heels of an initial release. Problems can be quickly identified and fixed in the next release, which may be as little as two weeks away.

This requires a significant shift in thinking for User Experience. It is our job to ensure that the users have something they find valuable and easy to use. We think big thoughts about mental models and context and integrate detailed thoughts on layout and implications. We have been accustomed to defining the entire picture, making sure all the pieces fit, before moving on. It can be very challenging to take one piece of a larger project and just get it to ‘good enough’ while ignoring the rest of the system. We are judged on how the product looks and behaves. Sacrifices made for expediency affect our credibility and reputation.

We also may have different ideas of what constitutes ‘good enough’. To a prototypical engineer, it may mean that the feature is present and functional. For UX, it’s about utility and ease. A product owner may fall somewhere in the middle. Its important for each team to agree on their shared definition of ‘good enough’. If forced to work under the simplest extreme of ‘functional’, we may not be pleased, but at least our target is clear and we know what to work towards.

This change in thinking is a key challenge to successfully integrating UX and agile. One approach is define a rough, high-level vision so that all involved can get a sense of the whole. During each sprint, or prior to each sprint, fill in the details of the pieces, or stories, about to be built. It won’t guarantee that there won’t be rework, but it will help balance the need for holism with the need for speed. If you don’t get it right this time, there’s always next release.

Adopting Agile is Hard

Before getting into the details of our particular challenges, I wanted to acknowledge, for all of you going through this, that adopting agile is hard, perhaps one of the biggest professional hurdles I’ve faced in recent history. While I’ve been in the same industry for about 12 years now, I imagine this is about as close as you can come to switching careers without actually doing it. You think you know what’s going on, but the rug keeps getting pulled out from under you. However, I also like the term ‘adopting’ because this is similar to adding a child to your family.

When you have a kid, your life is no longer the same. You’ll sleep less. There will be lots of screaming, and you will have to clean up more crap than ever before. Moving to an agile process seems a lot like that. The hope is that once you figure it out, life is better and you wonder how you ever lived without it.

Even reading about agile can be as confusing as negotiating the parenting section of a bookstore. Want to know how to get your baby to sleep at night? Here are 20 books that all say something different. Want to adopt an agile process? Here are multiple options, each with different interpretations.

To be fair, the looseness of agile, and scrum in particular, is one of the things I like most about it, and what also causes the most pain. If you were to ask a personified scrum process what to do, the answer would likely be, “It depends.” It may be true, but it doesn’t feel helpful.

Agile is more of a philosophy than a process. It dictates very little. We have five scrum teams working concurrently and each one works a little differently. One team has a number of outsourced members across the globe. Two others are working on entirely new initiatives The last two are refining existing parts of the site, although they move from making small tweaks to significant additions or revisions. Some teams do more costing and planning for each sprint, while others are very loose. Each of these teams have developed their own idiosyncratic scrum process that works with their unique situation. This is one of the powerful elements of the agile methodology, the flexibility. It is also one of the biggest challenges. Teams must define their process for themselves. Scrum only provides a framework. Each team is trying to do what is best for their people and their project, but it can be very difficult to work across multiple teams that are working differently.

There seems to be a sense of the serenity prayer to it. Agile is a new process and will require a lot of change. However, realize what you won’t be able to change and find a way to work within those constraints. I appreciate that this process acknowledges the realities of organizations and attempts to work with them. I found Ken Schwaber’s book Agile Project Management with Scrum very helpful in demonstrating this. In this book, Ken presents case studies of teams in different circumstances at different companies. In one case study, knowing that the program management office required Microsoft Project files for status reporting, the Product Owner adapted scrum reporting to fit within Project’s framework. Rather than trying to get another part of the organization to adapt in a futile battle against the windmills, teams in this book found ways to improve their process while working with the constraints they had to live with.

So if this feels painful or impossible, that’s normal. It means that you’re going through change. Recently, our Program Manager and resident certified Scrum Master attended a conference with two major agile gurus. After listening to the other people describe their problems, he says that he came away feeling that we are doing quite well compared to a lot of other companies! Given how hard it has been for us, I really feel for those who are not quite as far along the path.

As we figure things out, I’ll share what I can. Until then, if you have any questions, I may respond with, “It depends.”

If there is something particular that you would like me to write about, visit the Suggest a Topic page. You can vote on existing topics or add your own. I’ll do my best to address them in a reasonable time frame.

Agile and User Experience

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?

Pulling the what?

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.

The gang tries to pull Pooh out of Rabbit's house

The gang tries to pull Pooh out of Rabbit's house

Ira Glass, Killer

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?

Where’s the fire?

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.

I Forgot!!! Happy Cheese Weasel Day!

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.

Pointing the Finger

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.”

Balance

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?

Inheritance

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.