By now, most organizations should have understood that they have to become more agile in order to stay in business. Like any new trend, people need practice to use it correctly. Some organizations have taken shortcuts and bent the rules of Agile and Scrum, and „forgot“ to think before they started to implement. A software development will seldom be successful without some form of thinking, specification, and documentation. The question is „how much thinking is actually useful?“

In some waterfall-y organizations teams of product managers, business analysts, requirements engineers, and UX designers might exist who each believe that their work is most important and who therefore have no interest in the opinion of the others. Yet, they are all using the same or similar techniques, methods, and tools.

The battle of the methodologies

For years, the different methodologies have battled each other: the International Institute for Business Analysis (IIBA), the International Requirements Engineering Board (IREB), and what was once called the British Council for Science (BCS). I was in the audience of an opinion battle among spokespersons of the three organizations in 2012 at the SAQ Requirements Engineering Forum in Zurich. Each claimed that his organization, certification, and therefore methodology was far better than the others.

In the wake of these battles, some business analysts, requirements engineers, user-centered designers, user experience designers, user interface designers, and so on keep on fighting an open battle as well: „you can do this but not that because that is my job“. Product managers might write requirements. Business analysts might do UI design because they need it to identify requirements from users. Requirements engineers might do user-centered design, talk to users, and do UI design because that is what they need to do to be successful in their job.

In the worst incarnation, each of these methodologies became a silo- and waterfall-like project phase that had to be executed before the next could begin. Instead of collaborating as a team on the solution of a customer’s problem, they worked sequentially producing overlaps and waste.

In 2014, my colleagues and I of the conference board of the then Swiss Requirements Day discussed two questions: „what are requirements?“ and „why do we produce requirements in the first place?“.

The typical answers were something like „to document all requirements towards a system under development“, „to ensure that the system will provide value to its stakeholders“, or „to interpret business language into technical jargon“. Two interesting concepts that we developed that day were „to produce agreement“ and „to mitigate risk“.

Why do we think before the development starts?

If everyone involved in a project, the sponsor, all stakeholders, and all developers would have the same understanding of what needs to be done, then they would have an agreement.

While this approach is possible and sometimes needed, it comes at a certain risk: the risk of misunderstanding which might result in a financial risk.

Over the years, I have come to believe that all of the methodologies should only be executed in order to mitigate some sort of short-term or long-term risk. If we would analyze the above agreement, then we would find that certain areas of the problem are well understood while others are not. It would be an enormous waste of time and energy, if an organization would execute the methodologies when the problem and the solution are crystal clear to everyone and the financial risk is low.

In the summer of 2015, the Swiss Requirements Day re-invented itself in order to again lead the way into a new, agile and collaborative approach for our methodologies. We were only short of a name.

The Birth of Upfront Thinking

In September of 2015, Mike Cohn, one of the founders of the Agile Manifesto, wrote a blog post asking the question „which insurance policies do I need for a certain area in the project at a given time?“.

If we ask this question, then all of the above methodologies and roles become insurance policies. We might buy them in some instances and in others we will not.

Mike called it „Upfront Thinking“.