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.

The more you know who you are and what you want, the less you let things upset you.

Bob Harris – Lost in translation (2003)
Image from FocusFeatures

Introduction

For the past, almost, two years, I have been working in H2020 EU projects. In simple terms this means that I participate in consortiums with partners from all around the European Union, so I have to use my English language skills almost every day.

My mother tongue is Greek, so my English is not perfect. But I try, and I try a lot my speaking and my writing to be as correct as possible. I try to improve daily as much as possible, and the reason is simple: I am a professional, and there is no room for excuses!

Usual excuses

• Lack of opportunities to practice English.You can watch a movie, read a book, or find people online to practice it!
  
• Lack of time. This is the biggest excuse ever! Instead of using the Spanish or Italian or whatever translations of a technical manual, use the English version. Grammar, vocabulary, terminology are all in there.
  
• Not understanding everything. Well, you understand some or a lot!, So engage into the conversation, make mistakes and improve your English language skills!
  
• No one corrects me. Besides the fact that you can find a tutor to support you, practicing and checking now and then a grammar and a vocabulary book will actually help you a lot you to make less mistakes.

The impact

Not improving your English language lead to bad professional impact. It’s not that it makes it more difficult to communicate with your current partners, but keeps you away from the labor market, at least the part of it you are interested in.

I could write down at least three to four examples, of failed communications cause the other party didn’t speak English. And those incidents didn’t occur to a small local city but in the center of Brussels!

And to be totally honest, English is not enough anymore. Speaking languages like German, Chinese, Russian, Spanish is a huge advantage. And the reason for learning those languages is simple: Those languages are spoken to many countries that are markets to services and products provided by the companies you probably want to work for.

Conclusions

Don’t keep yourself out the IT industry, or any industry. English is nowadays part of the basic skills, not the extras. Even I, at the age of the 36 I am planning to take German language courses.