Integrating solve and do

The industrial age divided our world into white-collar and blue-collar workers. Those with white collars went to college, worked in an office, solved problems, and made decisions. Those with blue collars went to high school or trade school, worked in a factory, performed work, and followed orders. “Solve” was separated from “do”.

But in our contemporary world of knowledge workers, very little of it can be teased into separate “solve versus do”. Today, doing is an integral part of solving, and solving is an integral part of doing. We are all “no-collar” workers: smart, well-educated, solving problems, and performing work.

The successes by state-of-the-art practitioners in both agile development methods and UX have given rise to a desire for more effective collaboration. Once a programmer has seen what well-applied agile methods can accomplish, she soon begins to yearn for a better user-facing strategy. Likewise, once a designer has seen what good interaction design methods can accomplish, he soon desires to work with a strong development team open to collaboration.

Many advanced thinkers have already tried a first order solution: agile programmers have requested input from designers, and UX designers have attempted to squeeze their work into the timeboxed cycles of agilistas. The results have been promising, tantalizing, but somehow not quite there yet. It has become clear that while both UX and agile are effective methods, a combined “agile-UX” method will be something different from—something beyond—a simple addition of the two.

This past weekend, in a creatively messy office space in Tribeca, two dozen such advanced thinkers got together for the third installment of a working group dedicated to addressing this worthy challenge.

The group, which calls itself the “Agile UX Retreat”, consists of about 50 people, who borrow time away from work to participate. The group actively seeks and invites promising newcomers, but there is a core of twenty or so who attend every meeting.

At last week’s third meeting, the group shifted into a higher gear and made remarkable progress. They weren’t so much “post-agile” or “post-UX”, as they were “post-doctrine” and “post-hostility”. The thinking, speaking, and exchange of ideas, vision, and practice was not only of a remarkable quality, but it consistently transcended its component pieces. Beyond talk of design or agile, beyond talk of design and agile, the talk was of what the organization can be—and must be—when everyone in it is committed to the principles of user-centered, collaborative, iterative teamwork.

Much of the gruntwork of figuring out how this new organization works is being done by the “lean startup” folks, spearheaded by the likes of Eric Ries and Steve Blank. Lean startup has really only been practiced in tiny little startup companies, where, when you talk to the “product owner”, you really are talking to the product owner. While this is only a microcosm of the larger corporate reality, it is a valuable test-tube in which experiments can be conducted. In other words, we can learn a hell of a lot about how to run a big company by seeing how this stuff works in little companies.

But the core ideas of lean startup aren’t so much new as they are simply the beliefs of agile and UX, brought together effectively in a business context. Half of the lean startup’s principles are bedrock to agilists, while the other half are foundational to user experience professionals.

Not just the designers and not just the programmers, but everyone has to center their work on satisfying the customers. You need to have sublime confidence that the only way to deliver a successful product or service is by first delivering some version that is wrong, or at least, not quite right. That is, success on the first try is not within the capabilities of humans. Iteration and incrementing are integral parts of a post-industrial approach to product development.

At the union of “solve” and “do” we find the definition of the twenty-first-century business. Even though we are still at the beginning of this journey, it’s clear that we are finally on the right track.

Related reading

Alan Cooper
Alan Cooper

Alan Cooper is the co-founder of Cooper and a pioneer of the modern computing era. He created the programming language Visual Basic and wrote industry-standard books on design practice like “About Face.”

Learn more

Subscribe to our mailing list and stay up to date on our latest thought leadership and learning opportunities.

Connect with us

Want to know how we can help your company drive real business progress?

Let’s talk

Stay up to date on our latest thought leadership and learning opportunities