Lean UX and Agile: More Content in Less Time

We're going to be talking about principles, not practices. If you take lean or agile as just a set of practices and expect to succeed, you won't.

Productivity is the key, from manufacturing to development. Toyota looked at lean product development and figured out how to produce a new vehicle in one year, as opposed to North American companies taking two to three years. It was not just the manufacturing process. It applies to design. Toyota has a process for inventing things, for how you plan to envent things and put it on a schedule.

Agile programming methods have been applied very badly in many situations. The principles include specify value, identify the value stream, flow, pull, and perfection. The only thing that counts is what adds value to the customer. For example, moving something in a factory is waste. You are always looking for waste, which means you have to know what value is.

We often don't know all the processes that go into something. Identify the whole process by which value gets created. The key principle is flow. You want things to flow smoothly. Nothing is created until it is needed. For that to happen, you need a perfect flow.

In software development, the principles translate too eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity, and see the whole. Why decide as late as possible? The later you make a decision, the more information that decision is based on.

These principles as applied to software development work also on content development.

We want content pull: We won't write soemthing until it's needed.

Taking this approach promotes learning.. Errors are found sooner. Errors in content result from defects in knowledge. The stuff in your head is inventory. Fix the defects in your knowledge so you can produce better content faster. this results is more efficiency--including no crunch at the end of a project.

The sooner you send your content for review, the more errors will be caught. A reviewer reading a book can't see the trees for the forest, but if you send content a chunk at a time, reviewers can focus on the one issue. 

When you send stuff in pieces, it makes people who get it aware that documentation is part of the process. As a result, they are more likely to inform writers of design changes. When you make your doc process more visible, you get more feedback, more support. And that can make you more productive without changing any processes.

Waterfall fails because you're making decisions at the beginning, when you have less information. 

Embrace change. Information increases throughout the process. Rather than building a system that doesn't let change in, build a disciplined process of learning. It means iteration. What is the most efficient way? It's a process that recognizes that you're trying to generate information.

Agile development includes iterative development, user stories, frequent deliveries, keeping your options open, doing the simplest thing that works, refactor constantly. The reason for an iteration is to generate information. And of course, agile content development is similar.

Evenness is the key. Different techniques optimize different parts of the process. Optimize the whole, rather than just the parts.

Best practices aren't best unless they meet your context or your objective.