I have to admit: I am German. Us Germans are well-known in the world to deliver good results. That said, we are very dedicated to deliver efficient results. There is one thing that troubles me about that. Having our main business in Germany, I often face questions with regards to efficiency while introducing agile methodologies. You can efficiently drive your car right into a wall. That would be very efficient, but unless you try to kill yourself, not very effective. The English saying ‘don’t try to run before you walk’ expresses this gallantly from my point of view. Let’s explore that thought.

Effectiveness is about doing the right thing. While you can jump on a train to get you anywhere, it is usually more helpful to get on the train that drives in the direction of your destination.

Where do we find ineffectiveness in our workplaces?

At a client a few years ago, there were highly political games involved. In order to drive home a decision for a meeting you needed to schedule several 1on1 meetings with the attendees in order to prepare the decision-making process. If you assumed that you could simply meet with the relevant people in one room in order to decide about something, you could find out that your approach was not very effective, having no decision after the meeting at all.

I saw several other coaches in that company that were aware of that. They used 1on1s to prepare the meetings, and the underlying decisions. That approach did not feel very efficient for us coaches, though it was way more effective.

The same holds for software development. Some practices like test-driven development or Exploratory Testing seem to be inefficient. I think this has to do with our engineering tendency to do one thing well. Unfortunately us humans are not like machines. Our brains are highly associative. That means that the direct line between two points does not necessary work best for us. Instead, we sometimes reach our goals by wandering around, getting lost, and returning on our track back.

For TDD this means that the effort of writing a failing unit test first, might look like it’s inefficient. And it is surely less efficient than simply writing down the production alone. However, in the long-run, when the complexity of the growing function, class, and application overwhelms our minds, we are able to rely on this double bookeeping in our code. We are more flexible, and can rely on the safety-net in our code base by executing the tests more often (if they tell us what we need to know). So, in the long-run we are way more efficient if we stick with less efficiency in the beginning.

Counter-intuitive, isn’t it?

Now, consider the overhead of meetings that you introduce when introducing Scrum. There is a planning meeting every two weeks. There is a daily meeting to coordinate daily fuzz. And there are review and retrospective meetings every two weeks as well. With all these meetings, when do we get work done?

It’s the same as with TDD here. The problem with software development is that we have a hard time to see queues in our systems. Unlike a physical engineering project, all the decisions we made are put in a sheer endless storage system – the codebases in our computers. That’s why it’s hard to see queues with large batches piling up.

Unfortunately large batches have the tendency to lead to sub-optimization. With sub-optimization we make more assumptions. With more assumptions we end up with more “wrong guesses”. More wrong guesses means that we will have to more re-work later. So, in short-term we face better efficiency. But since we cannot see the amount of assumptions that floated into that efficiency, we can’t see how wrong we were.

It’s always easier to get the software right the first time. Unfortunately most systems need to be coordinated between several persons nowadays. That also means that we need to talk to other people more often. Without that talking we would be more likely to build more wrong assumptions upon our current wrong assumptions. If you take a closer look into Winston Royce’s paper on waterfall development, you’ll notice that he is stating that this model probably can only work in short cycles. Short meaning two weeks.

Royce understood that the creation of software needs to take frequent coordination among several people. Scrum fixes this misconception in the Waterfall model by introducing more meetings to the workplace. So, the workers who are familiar with traditional style development will find that introduction less efficient. In the long-run those meetings are way more effective since they lead to less rework, and therefore to more efficiency in the long-run.

I think this is why we should focus more outcomes rather than outputs. The outcomes in the long-run can tell us whether we are doing an efficient job. Don’t just focus on the quick-wins as they will lead to sub-optimization. Instead watch out for the results in the long-run, and re-evaluate your underlying models. Eventually you will find out that some things need to appear less efficient to be effective – and therefore more efficient in the long-run.