My takeaways from spec by example with Gojko Adzic

Last Thursday Valtech invited Gojko Adzic for a one day workshop called “Winning big with specifications by example”. First of all I thourally enjoyed the workshop. I already knew from previous encounters with Gojko at NDC2011 that he was a very engaging speaking and he delivered this time as well. During the 9 months since I saw him last time I’ve been in a project where many of the ideas from spec by examples are used on a daily basis so the workshop in many ways acted as a reassurance that we’re on the right track. Obviously we’re not perfect and the thing I’d like us to focus on in the near future is the way we look at and handle requirements.

People tend to bring solutions

For quite natural reason people when faced with a problem try to figure out a solution to that problem. If the solution involved some sort of software development they’ll likely come to you and ask you to build the solution for them. The import thing here is not do accept this “solution” at face value but rather figure out what the problem is they want solved with the proposed solution. Think of it this way: if the person asking had sufficient knowledge about IT to select the best solution, why would they need you?

Follow the money

When digging for requirements, keep asking why until the answer is “it saves money”, “it makes money” or “it protects money”. If the person you’re asking can’t answer it probably means that you’re talking to some middle manager and you need to move up in the hierarchy until you get to the money.

Effect mapping

One way to handle the scenarios above is to “reverse engineer” the solution offered and then follow the money until you reach the actual business goal. When you have the goal you can use effect mapping (or other similar techniques) to quickly brain storm around possible solutions. Luckily for all of us Gojko has made a paper available on effect mapping that I highly recommend reading.