Archive for June, 2014

The Problem Space

Monday, June 30, 2014
posted by daveb


Guess which requirement was written by a solution-space thinker, and which was written by a problem-space thinker:

Requirement A: As the Iceberg Manager I need to receive timely (same day) notice when an iceberg breaks free of the ice shelf so that a decision can be made on whether or not to track it.

Requirement B: As the Iceberg Manager I need the system to provide an online form for the Iceberg Scientists to fill in when an iceberg breaks free of the ice shelf.

The trouble is, requirements like B seem to riddle project/product backlogs. It is solution-space thinking, and its poor work if done by a professional Business Analyst. (As an aside, if your Business Analyst or Product Owner writes requirements like B above, you need to tell them, or at least tell the Project Manager, that the whole team is being excluded from the creative process by such “requirements”.) Its leads us to a solution, short circuiting the potential to explore the problem from the many creative angles that a typical software development team is capable of. It fails to describe the nuances of the problem at all.

On a project team, this effectively shuts down all creative thinking, except that which comes from the Business Analyst. Software Developers, Testers, Technical Writers and other technical people are intelligent and creative people – that’s how that got where they are. It’s a terrible shame to exclude them from the creative process, and the quality of work, not to mention the morale, of the team will suffer greatly. Business Analysts and Product Owners are creative intelligent thinkers too, but we really need them to take on the role of defining the problem as clearly as possible. There’s no reason they can’t be part of the solution design, but their first job is to define the problem-space clearly. And when they move into the solution-space, they should expect their voice to be one of many, and that it should carry no particular authority over the team.

Hence we need the Business Analyst or Product Owner more than ever to think in the problem-space. If you don’t have a dedicated Business Analyst or Product Owner on your team, you have to be especially careful to avoid the traps of premature solution-space thinking, which frequently happens when a team of solutionists hear about a problem that needs solving. Being solutionists, we like our solution to be the one that gets implemented. This means we have to be quick to voice our solution as early as possible in order to get the buy-in of the other team members. This is wrong-headed in itself and is a sign that a team is a group of competitive, self-interested individuals rather a team at all. But worst of all, it drives the team to bypass the stage of really thinking about, and analyzing, the problem-space properly. And when we do that, we risk it all. We risk solving the wrong problem, or completely missing simple solutions, in favor of those that first come to mind, or those that are the easier to convince the team to agree to.

I’ve been involved in plenty of projects where I’ve worked directly with the customer / entrepreneur / stakeholders, without a Business Analyst in the middle, so this is nothing new. However, I have come to value the input a good Business Analyst brings to the project more and more over the years.

There’s a point made clearly in the Lean software development process that goes something like this: “The largest source of waste in software projects is building the wrong thing”.

Its kind of obvious when you think about it – should your team spend 3 months building a solution that does not solve the business need, and does not end up getting used, you’ve wasted 3 months effort. Its as if you achieved nothing at all in 3 months. You would have been better to send the whole project team away for a 3 month (paid) holiday. At least then they would have come back fresh and full of new energy. But I digress.

Getting back to the Business Analyst (or the equivalent person in the problem-space mindset), the value they add is having a mindset purely focused on the problem-space. We in technology are so deeply involved in the solution-space that we find it hard to work in the problem-space in an open minded way. When technologists, project manager’s, and others embedded in the solution-space attempt to write requirements that define the problem-space, we do a rotten job because we usually have a solution in mind as we are writing. We then reverse-engineer the requirements from the solution such that the reader will be led towards our solution. Exploring the problem-space fully is essential if we are to be lean, because being lean means building the right thing, and building the minimal thing that will solve the problem. Defined that way, we’d be well advised to be very critical of the definition of the problem in the first place. One poorly chosen word might lead us towards unnecessary complexity.

So where have we got to with all this? We solutionists should take all requirements with a grain of salt. Requirements need to be criticized, questioned and tested (even if only though thought experiments), because it is essential to get the definition of the problem as accurate as possible, and free from mis-interpretation. This precludes us from jumping into solution-mode too early. We need to take on the responsibility to shake down the requirements, and we should be among the harshest critics of the requirements. Only when requirements survive this test, and the scrutiny of the entire team and stakeholders should solution-space thinking begin.