Blog (Right Sidebar)

Some new projects

After a long hiatus, I’m jumping back into the world of content creation. Not only will I be creating more posts for this blog based on my current companies evolution with UX, Agile, & kanban, but I have started a few other initiatives that I wanted to highlight.

Lunch with TED
Lunch with TED is a simple and free way to bring inspiration, perspective, creative thinking, and community to your workplace with very little effort and no money. Simply reserve a room, invite colleagues, and screen a TED talk. I started running them almost two years ago at my last company and have continued at my current company. They are so popular that I decided to share the idea in the hope that others find it useful.

Open Personas Project
A number of years ago, Steve Mulder, author of The User is Always Right, and I came up with the idea for an open source repository of personas. People who had created personas could share them with the broader community, and those who needed a starting point could use personas that had already been vetted to some degree. We can’t do this on our own and are recruiting a team of volunteers to help make it a reality.

FUXT.it
The design community has made so much progress in the past few years. With the success of everything from the iPhone to the Nest, businesses are realizing that good design sells. Sadly, there are still a lot of experiences that are not just bad, they are FUXT. You can help end these travesties by calling them out and publicly shaming them on FUXT.it. Don’t let bad design go unpunished.

Only You Care How It’s Built

Remember the last time you were really frustrated when using something? It didn’t work as you expected or you couldn’t find what you were looking for. As your attention focused on the people who built the tortuous tool, do you remember thinking to yourself, “That’s OK. I hear they have a great process.” No? The unfortunate truth is that the people you are building for will not care how you got there, only whether you solved one of their problems in a positive way.

I think this is one of the reasons behind the first agile value, “Individuals and interactions over processes and tools”. It is tempting, when integrating new practices, such as with scrum, to get caught up in the mechanics of a new process. There are new ways of working and new tools to learn, and these can take a lot of time, energy, and focus. It can be tempting to do things ‘by the book’ when first starting out, but that puts our focus on the wrong goal. The team is not there to perfect a process, but to deliver value to real people.

So why “Individuals and interactions,” and not “results”? Results don’t make a product, people do. The people are the invisible force that create the product. As one of the agile principles states, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Pixar’s Randy Nelson has a fantastic definition of collaboration not as cooperation, but amplification. A good team that works well together will amplify each others’ skills and abilities to create better results than they would as individuals. This definitely resonates with my personal experience. My best ideas usually come when I’m engaged with others, not when I’m by myself. Sure, I have a few Eureka! moments wearing headphones, pushing pixels, but the bulk of them come from the interaction with other minds approaching the problem from different directions, each with their unique personal history.

There are many elements that create an environment that a allows a team to succeed. As implied above, clear goals and measurable results is one. I’ll go into that and a few more in a future post. In the meantime, what is it about your environment that supports or hinders your team? Do you have motivated people? Do your stakeholders trust you to make decisions on their behalf? Are you focused on value? What have you changed about your environment that has had a positive impact?

As always, I look forward to your comments. Also, please take a moment to rate this post by clicking the stars below the title. It helps me know if I’m on the right track and I really appreciate the feedback. If there is a specific topic you’d like me to address, add it to the Suggest a Topic page.

When Adding Waste isn’t Waste

Naresh Jain over at Managed Chaos was griping about The Bloat Effect. The gist is that as time moves on, everything gets bigger and more bloated, including the software, the team, and the process. This makes everything less valuable as a result.

There is often waste in our process. Sometimes it’s given to us and we have to deal with it. Occasionally we introduce it willingly. Often, we start out bloated. We may have an idea of what the streamlined, efficient process looks like, but it’s not what we adopt. Often there are good reasons, or at least reasons. We are, after all, smart, intentional people.

First of all, a definition of waste. Anything that does not directly add value to the customer is waste. Anything that causes you to spend more time than is necessary, is waste. Anything built but not used is waste. Anything that hinders progress is waste. A common goal of any process is to minimize waste, but sometimes we need it. Sometimes waste in the micro saves work in the macro. Waterfall is kinda like this. The theory is that the more you can remove uncertainty with upfront work, the smoother the project will be, ultimately saving time than if the project had tripped over some of the intricacies later in the cycle, or at least having predictable results with predictable resources. Of course, we know how well that usually works out. Agile aims to minimize all of this waste through multiple iterations and is comfortable with whatever revisions may be necessary later on, based on what we learn.

