Ninsky

Steve Raeburn's thoughts on Agile, Software Development & Life

December 28, 2011
by Steve Raeburn
0 comments

Scrum Product Owner

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

 

December 13, 2011
by Steve Raeburn
0 comments

When to use spikes

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.

December 7, 2011
by Steve Raeburn
0 comments

Agile vs Lean Startup

Joshua Kerievsky compares Agile Vs. Lean Startup

Agile Lean Startup
Product Roadmap Business Model Canvas
Product Vision Product Market Fit
Release Plan Minimal Viable Product
Sprint Kanban
Sprint Review Pivot or Persevere Decision
On-Site Customer “Get Out Of The Building”
User Story Hypothesis
Backlog “To Learn” List
Definition of Done Validated Learning
Red-Green-Refactor Learn-Measure-Build
Customer Feedback Customer Validation
Acceptance Test Split Test
Velocity AARRR
Mock Object Feature Fake
Continuous Integration Continuous Deployment
Certified Scrum Master Customer Success Manager

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

December 6, 2011
by Steve Raeburn
0 comments

How to stop projects failing

Tom DeMarco hits the nail on the head again.

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