35 person-years worth of prototype is a fantastic spec

I once invested 35 person-years worth of effort on prototyping. From my perspective this was time and money well invested. By the end of that time we knew, really knew, what problems our customers were facing and how to solve them.
Continue reading

Solution Convergence: Marrying Business, User Experience and Technical Input

My product owner was upset when I told her she couldn’t have the widget that she had agreed with the User Experience (UX) Designer. The problem was the design was not technically feasible. To get a great solution to meet the business requirements three parties – business, user experience and technical – must agree on the approach. That negotiation is what I call “Solution Convergence”.
Continue reading

Build it Twice then Build it again – the 3rd Version Will be Great

It is not something I want to say to a new client, but even before we touch a line of code, I know it will be the third version of their new product that will be great. The first two versions will serve their purpose but will be at just okay from a user’s perspective.
Continue reading

How to Manage a Vague or Dynamic Product Backlog

In response to my request for questions along the lines of what do I do when … ? Jo asked:

What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.

In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:

  1. Normally vague/dynamic
  2. Completely vague
  3. Massively dynamic

The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.

The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.
Continue reading

Reinforcing Success in Products and Projects

A fundamental military axiom is to reinforce success.

Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.

Wikipedia: Reinforcing Success

I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading

Requirements: State the Problem not the Solution

We all do it. Even those of us, like myself, who should know better do it occasionally. But it is wrong. Or if "wrong" is too strong a word, then it is at least misguided.

What is it? It is the habit of stating a solution when we should be explaining the problem. This habit isn’t confined to a specific role; I’ve seen all members of the team do this … users, product managers, project managers, business analysts, technical architects, developers, user experience designers, testers, and management stakeholders.
Continue reading