On the Constraints and Assumptions

I often ponder how most of the time (a lot more than one would think) in a vast variety of situations, private or business-related when dealing with problems, we usually spend our time fighting and resolving the symptoms instead of the real underlying issues.

The Assumptions

Next time you find yourself in an argument or a disagreement with someone try to step back and think — are you really on the same page and dealing with the problem or only its symptom? A good way to validate this is to check your assumptions (on all sides).

According to Goldratt — in nature, contradictions simply do not exist and the source of all disagreements are wrong assumptions. One side thinks this to be true, the other side does not which in reality is impossible. This is why re-evaluating your assumptions tends to put you on the right track.

On this note, I was pondering the ever-present issues in the context of Agile Software Development eg. introducing Scrum, such as:

• Estimation
• Breaking down stories
• Coming up with a goal
• Fitting meaningful work into by-weekly cycles
• etc …

What we usually tend to do is to look into these issues in isolation and get nowhere, but I would even go a step further and argue that even if we consider them in the context of the Scrum itself for example we still do not get far.

Why do you think that is? The wrong assumptions. (which implicitly means implicit preconditions and constraints)

What do I mean by this? More often than not, any methodology has certain assumptions coming along with the motions (eg. processes, artifacts) and the one assumption that is missed very very often is the mindset change.

What happens instead is that we usually only try to apply new processes while holding on to our pre-existing notions of how the world works or how things get done which is destined to fail because we missed the initial assumption which is actually an important precondition for the whole thing to work in the first place. That’s why retros for example won’t work because all you do are small local improvements applied in the wrong system with a wrong set of assumptions. — These issues also stem from the human predisposition to value more the what than the why.

Let’s take the example of the inability to set goals, and fit valuable work into the sprint or estimations.

What usually happens is this:

Someone comes up with pieces of functionality and/or requirements (hopefully of some value)-maybe PO/PM, spends time on it, goes through iterations, and cycles of refinement on a whole vertical from devs to C-level, and ends up with a bunch of backlog items ready to be picked up.

Then when it’s time to do the work, eg. to plan the sprint many issues arise in doing and scheduling the work items. Why is this the case in many instances?

It is again about assumptions and implicit constraints. Usually when we come up with the requirements we do not take into account the timeline or resources needed, but rather we view them as unlimited and defer the capacity/scheduling issues down the pipeline. What this actually does is it makes us start the whole discovery with wrong assumptions, the constraints are simply too loose and utterly nonrealistic.

We need to change our mindset instead and turn things upside down.

The Upside Down

Let me take a step back and provide you with a background story on Empire State Building.

I won’t go too deep into it I would highly advise you to look into it yourself, but in a nutshell, The Empire State Building was built under schedule, under budget in a record time while at the same time achieving its goal of becoming the highest building in the world by surpassing the Chrysler Tower. When I first found out about this I was fascinated and wanted to know how is this possible. What I found out was actually pretty simple (not simple to implement but the idea is pretty simple — simple is rather hard).

What happened there is that they did turn the whole thing up on its head. They started with a goal, a budget, and a timeline — and the only remaining question was what can be done within those constraints? The whole planning stage was executed with those constraints in mind instead of starting with a fleshed-out uninformed, unrealistic plan and trying to cram it into an unrealistic timeline with limited resources.

This is also not something isolated to the Empire State Building but is rather a common thing that many successful projects share.

I would highly recommend looking into the topic it is very eye-opening.

The Punchline

So what is the lesson here? Instead of deferring constraints such as time and manpower, we shift left on them. The question we pose ourselves is: What outcome can be achieved with this timeline in mind (works for any timeline) and this amount of resources? Only then do we start with defining the requirements (instead of cutting them down later and coming up with a mess).

This way we avoid the negotiation mumbo-jumbo later because there is nothing to negotiate or cut down because the stories and requirements were created with proper constraints from the get-go, otherwise all we end up with are simply compromises without really a win-win scenario.

We also avoid the famous “break it down into smaller pieces” because again, there is nothing to break down really. Every time we are faced with the issue of breaking things down what we really want to do is rethink but when we are faced with a situation where we want to rethink and scratch something on what a lot of people already invested a lot of time (and consequently a lot of money) we naturally stumble upon push back. Rather, start with the goal and constraints and set yourself up for success. Coming up with a goal for a bunch of unbounded loosely related work items usually does not work and is telling you that you have it the other way around.

Change the mindset don’t simply rely on implementing different motions, that won’t get you far. Most of the time when you satisfy these base conditions other stuff seems to fall in place. Also, ask “Why”? If you don’t know the why and only know the what, most of the time something is horribly wrong and you are probably only achieving a small percentage of your otherwise vast potential.