For those of you who are unfamiliar with Parkinson’s Law, it states that:
“work expands so as to fill the time available for its completion”
based on the theory first derived by a British naval historian called Cyril Northcote Parkinson, following his extensive experience in the British Civil Service. Parkinson observed how a simple administrative task tended to expand in both complexity and organisational bureaucracy to meet a time-box that was allocated to it.
Here is a simple example. Do you remember being set homework during the school holidays? At the end of school in July, I usually had six weeks off school during the summer months. But I was also given homework to do before school recommenced in September (BOO!!). Given that the homework might have taken only 2 or 3 days to complete, how long do you think it took me to finish my homework?
That’s right… 6 weeks. The whole summer. And I would still be rushing to finish it off the night before I went back to school!!
This is Parkinson’s Law in action. And we see it almost everyday of our professional and personal lives. In this blog post, I will try and weigh up the pros and cons of where Parkinson’s Law might be in play for scrum and agile teams.
I am a notorious procrastinator. I tend to delay starting tasks. I have a tendency to leave decisions and actions until later. I am aware that will increase my stress levels at the time I need to work on them, but I tend to de-prioritise tasks that don’t need my attention right now.
But from a lean perspective, that can be an advantage. In software, by leaving decisions until late we can minimise the cost of change by not having to redesign existing features which will have to change later. However, it is very difficult to pinpoint exactly when the “last responsible moment” to do this is – until it’s too late.
Using my homework as an example, if I estimate that my homework will take me 2 or 3 days to complete – the last responsible moment to start my homework would be maybe the Friday before I return to school on Monday. However, if that estimate is inaccurate (which it inevitably will be) and the homework turns out to be more difficult or time-consuming, or something else more exciting comes up, finishing the homework is much more at risk than it would have been if I had started it earlier in the holidays.
So surely procrastination must be a bad thing – it increases risk and potentially rushing towards a deadline and dropping quality to get past the post. And Scrum helps us by putting sprints in place to prevent Parkinson’s Law coming into effect by focussing teams on delivering in smaller increments to get feedback on completed tasks.
But is it all bad?
In his fascinating TED talk, Adam Grant describes how some of the greatest creators of our time were in fact procrastinators. Leonardo Da Vinci took 16 years to finish painting the Mona Lisa. He continually doubted himself and his ability, but that process allowed him to improve his work and create a masterpiece. Procrastination or thinking about a task more thoroughly allows you time to be open to new possibilities. New ways of solving the task.
Grant suggests that original thinkers are quick to start an idea, but slow to finish it – in order to take on feedback and be willing to adjust to improve. That extra time will invoke what Grant refers to as “self-doubt” when we start to analyse our own ability to complete the task – but we need the strength of character to push through and complete the task in hand.
(The Creative Process as described in Adam Grant’s TED talk, but I have seen it elsewhere many times, but I can’t find the original source…)
In my opinion, we need to be aware of how Parkinson’s Law might be helpful as well as a hinderance. One of the primary benefits of the Scrum framework is that it jolts a team into shorter feedback loops – thus preventing the team (and consequently the product) from slowing and coasting towards an incorrect target. These deliberate constraints should prevent Parkinson’s Law from kicking in.
However…
My point here is that we might not ALWAYS want the team to speed up and find the answers fast – despite the fact than many organisations see “agile” as purely that. As a facilitator we may want the team to slow their thinking and delay decisions until a later point – in order to allow more information or ideas to surface. I see “short” sprint planning meetings as a good example of where finishing planning early and getting on with the sprint may not necessarily be what is needed. Is that extra time to examine other design options a waste? Have we fully explored the task in hand? Maybe not…
In his first book Agile Software Development with Scrum, Ken Schwaber was insistent of a sprint length of 30 calendar days, and he described those first Scrum teams as “hotbeds of creativity”. In the last 20 years, we have seen two weeks sprints emerge as a norm and 30-day sprints are seen as the exception. I do wonder if longer sprints give a little more bandwidth for “the creative process” to take place, and maybe teams have been too quick to write-off Parkinson’s Law as a bad idea.
As an aside, how long do you think it took me to write this blog post? ?
Agilify offers training, consultancy and coaching for individuals, teams and organisations to help understand and embrace an agile approach to product delivery.
