Adapt & Enable

The beer coaster analysis

Written by Tom Princen | 27 November 2014

It’s Monday morning and the daily scrum just took place. An analyst got the task to dig into a problem. He eagerly starts working on it at his desk, digging deep into the issue trying to make it crystal clear. Doing everything he can; creating diagrams, modeling, drawing, … Putting in time and effort. The analyst goes to the developer’s desk to discuss the fruits of his labor. While going through the entire stack of documents, he figures out that all he needed were some quick sketches on a the back of beer coaster. So where did he go wrong?

He didn’t ask what his audience needed

Check with your audience what they need before you start digging into something. Start thinking outside-in. Understand your customers (developers, technical architects,...) and make sure to have a good grasp on how they will use your documents.

He didn’t ask which analysis steps were useful

I do not like over-analysing a problem. One of the most important lessons I learned is to ask myself these questions before starting on a task:

  • Is the task I am going to do necessary?
  • Does my customer really need what I am doing?
  • Do I really understand the problem?

Start by thinking about what you're doing and whether it’s useful.

He went too far trying to clarify the solution

Tune your product, figure out some way to make the problem or solution clear. It’s all about balancing what is appropriate for the situation. If there is a lot of haziness and the developer doesn’t know where or how to start; something more than a beer coaster will be required.

Indeed building a cathedral will require a 'slightly' different analysis than building a summer house.

He wasn’t pragmatic

Getting something clear is not simple. There are a lot of philosophies, techniques, tools and conventions available to clarify something. Domain Driven Design, Catalysis approach, UML and many more. You name it. But keep in mind: it’s not because some methodology tells you to create a use case or draw an information model that you should. These are only tools that make you think about a problem from more than one perspective. Documenting just for the sake of documenting does not add any value.

So don’t forget

It’s a common pitfall to over-analyse a problem or to misjudge your customer's needs through lack of clear communication.

So be careful, there are a million things you can do with your limited time. Spend it wisely.