Last year I wrote about the power of 1% improvement, and how powerful this can be when that improvement occurs frequently. For example, if a team improves 1% a week then over the course of 50 weeks (a year) they would improve by over 62%.
A few days ago I had a revelation: the opposite is also true.
If a team enters a downward spiral then a 1% decline in productivity each week has similar effects but in the opposite direction. In fact, as I think about this I see more and more occasions where a team can loose small amounts of performance which actually saps their productive capacity. Like the frog in hot water they don’t realise they are cooked until it is too late.
The graph above shows what happens to value-add over a year when a team is 1% less productive each week. The blue bars show how value-add falls each week. The red line shows how each week the team declines slightly compared to the week before.
That the red line get higher seems odd but it makes sense: each week the team is 1% less productive than the week before. So at the end of the second week the team is 1% less productive than they were in the first week. At the end of week 50 they are 1% less productive than week 49 but only 0.62% more less productive than week 1 because the 1% decline was from a lower total. Getting worse slows down because the team are worse!
At some point the value-add ceases to justify the cost of the team. But as these changes are very gradual that is going to be hard to see.
Why might this happen? – lots of reasons
First off there are the corporate drains on productivity. Consider corporate security processes: think about passwords alone, the need to change passwords regularly, have longer and longer passwords, have different passwords on different systems, and so on. Sure cyber security is important but it can also be a drain on productivity.
Then there are the other hassles of working almost anywhere: finding meeting rooms, booking meeting rooms, setting up webex conference calls, “cake in the kitchen”, restrictions on internet use – whether it is limited access, site blacklists, or authorised “white list” sites only.
It is easy to see how a large corporate can gradually drain a team. But there are other reasons.
There are personal drains on productivity too. Consider internet use during work time. The likes of Facebook, LinkedIn and Twitter which aim to keep you on their sites as long as possible. Using LinkedIn is almost a necessity in modern work – got a meeting coming up? someone applied for a job? looking for a lead? – but once your in, Microsoft wants to keep you there.
Then think about your code base: is the code getting better or worse?
- Easier to work with or harder to work with?
- Do you write an automated test for every change? Or save time today at the cost of time tomorrow, and the next day, and the day after, and …
- Do you take time to refactor every time you make a change? or are you constantly kludging it and making the next change slightly harder?
Notice here I’m not talking about those big time consuming changes that happen occasionally: new employees, reorganisations, mergers – things that happen occasionally, take a chunk of time but finish.
So, is your work environment getting a little bit better every week? or a little bit harder?
If we think at the “very little” level it is unlikely that things are the same as last week. Staying the same will be hard. Things are probably a little bit better or a little bit harder. Extend that over a year and – as the theory of 1% change shows – things are a lot worse, or maybe a lot better.
What is important is the trend, and the trend is going to be set by the culture. Do you have a culture of small improvements? Or an acceptance of small degradation?
Finally, because there are so many minor factors that can sap your productivity capacity then it is quite likely that if you aren’t getting more productive then you are getting less. In other words, you need to be working to improve just to stand still.
| Published on Java Code Geeks with permission by Allan Kelly, partner at our JCG program. See the original article here: Agile won the war but lost the peace Opinions expressed by Java Code Geeks contributors are their own. |
