Who hasn’t been using a taxi service in a foreign country, just to find out that the more inefficient the cab drivers are, the more money they make? They seem to be driving you around forever, and in the evening you look on Google Maps and find out that the shortest trip to your destination should only have taken 10% of the time that you needed. They just get paid more by being inefficient on purpose …
Rewarding inefficiency in software development
In some organisations, the way that software teams are rewarded is not very different than the above taxi case. People who seem to need a ridicilous amount of overtime to get a task done are sometimes receiving the most appreciation and applause. The more cumbersome or time consuming the road to the result, the higher the reward.
I’ve seen this myself, even in large multinationals under the contant burden of being on the stock exchange. You’d expect that these cost-minded organisations should be the last ones on earth to applause for inefficiency… On the contrary, employees working extremely hard without significant results would become employee of the month because of their relentless drive to take the most inefficient route and to work more than 12-13 hours a day in average.
The Agile Perspective
Take a look at the following agile principle:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Note the magical words ‘sustainable’ …. ‘indefinitely’! I still have to meet the person that can keep on spending huge amounts of overtime indefinitely, so the above mentioned “heroism” isn’t really in agreement with this principle.
In the contrary, this kind of heroism is probably mostly found in waterfall projects, at the end of the project, when the deadline is near and desperate measures are taken to get ready in time….
It’s all about results and value
The primary purpose of agile development is to increase value after every iteration. The effort needed is of secondary importance, it doesn’t matter wether you tried very hard when you aren’t able to show any results. (Jedi Master Yoda was clear about this: “Do or do not, there is no try”.)
Not taking the shortest route to a solution is therefore just plain ol’ waste (lean).
Lazy developers will take the shortest route
I’m not talking about procrastination or avoiding work, but when building an agile team, you should focus on a healthy kind of laziness. Developers should take the shortest route to a solution, in a way that they create the most value for a limited amount of effort. The effort should preferably be close to zero when talking about routine tasks. For example, doing repetitive manual data entry tests are a waste of time and material: these should be automated.
How to be lazy in a lean / agile way
- Recurring routine tasks should be automated. Developers should be paid for their brains and not for their hands.
- Don’t write code that already exists, either somewhere else in the organisation or even on the internet. Copy it, tweak it, improve it and move on.
- Ask for help! Don’t try to be a hero by trying to solve a problem yourself, but ask a colleague for advice or help.
- Automate your tests by using a test automation tool like selenium
- Have the team sit close to each other, so that no time is wasted when people want to talk to their colleagues.
- Don’t try to make fancy burndown chart in Excel, using formulas, trendlines, …. but draw the graph by hand using pen and paper.