Dilbert saves the Agile day

Agitma

Introduction

Business people are completely different than us. Their point of view is sometimes so far away from ours, that in the end, there might be no overlap at all. Every domain has its own principles, its own constants, and that’s why we must setup a common ground, in order to achieve productive communication and it the end quality software.

My truth, your truth

Before setting up any principles with people different than you, the first step to identify their truth, their principles that lead them to design/build/work. For business people those pillars are for sure two: time and money. Yes, those two! Of course there are more, but but the last square will always be those two. Do you know what programmers hate? Deadlines (time)! Although this sound totally against the every day’s life of a programmer, it is true. And the reason is simple. We are craftsmen, not a factory’s production line. And as craftsmen we have one principal, a principal to rule all the others in software development, and this one is software quality. If your house constructor needs more time to finish building you will him all the time he asked, even under pressure. I am sure, no one of us would live to an half built home.

Communication breakdown!*

So what is wrong? What happens and we deliver bad software? We can’t blame the tech stacks any more. We have powerful languages, libraries, cloud, tasks automation, experience and knowledge to solve almost any known problem in the business world (AI is still on the go). So what is left to check? What is always has been the problem! People!

Businesses do not always define IT services. It’s more a perception question than a size one. And after one is defined, someone has to explain to the IT guys what to do. In all of cases, the IT department has not a clear view of what the business does, and is unaware of the business priorities. A lot of business people, consider the IT department as a black box. They don’t care how they work, they just expect the final result (software) and clients happy! Well, software development is not a vending machine!

On the other hand, the IT department needs to know what the company does. Let’s take under consideration the following example: A company named iBuildBuildings is mixing cement. The cement takes less than an hour to harden once it’s mixed, and it has to get where it’s going before that. A client called in because he was having trouble dispatching the truck and the IT guy says, “I’m going to lunch. I’ll deal with it when I get back.” That’s showing he didn’t understand that it hardens.

No matter how good your software is, or if the server was 100% up all year long, the cement guy doesn’t care about that. Well he should, but in that specific moment, the problem, was not the bug in the software, bug the IT guy who didn’t care about the business needs.

I am IT, can I contribute to business?

A lot of business decisions are made upon IT feedback. Is this good or bad? It depends. If everybody knows their places, their responsibilities, their goals, their limits, the business needs, then probably is good. If not, then we have communication breakdown.

When an IT guy talks to a business one, he has to speak in terms of money and time, not in technical terms.

For example:

A small deliver company that is called iDeliverEverythingAndEverywher wanted to update their smartphones. If the IT department is trying to contribute by talking on smartphone CPU speed, version, OS it will achieve nothing. It has to speak in business terms. To explain that the new smartphones can handle GPS better, and will speed up deliveries.

A lot of times, the IT guys make things more complex and tend to cause more problems in the business, than they solve.

Time is killing software quality, for the sake of money

Everyday thousands, maybe millions, decisions are made in the is fashion. But let’s set the record straight here. Any software that is developed with the wrong people, with less people, with ambiguous or half described requirements, underfunded and with time pressure is gonna suck big time. An application of that kind doesn’t create problems only at the moment, but for the future times to come, by generating a technical debt.

For a company that doesn’t have a lot of time, money or people, any decisions on software implementation must be extremely lean. No one can afford to waste a huge amount of time and money, thinking about processes that give no value to the business or to the clients.

If it is not clear, what the process does and what will offer to the business value, there is no time wasting on thinking about that. Also half solutions must be avoided. They are worst than taking no decisions at all.

Only the processes that are going to have a measurable impact matter. Once the strategy is laid out, you can understand the process, you can see what needs to be worked on.

That is way software development must NOT be a black box for business people. Time and money are wasted on wrong decisions that were meant to be right.

*https://en.wikipedia.org/wiki/Communication_Breakdown

Conclusions

In the end what really matters is to initially understand what is the problem that needs be solved? But processes have not value if the principles are not defined. All parts must contribute, but on the same principles. The goal view must be same and must not deviates influenced by the department you come from.