bookmark_borderDevelopers, developers, developers, developers!

You are a dev. You find a job. You get a PC. It’s slow. It lacks the software which allows you to be productive. Half of the internet is blocked. You can’t choose your favorite keyboard or mouse or chair. Sounds familiar?

5S

Japan has a fascinating culture. Esthetics, order, industriousness are its strengths. One of the biggest achievements of modern Japan is its automotive industry. American car manufacturing companies, with the great Detroit and Ford’s assembly line, have been one of the landmarks of USA industrial power. These enterprises had decades of experience, America won the war but despite this in the 80s Japanese took over the automotive industry. Toyota production system became famous and the whole world looked at Japanese organizational techniques to find inspiration.

One of the elements of Japanese culture in this field is 5S. Long story short, it’s the organization of a workplace where:

  • useless tools and items are removed
  • unnecessary move and effort of workers is minimized
  • workplaces are kept tidy and organized

Implementing these principles helps to create a safe and effective workplace. It improves the efficiency of a whole company without putting a strain on workers.

Alcoa

Alcoa is one of the biggest aluminum producers in the world. Charles Duhigg in his famous book, the Power of Habit, described an interesting story about the company. Once upon a time, the new CEO has been nominated. His name was Paul O’Neill. He shocked stakeholders on his inauguration speech because instead of describing his plan to increase effectiveness, profit, and reduce cost, he gave a talk about increasing workplace safety.

 O’Neill managed Alcoa from 1987 to 1999. During that time period, the market capitalization skyrocketed from 3 to 27 billion USD, while net income went up from 200 million to almost 1.5 billion USD.

Was it money saved on industrial accidents?

Obviously not. The money was wasted because of bad organization. Workplaces have been badly organized, they posed risk for workers, reporting the problems was far from perfect and the whole organization suffered. O’Neill has introduced the pressure for improvement of the production process. Workplace safety was metrics of perfection. As we can see from the results – it was a proper one.

The workplace of software engineer

Software development and IT industries obsessed with optimization. New frameworks which allows us to work faster. New processors, more RAM, more storage. Faster algorithms. CPUs generating more FPS. We continuously believe that we can make anything better, quicker, cheaper and more efficient.

A software engineer, when confronted with the job, tries to optimize it. If the tasks are repeatable, a developer will try to automate it. If something takes too long, the engineer will figure out how to do it quicker, using a different approach.

What then can be more annoying and demotivating for a developer than the situation where something slows him down and he can’t get rid of it!

The amount of these obstacles is surprisingly substantial in most corporate workplaces. Let me give you a few examples:

  • our development workstation has too less memory / too slow processor / too small hard drive
  • the internet connection is slow (for example due to proxy)
  • antivirus software dramatically slows down our computer
  • company policy blocks some pages (for example youtube, where we can find a tutorial to solve the technical issue)
  • granting access rights takes ages (for example, to perform some task we need access to system X, but it must be accepted by three managers, which takes three weeks and blocks our)
  • the company does not buy some tools or does it very slowly (for example we need a new testing tool in a week when we start the project, but we can order only during next fiscal year starting next few months)
  • repairing broken hardware takes very long (personally I waited two weeks until my workstation has been fixed)

I remember one manager in a big company wondering how it’s possible that startups are more efficient while they have smaller budgets so theoretically they should have worse engineers. My experience tells me the reason is the corporate inertia, when all the procedures mentioned above slow down everything sometimes to gargantuan extent.

Flow

Except for technical aspects, we need to remember also about the ergonomics of the developer’s workplace. Many companies buy the same chairs, keyboards, desks, monitors, and other gear for all employees. It’s understandable and usually, these things are of good quality. However, there always be some amount of people – some unusually short, others obese, tall or sensitive – who will suffer from these default solutions. They will have headaches, sore eyes, the pain of their wrists. You can be sure they will have a problem doing the most important thing in the work of the developer – to focus.

The software engineer, who doesn’t focus, burns company money. Getting the flow is not as easy as going to the office every day. Talkative colleagues, lots of meetings interrupting our focus during the day, uncomfortable chair – all of this can ruin our flow.

Developer eXperience

User experience became big thing. Every company knows now how important UX is and almost all enterprises producing software have UX experts in their teams.

Analogically we should adopt the idea of developer experience, DX. The lower developer experience in the company and project, the more money will be burned, the staff turnover will be greater and the team’s output will be minuscule. On the other hand – awesome developer experience will bring us great experts at a lower price, will give us a productivity boost and we will not need to constantly recruit new team members because old ones decided to quit.

Last but not least, let’s remember – Microsoft always cared about developers 🙂

bookmark_borderDaily at 9 AM

A software house is not a convenient store. The work can start pretty much at any time. What’s important is that people who perform the tasks together can communicate, meet, and share their thoughts. This flexibility is important because the chronotype is said to be like a human height – you can’t change it without breaking a bone.

What is chronotype?

Chronotype is being a night owl or the morning bird – it’s the preference of the organism to wake up early or stay late. Apparently, in traditionally living tribes it breaks down so that about 25% of the population likes nightlife, 25% morning, and the rest something in between. This would serve the survival of the group because at every moment of the night and day there is someone who watches.

So we have Mark, who gets up at 5 AM and Bill, who falls asleep at 1 AM. Theoretically, they both have flexible working hours and must meet from time to time on a call.

Then scrum master sets up the daily scrum meeting at 9 AM.

Mark is cool, he comes at 7 AM, he will eat breakfast, he will poop, he will browse cat pictures on the Internet and he is ready and fresh for confession from yesterday’s tasks.

Bill, on the other hand, gets up sleepy every business day, because he would like to come at 12 and cannot sleep earlier. Frustration grows, and IQ decreases. He sleeps well only on weekends and holidays. Every morning he’s in a hurry, sleepy at this damn daily and the whole day too. In addition, the team looks at him crookedly. Lazy, late, sleepy, cursed black sheep!

Meanwhile, research suggests that the night owls are more intelligent, not lazy: https://www.psychologytoday.com/us/blog/the-scientific-fundamentalist/201005/why-night-owls-are-more-intelligent-morning -larks

This seemingly unimportant organizational habit – organizing daily at 9 AM – drives the significant part of the team inefficient. How much of it depends on luck, but statistically around a quarter. There’s no reason why daily meetings can’t be scheduled at the end of the day or in the middle of it. It is simply a habit, a ritual that has spread and is mimicked in a reckless way.

To sum up: when organizing a scrum team, it is worth paying attention to the preferences of its members regarding the hours in which the meetings are to take place. This also applies to meetings at around lunchtime, when some people may simply die of hunger because of discussions lasting several hours.

Early daily scrum meetings can reduce the performance of the team as long as any night owls are the members. It is worth remembering.