The Scrum Product Owner has a tough job. Translating business strategy into product strategy and ultimately into teeny-tiny user stories takes a ton of time and effort. Most Product Managers don’t have the time or inclination to be a good Product Owner and most Business Analysts, the people most likely to fill the gap, don’t actually own the product. I almost always recommend to my clients that a team of people work together to fill this role. I don’t really care about the whole ‘single wringable neck’ thing… all I want is well groomed prioritized product backlog, and I think there is more than one way we can get there.

Read more

There are a couple of signs that indicate when running a spike might be valuable:

The team finds it difficult to define clearly or agree on a suitable design or approach and discussion drags on without consensus.

People are reluctant or unwilling to estimate a piece of work, inflate their estimates, or there is a large range in the estimates given.

The system is about to move into a new area and/or a substantial change is forecast.

An issue due to a current design limitation surfaces.

A team member is convinced there is a better way of doing something but the wider team has not bought in.

Discussion is vague, generalizations abound and the conversation lacks data or concrete examples.

via Using Spikes.

Definitely not an either/or situation IMHO, but it’s a useful reference.

What’s really wrong with software folks is that they’re continually beating themselves up for something that’s somebody else’s fault.

He suggests that there are really only two reasons why software projects fail:

1. Either the business failed to recognize the need soon enough, so the project didn’t kick off until it was too late.
2. Or the project was started early enough, but the business value was insufficient to justify the real cost of the project. (Not the mythical planned cost).

He suggest that the first reason is a failure of the business, not a failure of the software development project. There was a real business need, but they spotted it too late.

Of the second reason he observes:

If a project offered a value of 10 times its estimated cost, no one would care if the actual cost to get it done were double the estimate

In other words, the project was doomed before it even started. The lesson then is that projects cannot succeed unless the business learns to a) spot opportunities earlier and b) pick winners with the right ROI. And IT needs to become better consultants in helping them learn those lessons.

Read more

User Stories or Use Cases? Yes!.