Recognize the role that waste is playing.

If you are being asked to do something you consider unnecessary, find out what need it is filling. If there isn’t one, you may have an argument for eliminating the task. If there is, you may be able to find a leaner way to solve that need. If you don’t have the authority to make the change, you may have to figure out who in the organization can and convince them. Unfortunately, waste is often thrust upon us with no recourse. Then it’s back to a software version of the serenity prayer, accepting what we can’t change and working on what we can. Sometimes that’s just just ‘how it’s done’.

However, you may choose to add steps into your own process to save time later on. If you experience a frequent roadblock that causes a lot of churn, you may need to add extra steps upfront to deal with it. For example, if you have difficulty communicating new concepts to key stakeholders, perhaps more time needs to be spent fleshing out those ideas before they are presented, especially if you believe that they are justified by the business and user needs. Do you spend time that feels unnecessary? What steps could you take earlier to minimize this unnecessary expenditure of effort? Would the trade-off be worth it?

Simplify as you go

Even if you can’t immediately change the process, you can work to simplify over time. Just because there may be legitimate reasons why you live with the excess now, don’t let that keep you from working to improve the process. This is one of the 12 principles of behind the Agile Manifesto. Can you take a small step the next sprint, or the next release, to streamline? Can you keep educating those insisting on inefficient methods in better processes? Is it waste or is it really saving you time later on? People may be hanging on to tools and processes that they are familiar and comfortable with. Moving them away from them too quickly may be difficult or undesirable in the short term. As you demonstrate success, you will have the freedom and trust to make changes and put past process attachments to rest.

Is it Agile?

As you evolve as a team, you may encounter people who tell you that, ‘You’re not Agile.’ They may be right. You may not be capital-A Agile, but I think the key questions are:

1. Are we doing better this sprint than last sprint?
2. Are we making changes that we expect will enable us to perform better in the next sprint?

Adding value

To often I’m concerned less with removing steps than with adding them. It seems common to encounter an engineering team that has been using agile without the benefit of UX and now they are experiencing some pain. There is often the misconception that waste is anything that is not working code. At the recent Deep Agile Conference, James Coplien indicated that, “Rework in implementation is waste, rework in design is agile.” Adding in a quick usability test to uncover design flaws early is not an outdated process to be slowly abandoned. It is a positive practice that should be introduced where it is lacking. Engage with your users, gather feedback on your product/designs, measure your results. These are steps that do not directly contribute to customer value, but they are some key elements that form the foundation of a solid product. Waste needs to be looked at in the context of the entire product, not just the tasks that any one individual or team are performing.

Failure: The Secret to Success

Honda has produced a series of short ‘documentaries’ promoting Honda innovation. I’m usually quite critical about this kind marketing content masquerading as entertainment, but having watched two so far, I can say they are well produced, engaging,  and only tangentially talk about Honda.

This one is about failure. I don’t think about failure much, even though some might consider that I’ve been around it quite a bit. Many companies that I’ve worked for didn’t make it, or had to cut back during hard times, but I never thought of them as failures. With each one, I often had great results with my piece of the company puzzle, met brilliant and talented people, and learned a hell of a lot. For me personally, that’s a success.

Projects come and go. I try and make sure that whatever I spend my time on is going to give me a great experience, draw on my strengths and knowledge, and give me new challenges to learn from. If it doesn’t work out, I’m very disappointed, but I take what I’ve learned to the next opportunity.

Oh, and it needs to  pay the mortgage. Can’t forget that one.

From Salon (login or adroll required) via Neelakantan at Interim Thoughts.

If you are an older subscirber, please update your RSS feed, or if you haven’t yet, subscribe to this blog’s RSS feed. Don’t know what RSS is? Check this out for an explanation of RSS.

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.

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.

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?