“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 / Product Management
Posted on:
Agile Cadabra
Agile is not magical. Changing from a waterfall process to an agile process changes how your team works, and helps eliminate inefficiencies. Adopting an agile process does not let you magically have a more successful product. What makes agile powerful is also makes it dangerous.
Agile / Communication / Prioritization / Product Management / Product Strategy / Requirements gathering / Software development
Posted on:
Whole Product Game
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.
Agile / Ishikawa Diagram / Kano Analysis / Product Management / Requirements / Requirements Models / Software development / Uncategorized
Posted on:
Why Do Products Fail? – Incomplete Solutions
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.
Agile / People management / Process Improvement / Software development
Posted on:
Specializing Generalist
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.
Agile / Business Analysis / Prioritization / Process Improvement / Product Management / Project Management / Requirements / ROI / Software development / User Stories
Posted on:
Agile Estimation, Prediction, and Commitment
Your boss wants a commitment. You want to offer a prediction. Agile, you say, only allows you to estimate and predict – not to commit. “Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.” There’s […]
Agile / Business Analysis / Requirements / Requirements Models / Software development / User Stories
Posted on:
Agile Documentation
Agile values working software over comprehensive documentation – it is 1/4th of the original manifesto. That doesn’t mean don’t document! It means don’t document more than you need to document. Documentation does have value, but the practice of documenting got excessive – that’s why a reaction to the bad stuff […]
Agile / Software development / UX
Posted on:
Good Stuff on Agile and UXD
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.
Agile / Business Analysis / Business Rules / Interaction design / Interface Design / Product Management / Requirements / Requirements gathering / Software development / Uncategorized / UX
Posted on:
A Prototype is Worth a Thousand Lines of Code
A picture is worth a thousand words. A prototype is worth a thousand lines of code. Two key elements of product management – and of agile development are elicitation and feedback. Low fidelity artifacts can significantly improve both. Polished, codified prototypes can create problems that prevent you from getting the […]