Archives for category: Agile Methodology

A few years ago, I was working on a project that was easily the most complex interaction design that I or my team had ever worked on. It was filled with “interesting moments” where timing, feedback and responsiveness were absolutely critical. The team had been used to a fairly typical design and development process. A PM would set the scope, a designer would create static wireframes, iterate on them a bit and then deliver final designs to development that were not supposed to change. These were the final designs, after all.

We had recently adopted Agile development and so the question for me was, when are you going to “get to done” on the design? My answer was honest but, at the time, not appreciated. I said:

A design is never done, it only approaches done. *

I knew what the reaction would be — What the hell are you talking about? Something is either done or it isn’t! We’ll never ship! You’re going to ruin everything!!

But I still stand by that statement, even more now than I did then. It is foolish to think that you will get the design right the first time. It is also foolish to think that there won’t be changes to a design once development begins. And on a larger scale, software products are never done unless they are dead. Life is better when you stop kidding yourself and your team and admit that there is no “done”.

As a design manager, I use this concept of approaching done to evaluate the health of a project and the effectiveness of its designer. A designer is on the right path when his or her solution is approaching done. In the early stages of a project, there is typically a high level of variability. Designs may appear to be approaching done only to get completely reset once a new requirement or constraint is encountered. This is completely normal. But over time, this variability should become smaller and smaller. That is when you know a design is on the right path. There is a steady progression toward done.

* This idea of approaching done was inspired by some bastardization of what I remember from calculus class and the limit of a function. It may have come to me in a fever dream.

Recommended Reading

There are some compatible ideas in the Lean UX arena. If you’re interested in learning more, I suggest checking out the following sources:

A fascinating study conducted by Saras Sarasvathy, a professor at the University of Virginia’s Darden School of Business, describes how successful entrepreneurs approach a hypothetical business problem versus their corporate counterparts.

What struck me about the study is how much the entrepreneurial way of thinking maps to good design and Agile thinking. Namely, the approach of these very successful entrepreneurs is focused on doing — not waiting, analyzing and debating. Said one entrepreneur:

You have to take some risks. You can sit and analyze these different markets forever and ever and ever, and you’d get all these wonderful answers, and they still may be wrong.

In my experience, this world view is often shared by successful designers and successful Agile teams. The best way to remove ambiguity from a project is to start it. It’s also the best way to know whether or not your idea will succeed.

We can’t accurately predict the future and we can’t predictably be right the first time, no matter how many spreadsheets and research projects we throw at it. To many people it seems counter-intuitive, but beyond an initial scoping and problem definition, the more up-front work you do attempting to reduce risk actually has the opposite effect — it increases cost and risk.

Inc’s Leigh Buchanan sums up the differences quite nicely:

Corporate managers believe that to the extent they can predict the future, they can control it. Entrepreneurs believe that to the extent they can control the future, they don’t need to predict it.

Read the Inc. Magazine article here.

I’m on my flight back home from an Agile UX retreat at Pivotal Labs in New York City. This is my second event with the group which formed back in January of this year. The group is focused on determining the guiding principles and best practices that result in highly collaborative teams who build great products. 

I didn’t do any tweeting during the event. Instead, I thought I would share the “Tweetable Moments” from my notes here on the blog. 

– The value of narrative is immense. Find the stories.

– Lead with conversation, trail with documentation

– Build shared physical artifacts

– Teams should focus on effectiveness, not efficiency. Effectiveness gains efficiency.

– Don’t lose sight of the product: 
Devs too interested in solving cool problems
Designers too involved in delivering pixel perfect assets

– Always seek to push certainty into the project areas that are uncertain

– The smallest unit of planning is the team, don’t try to break that into design/dev/qa

– Provide just enough information to go and start work

– Staggered sprints are so 2009

– It’s not bad when you fail, it’s bad when you don’t notice that you’ve failed

– The time you spend to reach failure is waste, minimize it

– Practice minimum fidelity prototyping

– Increase the quality of the product, not the quality of the code

– Humans can’t predictably be right the first time (no rock stars!)

– Lean mandates the do-over

– Think, make, check (repeat)

– Separate design risk from development risk

– A prototype is something you can use, a specification is something you can’t

This was truly a great event and it was an honor to participate. Many thanks to Pivotal Labs and @IMF for organizing and hosting!

It’s easy for folks working on a project or running a business to get so wrapped up in process that they lose sight of the actual goal — shipping killer products.

Eric Reiss has written a fantastic post on the topic entitled “In defense of ‘making it up as you go along'”. The post articulates this conundrum better than I could ever hope to:

… I have a lot against creating gameplans that don’t allow for deviation or the unexpected voicing of a sudden brilliant idea that turns the whole project on its head… My problem is with the tyrants who blindly stick to this (or any other established process); who hide their own lack of talent and creative insight behind a veil of pedanticism and false authority.

Sorry Columbus, ignore this new world of yours. Remember, your job is to find a passage to India. What will you do between now and the next daily scrum meeting regarding this project?

I call these tyrants Process Nags. Process Nags are so focused on doing it “the right way” that they forget about the product. They stifle innovation and they destroy the autonomy of the team. For companies focused on innovation (and who isn’t these days) this is a death knell.

The problem is not unique to a particular process or organization. When something is successful, people want to replicate it. That’s logical and natural. But what happens when, as with Agile, you are trying to methodically replicate “making it up as you go along”? Often, you lose the very soul of the idea. Rather than being agile, teams become rigid and fixated on the rules. Process trumps product.

So, how does a team avoid process over product? Have a story. Every team should know what they are building, why they are building it and how to measure success. The story makes this possible. And I’m not talking story in the Agile sense, but rather a narrative. Paint a vision of how your user will interact with this product. What will they do with it that provides tangible value? In the absence of a story, all you have left is a collection of parts (features) and when that’s all you have, a factory floor mentality can set in that focuses almost exclusively on productivity and process.

Good designers are good story tellers and good stories motivate teams. Motivated teams don’t need to focus attention on doing it “the right way” because it just happens. Motivated teams don’t focus on roles and formal processes. Motivated teams just get shit done and leave the Process Nags out of the equation.


I spent the weekend attending the Agile UX Retreat at Cooper in San Francisco. The retreat brought together an impressive mix of designers, user researchers, developers, scrum masters, product owners and quality engineers.

Agile UX RetreatThe central topic of the retreat was how to integrate User Expeience (UX) into the Agile Development Process. At least that was supposed to be the central topic. But somewhere between the afternoon of day 1 and the conclusion of day 2, it became something else entirely. We transcended Agile and UX, we eliminated “us and them” thinking, and we stopped talking about Agile with a capital A. Instead, we focused on what really matters: We all want to make great software… together.

We need to overcome the momentum of tradition
It is time to relieve ourselves of the industrial age thinking that says efficiency is king. It is time for a culture change in software.

  • Efficiency needs to yield to effectiveness
  • Process needs to take a back seat to products
  • Roles need to give way to competencies
  • Egos need to die

We are all makers and craftsmen and facilitators, and when it works well we build killer products that change the world. To hell with tradition. Let’s go make great stuff together!

%d bloggers like this: