In this post it gets a little philosophical. I will take a look at the collaboration between software development and business to see what happens when teams are a little too “nice”.
A Tale of Kant and Coding
For Immanuel Kant, the categorical imperative was the fundamental principle of ethics. Basically, he postulated that each individual should only act in a way that would be OK if it became a general law. So far, so irrelevant for software development. One might think.
Follow me over the next few lines – I will try to show that there actually is an unexpected amount of usefulness in this guiding principle, especially for software developers.
From Idea to Feature
In my consulting projects, I often meet teams that are well educated, experienced, motivated, equipped with the latest tools. And yet these teams can often accomplish little. Why is that?
Each client and each project is unique in itself. However, there are two basic patterns that I would like to introduce to you.
Pattern 1: “Exegesis”
This pattern often occurs when work is not project-driven. In such contexts, development or testing efforts are often seen as utility costs (such as water, gas, electricity…) and are hardly measurable. This dynamic is mainly found in smaller companies with fewer than 50 employees, but larger companies are not immune to this either.
Due to the lack of visibility of our efforts, the various stakeholders resort to local optima, such as…
- The business wants to work more closely with the customer and therefore only invests minimal time and effort in specifications or requirements engineering. This in turn increases the efforts in software development.
- Product owners are urging developers and testers to release early, for example to be able to make it in time for a trade show. This causes increased effort in customer service, later.
Just like water in a river, the effort for specification and validation of requirements “flows” downstream. However, the actual amount of work is always the same, it is only shifted!
This shift does not lead to any increase in efficiency – it only increases the total effort. The reason for this increase is that we force our teams to work with fuzzy inputs – in the area of software development we refer to this as working with incomplete requirements.
Remember the introduction: In line with the principles from the Agile Manifesto, I assume that we employ “motivated individuals” in our teams. These motivated individuals cannot and do not want to simply switch their brains off – after all, we usually pay them for thinking. So the team will invariably fill in any ambiguities in requirements with assumptions. This happens with every linguistic inaccuracy, with every omission of information or specifications.
This set of assumptions made is why I called this pattern “exegesis”. The teams do some sort of interpretation or reverse engineering. You have to painstakingly interpret what was thought and meant upstream, many moons ago.
That is why the rule of ten applies when moving effort to downstream process steps (see [1] for more on that). This is illustrated by the figure below.
With this pattern, what is the probability that the finished product will implement the original idea and meet the business requirements?

Pattern 2: “Chinese Whispers”
This pattern is particularly common among larger companies. Out of fear of chaos, uncertainty and ambiguity, stable processes were introduced (6 Sigma anyone?) and a detailed org chart with clear responsibilities was drawn up. The principle at work here is “divide and conquer”, and what worked well for manufacturing for decades cannot be bad in software development, can it?
On our way from idea to product, however, the following handovers are created (which are often also found verbatim as milestones in the Gantt chart):
- (At the customer) User → Key User → Process Owner → …
- Customer → Account Manager/Project Manager
- Account Manager/Project Manager ↔ Analyst/Lead Developer
- Several loops and iterations, until scope and effort is clear
- Fixed price, fixed scope, fixed delivery date!
- Account Manager/Project Manager → Software Development
- Software Development → Testing/QA
- Testing/QA → IT Operations + Support
Do you notice that no one even speaks to the customer from step 3 onwards?
So you see, there are a lot of handovers – in some of my projects, 10 or more handovers were necessary. Through linguistic transformation processes, this invariably distorts the original idea, because as with pattern 1, any ambiguity is filled with assumptions. Every team member makes assumptions about every requirement in every process step, the blurring grows exponentially:

Again, the question is: What is the probability that the finished product will implement the original idea?
These two patterns are of course a simplified representation of what is really going on. In practice, mixed forms of these two patterns often will occur, but the following applies to all contexts: What does it cost you to re-do features which have already been developed and tested, just because someone has forgotten to provide a small info?
TL;DR
Challenge assumptions! Do you understand the problem that needs to be solved? Why does this user story create added value for the customer? What’s the context of usage?
Hence the reference to Kant in the post’s title – I call this challenging of assumptions the categorical subjunctive: only work with such requests/user stories that can not only be considered a personal favor, but also correspond to a definition of ready, for example.
Wouldn’t it rock if we could replace local optima by joined efforts across the whole value stream? Let’s free up capacity for the development of awesome products!