In a comment on my last blog entry, Thomas Ponnet reminded me of something I experienced during my years at the university while I was working in a local shop. By that time I was responsible for ordering beer and non-alcoholic soft-drinks, and getting them into the shelves. We had a weekly ordering cycle, and some of the better brands needed to be ordered in large amounts and refilled over the course of the week – i.e. directly before the weekend.

My direct superior switched jobs to another shop, and we got a new superior. The first thing our new boss changed, was the responsibility for all orders in the food department. Just the new boss and his substitute would make all the orders in the department. Groceries, meat, alcoholic and non-alcoholic drinks, etc. We were asked to simply fill the shelves, and keep the shop beautiful.

Now, think shortly over how this felt. Our self-responsibility was taken away. This resulted in a more senior student temp to quit. The new orders from his new boss were just too ridiculous to stay there any longer. I decided to stay, but I also got the exceptional status to still order goods myself. So, in order to demoralize a team completely, just take their self-responsibility and observe the degeneration. This holds for teams in your local shops as well as for software development teams.

Now, over time I observed the other areas, where I wasn’t mainly responsible, but helped to fill in the shelves from time to time. The food substitute ordered more and more goods. The problem was, that the substitute did no longer have the time to do the refills. Over time she was simply noting down the orders during her shifts. The problem was, that she started to make mistakes based on the time pressure I think she had to finish all these orders off in the time given to her. So, time pressure resulted in more human errors. Sounds natural, doesn’t it? This also holds for software development teams, doesn’t it?

What then happened, was striking me. We noticed all the errors the substitute made during noting down the orders. Since we took the new goods and put them in the shelves, we noticed there were blanks after we finished, and there were remains we needed to carry over to storage in the back – hopefully the remains would fit into the shelves in a week or so. But, instead, the substitute while noting down the orders for the next week, saw the blank place on the shelf. She then did the same mistake again, ordering just those goods, that were full and we had still some remains in the storage, instead of the product that was actually missing. Since she didn’t have the feedback from her orders, they got worse and worse, ever resulting in larger and larger piles in the storage. Over the course of a year the remains in the storage raised by a factor of four.

What I learned over the course of two to three years by then was, that people responsible for a job have to get the feedback of their actions. This holds for shop ordering teams in the same ways as for software development teams. Without the feedback on problems and errors, I cannot learn to avoid these errors the next time. I will be pretty oblivious to my courses of actions. In the software world, there are several things we may pile up. Maybe it’s a large test suite with unreasonable execution time, maybe we pile up Technical Debt, or maybe we pile up Design Debt, or, or, or…

This is why Agile development teams iterate and reflect. They get their feedback regularly and decide how to adapt to problems and new situations regularly. That feedback is crucial, don’t remove that feedback from your teams – and please leave them their responsibility.