Software product success.
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.
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 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 […]
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.
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 […]
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 […]
Almost everything I’ve read about use cases focuses on describing what needs to be added to your product. Agile development says “get it working first, make it better second.” That means changing the way the software enables a user to do something they can already do. How do you manage […]
Each requirement you write represents a single market need, that you either satisfy or fail to satisfy. A well written requirement is independently deliverable and represents an incremental increase in the value of your software. That is the definition of an atomic requirement. Read on to see why atomic requirements […]
Every team that transitions to agile faces this problem – some stories are too big to fit in a single sprint. Most of the teams that I have worked with have the wrong instinct – to solve half of the problem for all users. The right approach is to first […]
