Parkinson’s Law – “Work expands so as to fill the time available for its completion” – Cyril Northcote Parkinson
Your agile team can be following 99% of the principles and practices behind Scrum, XP, and/or Kanban and yet still working at half efficiency, or worse, due to Parkinson’s Law.
There is very little in the prescribed principles and practices that directly address the efficiency of executing tasks, save the concept of eliminating waste, but even that usually centers on eliminating workflow waste, not task or work item waste.
The good news is that while your agile team may have tremendous untapped potential, realizing that potential may be as simple as setting up the right environment for them.
It is a natural human behavior to allow work to fill the time allotted. We have all done it. The reasons are many and various: Overanalysis, not balancing task elements across the work item, struggling with a blocker without asking for help, procrastination, lack of a desire to work faster, lack of motivation, distractions, not managing interrupts well, multitasking, and so on.
Note that every one of those behaviors can be identified and remedied. But where to start?
Empowering Agile Teams
The first place to begin to solve the Parkinson’s Law problem is with empowerment. An unempowered agile team is a team that doesn’t care. And that is a prescription for a bad case of Parkinson’s.
Here is one recipe for curing Parkinson’s within an agile team. The order is logical: Start where the answer to the leading question is “yes” and work downward:
- Have non-team members (by “non-team members” here, I mean anyone other than the team; it could be any level of management, the client, the business, the PMO, etc.) set an unrealistic goal for the project? This situation will make people feel that they have no control and that if the project fails, it is someone else to blame. A solution may be to improve transparency around the release burnup. Is there a release burnup? If not, start there.
- Create a clear burnup from empirical velocity and an agreed-upon backlog and distribute it to all stakeholders.
- Make sure that the release backlog is reasonably well sized.
- Make sure that the velocity is based on empirical data, not wishful thinking.
- Ensure that the burnup accurately reflects the backlog and velocity.
- Make sure that everyone sees it – client, PMO, business stakeholders, various management levels, other potentially impacted teams. Obfuscation occurs when different groups use different artifacts to present information, so ensure that they are all using the same artifact.
- Are non team-members selecting the stories to be run each sprint? This can serve to prevent the team from feeling ownership.
Tip: Put the Team in Charge of Their Commitment
- Stop the practice of external story selection and have the team select only enough stories to get to the point that they feel that they can commit to complete those stories and not one more.
- Have a discussion around the meaning of “commitment.” Make sure that this is one of those things that require unanimous team agreement, like a jury. There are some decisions that can be made by a democratic majority, others that are okay to be made by an oligarchy. But, commitment to a Sprint plan should be unanimous across the entire team. Without that unequivocal commitment, unspoken naysay remains unchallenged, that could spoil morale right when you need it.
- Then, during the planning session, ask for that one-by-one commitment to the sprint.
- Is a “chicken” (e.g. project manager who is not part of the team) selecting work for people, assigning tasks, assigning story owners, assigning roles? How can they possibly know better than each team member how what tasks are needed for each story and how long each will take?
- Eliminate that practice. Only when the team selects their own work do they feel ownership of that work. And it is only when a team feels ownership that they will begin to have the motivation to work at their full potential.
- Are story sizes small enough that each person can work on at least two stories per sprint? Large stories that take most of the sprint to complete can create a Parkinson’s effect. People get used to the idea that they work on only one story per sprint, and so, consciously or subconsciously, allow each story to expand to fill the sprint. Sometimes you can have a breakthrough in velocity just by breaking that pattern.
- Size stories such that at least two or three can be worked on by each person in one sprint. This gets people used to the feeling of finishing and then pulling something off the backlog mid-sprint.
- It might be necessary for the ScrumMaster to keep close watch on stories to ensure that they don’t languish uncompleted for days. Once the pattern is broken, this is usually no longer a gating concern.
OK, great. The team is fairly empowered at this point and work should be flowing smoothly. Still, they may not feel full ownership and commitment. One of the problems is that they team may still be looking to their PO and ScrumMaster as their “leaders,” and consciously or subconsciously feeling that the ultimate accountability for the story or the work item or the task is more with these “leaders” than themselves.
So spread out the “leadership”.
Tip: Spread the Spotlight
- Do the ceremonies revolve around the same people? Is it always the SM or PO that facilitates the planning sessions, retrospectives, and sprint reviews? Do people talk to the SM during the standup? Start by broadening the leadership.
- One method is to have story owners. Ultimately, it is probably ideal for the entire team to feel fully accountable for all stories, but it can be difficult to get there in one step. So, an interim step may be to have designated story owners, whose job it is to drive the story to completion. They should ensure that there aren’t gaps in time between sequential tasks of the story and help resolve impediments pertaining to that story. This can have the negative consequence of individual team members still not feeling accountable to that story being complete, but at least the feeling of ownership has been somewhat spread out. Individuals who have been story owners can then spread that feeling of commitment to others on the next stories.
- Ensure that BSAs, QA, and developers all get the chance to be story owners.
- Once everyone begins to demonstrate accountability to all stories, the story ownership may be dropped.
And yet still it may seem like some stories and tasks are dragging on longer than they should.
Tip: Use the Buddy System
- Do people tend to hand off work to each other via documents? Do they communicate via email instead of in person? Lack of collaboration can lead to low transparency silos, which are a breeding ground for Parkinson’s. It is very easy to hide when no one else interacts with you.
- Encourage collaboration sessions around story acceptance test writing or reviews, perhaps even kickoff sessions for each story.
- Make a habit of including everyone involved with a story in ad hoc discussions.
- Encourage pairing; not necessarily for just development, but any functional area, especially where Parkinson’s might be lurking. Pairing generally speeds up tasks, and many in the XP world even observe that pairing can even reduce overall net effort on a task. But even if it doesn’t, the payoff in terms of reducing the Parkinson’s effect will probably offset any net effort increase due to the pairing.
A healthy pattern will be established which should stick. It is hard to watch your velocity drop and hard to let Parkinson’s set back in to a team, once good collaborative patterns have been established.
Tip: Focus on Focus
- Do people tend to complain about interrupts, or that they have too many responsibilities outside of story work? Perhaps it is time to retrospect on those problems.
- Solutions may exist in process changes. For example, rather than have everyone on the team be interrupted by a production support broadcast, have level 3 support designates that periodically rotate through the team.
- Practice good interrupt management. Does everyone on the team understand the evils of multitasking, both from the standpoint of flow as well as context shifting? Perhaps some education is needed. Spend a sprint recording what you are doing once per hour (set an alarm) and aggregate the results. See anything surprising?
- As a Scrum Master, check to see if people are burning down tasks on multiple stories at the same time, rather than working a task to completion before moving on to the next one.
- Question the interrupt requests.
- Give feedback to habitual interrupters,
- Recognize that you are not indispensible and don’t need to always be the hero.
- Turn off distractions if you can, like email popups.
- Resist the urge to check email.
- Manage time in blocks.
There are many more time management ideas that you can find via a few specific web searches.
By now, we should be seeing a healthy buzz of collective ownership and collaborative practices, and Parkinson’s Law should be all but eliminated.
Parkinson’s is all about lack of motivation. Therefore, it can be cured by taking steps to establish a team environment where motivation comes naturally. Any steps that serve to improve empowerment, teamwork, collaboration, and the feeling of collective ownership will have the greatest effect.