“Agile” is something most teams do wrong*, without realizing they’re doing it wrong. A good 2×2 matrix acts as a lens, helping to convert information into insight. Let’s apply this lens to agile as applied within a company, and see if it helps people decide to do things differently.
Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. . What makes agile powerful is also makes it dangerous.
How can Theodore Levitt’s classic Whole Product approach help with defining a product roadmap? I’ve been revisiting his concepts and their use recently, thinking about how to revise them for some exercises I’ve been doing with product teams.
There are several ways to answer the question “is agile cheaper than waterfall?” Here are two of my favorites:
“It depends. Agile done well is cheaper, as long as you measure correctly.”
“You’re asking the wrong question. The right question is: is agile better?”
Next up in the series on the root causes of product failure – products that fail because you have ignored the user’s level of experience. The first time someone uses your product, they don’t know anything about it. Did you design your interfaces for new users? After they’ve used it for a while, they get pretty good at using it. How much do you think they like being forced to take baby steps through a guided wizard now?
This article continues the series exploring the root causes of product failure. Even when you target the right users, and identify which of their problems are important to solve, you may still fail to solve the problems sufficiently.
The ideal agile team is made up of specializing generalists – but what does that really mean? The goal isn’t to prevent functional silos of expertise, it is to allow people to cover for each other.
Best practices for user experience design and agile. I don’t have the brainpower at the moment, or the experience and eloquence in general, to say it better than these guys. So this week, I’m phoning it in, and deferring to these folks to say it far better than I can.
I’ve been thinking about the software development process. Big, upfront, design and requirements. User research and analysis. Market insights, gained on exploration or over time. Release cadence – how quickly you get, and incorporate, feedback from your customers about your product. How quickly you react to your competitors’ reactions to your actions.
Satisficing probably makes more sense than perfecting your product.
Are we really saying “don’t make it perfect?” Yup.