Translation of “How we got rid of time reports” by Henrik Kniberg

How we got rid of reports on completed work

The story of getting rid of a waste of time

Introduction

Have you ever had to work with progress reports? Fill them out? Approve them? Carry them around the office?
Was it like spending time to good?

Statement 1 : Progress reports are sometimes useful.
Statement 2 : But very often nothing like this.

History

Once upon a time there was a software development company and I got a job as the head of the development department.
It was an interesting and cool job, but one of my weekly irritants was the obligation to collect and approve reports on completed work. Dozens and dozens of reports, hundreds of pieces of paper. One of the concerns of the personnel department was to kick me, so that I would submit reports on time, and, accordingly, I had to kick my developers about this every week.

It was annoying. Not only because it simply took time and distracted everyone, but also because my work on “approving” reports was mostly a guessing game. I had no working ways to find out if the report is correct. It was all annoying, but not enough to start fussing about it - I was a beginner here and wanted to concentrate on more problematic things.

One of the biggest problems was that people "worked hard to death." Many developers looked like pale ghosts; they were already in the office in the morning when I arrived, and still stuck there when I left in the evening. One of the key developers even managed to send a statement for a holiday for the coming Saturday. I thought that he mixed up and entered the wrong date, but it turned out that he had been working all weekend for several weeks, and really wanted to go home for at least one day this weekend. Saturday's leave statement was a ridiculous but very effective way to point out a serious problem.

Why, then, the Planning and Accounting module did not issue any Warning about the Dead Death of an Earned Developer? If this module cannot even do such a simple and important thing, what the hell is it at all? Imagine an airplane or a nuclear power plant with a trendy monitoring system that records all the possible information, but never warns when something obviously goes wrong ...

Fortunately, I could see the signs of this Warning, and so, since I was sitting with the developers ( And I was glad that I refused the personal room in the office, which I was offered at the beginning).

For a long time, for a short time, but after a few weeks the main problems were already more or less under control, so I got to the reports on the work done. By that time, I had to do a lot of different reports, but apart from all the shortcomings of this, there was one advantage: there was no place for other wasteful procedures.

The reports on the completed work not only annoyed me, I was curious. Why do we need them? Where do they come from and where do they go then? So I started asking.

My boss (CEO) said that they need accounting. Accounting said, they are needed by the personnel department. The personnel department said that they are needed by the company, which we outsourced payroll. Etc. This became my background project - when I had a bit of time, I continued my investigation of “Secrets of Progress Reports”.

In the end, I found out what was happening with the papers. After a series of hand-to-hand transfers, they ended their lives in that outsourcing company where each report was manually hammered into an electronic personnel accounting system.
Hmm ...



Mdaaaaaaa ...

Well, that is, I mean that in general it is not very effective.

Being an IT geek in my heart, I immediately started thinking about how to simplify the process. So, each developer can fill out their work online, their local team lead also looks at all the reports online and clicks OK to approve them, then I look at the high-level results and also click OK to accept them and all this is sent automatically by the outsourcing company. Wow, everything is pretty smooth. Hmm, maybe connect this system to Eclipse so that it automatically logs the time in the work performed, depending on which development project is open on the computer? Maybe we can immediately integrate directly with the personnel accounting system used by the outsourcing company? This is likely to fall well on the SOA ...
Wait.

“There is nothing more useless than doing effectively what you don’t need to do at all”
- Peter Drucker

I reminded myself that my initial question was the Effectiveness of reports on completed work, and not their Efficency.

• Performance - the ratio of the output of the system to its input.
  Example: The number of lines of code per hour.
• Efficiency is the quality of the ability to produce the desired results.
  Example: ROI per release.

I still did not know why the reports on completed work were used. The answers I received were often stupid of the type “we must fill in the work done, because this is our standard” (that is, the type “we must, because we must”). What they just didn’t tell me about the reports on the work done, but what I really wanted to know was why these numbers were needed.

