Scrum Against Parkinson's Laws
Summary: Parkinson worked in the public service for many years and published an article in 1955 as a criticism against the widespread idea that working "harder" was better than working "smarter and faster", especially in public service institutions. Today, "working smarter and faster" has become a necessity in order to increase customer satisfaction, which is at the top of the strategic goals of all companies, and to have products on the market on time. Because there are problems in achieving these goals with traditional methods. As Turksat Software Development Directorate, we are trying to make our teams more agile in order to achieve these goals. We aim to increase our effectiveness by using time more efficiently by applying some techniques and methods while creating the perspectives of agile teams. Read the article by Ali İmre, one of our project managers, about "how" agile methods are used in our directorate. you can reach In this article, I tried to summarize "why" we apply these.
What are Parkinson's Laws?
British naval historian, journalist and author Cyril Northcote Parkinson published an article in The Economist magazine in 1955, containing his observations on British state institutions. In his article, Parkinson said, "Things expand to fill the time needed to be completed", although it may seem like a criticism of the system, but he was actually emphasizing a perspective that would shed light on business principles, the laws of financial literacy, and the reasons why most of us are not successful in life, and a situation that everyone experiences at every moment of their lives. Parkinson, who was a relatively ineffective academic before the “law” was announced in an article, later became a famous person known all over the world by publishing other laws such as “expenditures increase as income increases”.
In his article, Parkinson shared, as an example, the story of a woman whose only job that day was to send postcards. Accordingly, this job, which a busy person could do in about three minutes, was carried out throughout the day by the woman. The woman spent an hour finding the card, another half-hour looking for her glasses, ninety minutes writing the card, and twenty minutes walking to the mailbox deciding whether to buy an umbrella, and so on until the day was over.
Current examples are not much different from this. If a team is given a job and a completion date for that job, it usually doesn't finish before that date. If you give yourself a week to do a one-hour job, the psychological complexity of the job increases and just thinking about it becomes daunting. If a meeting is planned for one hour, even if everything that needs to be discussed has been discussed in the first half hour, that time will definitely be filled with other topics and sometimes it will be longer.
We Use Scrum Against Parkinson's Laws
Let's take a look at some of the scrum practices we implement as the Software Development Directorate and how we use them against Parkinson's Law:
Focus on Target
No matter how good a team is, if it doesn't know where it wants to go, its work will go no further than saving the day. Therefore, first of all, the team must understand what the product it has developed serves strategically. Once we understand this, we plan the work by dividing it into small measurable parts to achieve these goals. In order to keep up with the change in the basis of agile development, we know and accept from the beginning that the strategic goal of the product and the plan will constantly change depending on customer demands. So, as Eisenhower said: “planning is nothing, planning is everything.” At this stage, the product is planned by dividing it into epics in a project plan. The status of epics is regularly monitored through "Epic Reports". These are compared with the project plan and the approach to the target is evaluated.
Focus on Value
If we think we have plenty of time to complete a task, we usually expand the scope. Sometimes, while trying to complete a task, we find ourselves working on other tasks that are not in the plan and usually do not create value. Therefore, the team works with the customer on the epics and prepares the product backlog to make the work visible and track it in this way.
In the product backlog, jobs are ranked according to the value they will create. Product backlogs are often very crowded. But when examined, the “Pareto Principle” is also valid for this list. 20% of the jobs on the list account for 80% of the value of this list. That's why identifying that precious 20% is critical. Works that will not create value are not included in the sprint plan. A sprint goal is determined for each run, and no work is done that will take the run away from its goal.
While the product's compliance with the plan is monitored through epics, the compliance of the sprints with the plan is monitored with burn-down charts or incremental burn-up chart reports. Seeing that the team has achieved its value-creating goals in a short time during sprint reviews increases motivation and ensures ownership of the work.
Distribute effort evenly over time
In traditional project management, deliveries are often spread out over very long periods of time. For this reason, after the beginning of this period is spent with inefficient work, the effort increases with overtime at the end of the period.
The Scrum framework recommends certain sprint times to distribute effort evenly. After these sprints have been run a few times, the average speed of the scrum team will also be revealed. Thus, product development can continue at the same pace from beginning to end. Giving tasks size (story points) instead of duration also prevents falling into the time trap. The speed determined according to the size of a task allows for more accurate estimation.
Eliminate wastage of time
Uncertainty and distraction are often reasoning why tasks take longer than necessary. We try to keep the team's communication at a high level with daily meetings, sprint planning and review meetings, and scrum events such as retrospectives to eliminate elements that distract the team while working and ensure focus on the goal. If someone on the team is getting distracted, the others help them refocus.
Repeating Scrum activities at certain intervals and in the same place as much as possible and having a time limit for meetings reduces time loss as it eliminates complexity and uncertainty. During the "remote working" that started with the pandemic, we observed that productivity increased considerably, even though it was expected to decrease, as we were able to continue these activities effectively remotely. We will share our experiences with online meetings that replace physical meetings with you in another article.
In the sprint reviews held at the end of the sprint, errors or situations that go wrong, if any, are detected early. This prevents wasting time on mistakes. Both the drying cost is reduced because it is detected early, and the creation of a product that the customer will not use is prevented in this way.
Having a team definition of "done" and determining "acceptance criteria" for each task both reduces disagreements within the team and increases the quality of the product. Team members must complete tasks as quickly as possible to meet the definition of done, remembering the saying “perfect is the enemy of the good”.
Creating and maintaining team spirit
According to another law of Parkinson's, increasing the number of people leads to an increase in bureaucracy, which leads to a decrease in productivity. For this reason, the scrum framework requests that the number of teams not exceed ten people. There are only three roles in Scrum teams and the responsibilities of these roles are clear. This way, everyone communicates quickly, without bureaucracy. They make joint commitments to sprint goals. Work is not assigned to team members. Everyone chooses their own work from among the works taken in the sprint, and at the end of the sprint, they work together to finish the work on the "to do" list.
Creating a continuous improvement perspective
Our favourite scrum activity for a scrum team to do its job in harmony, just like an orchestra, and to focus on doing better each time is "retrospective". In retrospective meetings, we ask "What did we do well?" While talking about the question, the team reviews itself and its way of doing business: "What can we do better?" The question allows the team to evaluate the system at the end of each sprint in order to continuously improve the system. Actions are decided in these meetings and experimental studies are carried out within the sprint for improvements. If it does not work, we evaluate it in the next retrospective and if necessary, we try something else. Instead of only solving the problems related to the product, the team solves the problems of its own system. It also organizes the working environment by solving the problems.
As a result, although Parkinson's laws are generally valid, we believe that we can reduce their effects by organizing the way we do business with an agile perspective. Although each team under our directorate has different speeds, goals and ways of implementing scrum activities, we work to increase our motivation and create value by dividing difficult tasks into small parts and solving them with continuous improvement and an agile perspective, and most importantly, by getting support from each other.
Source:
- Parkinson's Law | The Economist
- How to Use Parkinson's Law to Get More Done in Less Time - Lifehack
- The 'law' that explains why you can't get anything done - BBC Work life
- Parkinson's law - Wikipedia (wikipedia.org)
- The Scrum Guide
Esra Keskin Keles
IT Analyst
Software Development Directorate