The Developer: “Let’s start coding. We don’t have time for solution design.”
The Designer: “No, we should design first. It’s not a waste of time. It will reduce rework.”
The Analyst: “Guys, please! How to start designing, if we don’t know what the problem to be solved is?”
The Tool-lover: “But how to diagnose the problem without a tool? Let’s choose the tool first.”
The Architect: “Yes, but to choose a tool, we first need to make sense of the context and only when we know where we are, we can have criteria for choosing the right tool.”
The Tool-lover: “Doesn’t that mean we need a sense-making tool? Again, as I told you, we need a tool first.”
The Analyst: “No, this just means that we have to first analyse the context of the context. Let’s focus on that.”
The Developer: “20 lines of code ready while you are discussing.”
The Designer: “That’s a waste of time. But you, developers, don’t have a sense of time anyway.”
The Architect: “Time is an interesting thing. Good you mentioned it.”
The Analyst: “Is ‘time’ the problem?”
The Tool-lover: “We probably need a stopwatch.”
The Architect: “What we rather need is to stop and watch.”
… and so on.
This is really a GREAT article.
Like it and agree.
Eddy
From my experiences organize an adequate faciltation/elicitation meeting to get requirements.
In such these meeting each participant use his favorite technique to allow other to visualize and envision a shared understanding ( the requirement of the problem, architecture, security, compliance, business process, etc ). A second will be to agree on an prioritizing points to be done,
in fact the simple way of success is show me don’t byzantine me : the problem, the context, the drivers, the values, etc