So I began to ask questions differently. Instead of asking “Why do I need reports on completed work,” I began to ask, “What happens if we“ lose ”reports” or “What happens if we“ inadvertently ”generate report contents randomly.”

As a result, the real purpose of the reports surfaced. The main reason why they were used is to calculate how much to pay compensation for processing. There were other goals, but they were already covered by other reports. So the only important goal was precisely the calculation for processing. And, they were also needed to calculate the “flex time”, a tradition of the Swedish industry, which, in fact, allows people to come to work sometimes later, if the other day they arrived early. Progress reports were used to confirm that everything sums up at least 40 hours a week + X, where X is overtime.

The sweet taste of truth.

Now, armed with Truth, I gathered several developers and asked them a rhetorical question - “do you like to fill out reports on the work done”? The expression on their faces was the answer that I needed:



Then I continued like this:

“Now we use these reports to calculate overtime. But filling out reports is dull, and working overtime is even more dull. We all know that one hour of energetic, motivated, focused development is more beneficial than a whole week of zombie coding. ”

(Offhand, I don’t remember a single specific link, well, I’ve already lost track of studies that show that the relationship between the duration of the work week and the value produced is small or not, at least when it comes to creative work such as software development. Motivation is important. and focus, not hours).

“So what is the offer. No more reports. And there’s no more overtime. From today, Overtime means “Work when you don’t want to.” If you are demotivated or tired, go home. If you want to linger and hang around because you are "in the stream" - linger. This is not overtime. If you feel that you have been working late for several days, take a day off. If the week turned out to be slow - catch up on Saturday, if you want. Find your rhythm, find the rhythm of your team. "

“Of course, sometimes there can be exceptions. In such cases, the traditional processing compensation system will work. We will try to minimize such cases and deal with them in each case. If in doubt, call me. ”

“Manage for the normal and treat exceptions as exceptional”
- Edwards Deming

“Well, finally. I don’t care how many hours per week you work, as long as it roughly corresponds to standard full time. It worries me that you are focused and motivated when you work. Can I trust you to take this responsibly? ”

Everyone nods enthusiastically.

I gathered courage, went to the CEO, and told him that we would no longer send reports on the work done. The dialogue went something like this:

Me: “We will no longer send reports on the work performed”
CEO: “Why?”
Me: “This is a waste of time.”
CEO: “But the personnel department will not be upset?”
I: “I will give them what they need in a more efficient way.”
CEO: "Ok, cool."
Wow, that was easier than I expected. I got ready for a variety of issues ... That CEO liked me: o)
Then I went to the staff.
Me: "We will no longer send reports on completed work."
Personnel: “But you must. This is the standard! ”
I:“ The standard is changing, I just talked with the CEO ”(Well, yes, I lied a little, I admit).
Personnel: “How do we now know how much to pay people?”
Me: “You have everyone's employment contracts. Just pay everyone their normal monthly salary. ”
Personnel: “What's the matter with overtime?”
Me: “There will be almost no more. If it does, I will let you know. The rest of the time, count 40 hours a week. ”
Personnel: “But we don’t want to change our procedures and standards, maybe you will just send reports as before?”
Me: “I can make them automatically generated 40 hours a week and automatically sent to you by mail every week. Do you need this? ”
Personnel:“ Hmm, it turns out pretty stupid. ”
Me: “Well then, I will not send them. If you want to. You can assume that you receive a pack of 40-hour reports from us, and enter this all into the system, as you usually do. We’ll scribble less paper, and you will no longer have to kick me for late reports. ”
Personnel: "Ok, rightly so, let's try."
No one else stuttered about reports on completed work.

Moral of history

1. Many organizations uselessly spend a lot of time performing all kinds of procedures prescribed by the standards - various useless rules, practices and procedures. Take a fresh look at this. Take it positively - these are good opportunities for improvement.
2. Even the most useless at first glance procedure has a goal.
3. If you encounter resistance to refusing a useless procedure, find its cause. Find out what needs this procedure closes. Offer a less costly and useless way to close this need.
4. Be persistent. It takes time to eliminate the procedure, which is deeply “ingrained” in the organization.
5. Do not blame the predecessors who introduced this procedure. Most likely, this was a good solution to a real problem in the past. Although it might not have been. In general, this is not important, focus on the future.
   “Things are the way they are because they got that way” - Jerry Weinberg
6. Do not confuse efficiency with performance. Focus first on efficiency, and only then on productivity.
7. An hour is a measure of effort, not a measure of value.

FAQ

After something like overtime, didn’t this lead to the fact that you began to do less time

Well, that led to less code being written. Less Bad Code. Less important code. Less trash. And therefore, less time for catching bugs, for answering panic calls to the support service when the system crashed, for supporting the list of bugs, for issuing corrections and for decrypting the crooked code.

And that means more time to write a Good Code.

We all noticed a clear and marked improvement in productivity after abandoning overtime. Productivity in terms of user value per unit of time.

Didn’t you ever need to take into account the hours worked?

Oh, sometimes there are completely correct reasons for knowing how much time is spent on a particular project, for example, if there is an external client who needs to be billed. But this is easy to do without reports on completed work. If one team of 8 people spent 3 sprints working on project X, and each sprint took 2 weeks, then we can roughly assume that 8 people worked full time for 3 × 2 weeks. Total 40 hours x 6 weeks x 8 people = 1920 hours. True, it may be that they spend part of their time supporting product Y at the same time. In this case, in each retrospective, I ask the team to roughly estimate what percentage of the time they worked on Project Y, for example, 80% / 20%. It’s quite easy to take this into account in the calculations.

Some teams do this every day - before going home, each team member puts a mark on the chart on the board, roughly distributing their time for the day for different jobs. This gives even greater accuracy, at the same time at low cost.

However, I would be more careful here. Multitasking is usually a very bad idea. If we have to create a complex system in order to take into account exactly how people allocate their time to projects, then we are definitely not focusing on that — we should fix the problem (doing too many projects at once in parallel) and not the symptom (problems taking into account the work performed )

Suppose I spent Monday working on four different projects, 2 hours on each, 8 hours in total. I will mark 2 hours for each project in the system of accounting for completed work, but with all these “context switches” the effective time will most likely be closer to 30-60 minutes per project. So most of the day wasted.

A time tracking system that spends a waste of time is itself a waste of time.
If everyone works on only one project at a time, then learning the work done becomes trivial.

Is it possible that some developers have stopped receiving a lot of money for overtime?

I raised salaries so that overtime compensation is no longer the driving force. The increase was significant in many cases. No one complained about it, no one suggested switching to the old system.

Studies show that monetary incentives can make productivity worse, and not better, when it comes to such complex and creative work as software development. Instead, just pay people enough so they don’t think about money. Here is a short and very cool presentation on this subject, must-see, - Drive: The surprising truth about what motivates us.

Paying people for overtight was one of the stupidest things of all, it just gave us very tired developers and a “technical debt” (a lot of crooked code, imperfections, etc., postponed for later)

What happened next?

I wrote the book “Scrum and XP from the trenches”. To my surprise, it became very popular in the developer community (I wrote it more for myself, just to get all my thoughts out of my head on paper) and since then I have already lost track of people from all over the world who told me that my book inspired change them the way they organize their software development process. Very cool, thanks for the feedback!

This article is just another side of that story. The most important thing is that we could never do what we did if we didn’t continue to constantly aggressively clean up all the waste of time we encountered (reports on completed work were just one example). Hmm ... why did the word “Lean” immediately pop up in my head? : o)

It was all in 2006. Since then, I have never touched or filled out any hours table - even despite the fact that I have been consulting for the last 4 years. If a future client raises this question, then I will find out his real need and find an alternative way to close it.