When to Plan and when to Scrum

A project has a goal, a beginning, and end, and by most definitions a plan for what activities will be performed to reach the goal. Unlike a process it is a unique one off thing.

There are two main approaches to managing projects: Predictive project management and Adaptive project management. You can also use a hybrid between the two.

Predictive management and predictive planning is the traditional way, where you try to predict the steps, activities, and resources required to reach the goal and make a plan accordingly.

The adaptive approach is used when the goal is less well defined or expected to change over the course of the project. It uses an iterative and incremental approach where the goal and activities are frequently reevaluated. The best known and spread adaptive approach is the Scrum framework.

In this article we will discuss when Scrum is a fitting approach and when a predictive or hybrid approach works better.

Why Scrum exists

History

Scrum was developed as a process during the nineties and was first presented in 1995. It started to be well known in the ‘00s. Two of the framework authors, Ken Schwaber and Jeff Sutherland were also part of the group that published the “Manifesto for Agile Software Development” in 2001. The Agile manifesto has had a huge influence on the software industry, and Scrum has become the most famous framework to implement Agile principles. Part of the fame can be attributed to the success of the now famous FANG tech giants. The apparent success of Scrum and promotion by Scrum education and certification companies is causing these methods to spread beyond the realms of pure software development.

The problem and the solution

The first problem Scrum was designed to address is a product management one. Especially during the ‘90s and ‘00s the computer and software technology were changing rapidly. This meant that requirements and specifications for software products often needed to change during the product life cycle. A rigid system with specification, planning, and execution steps is ill suited for that, leading to lots of wasted work. Estimating and planning features that are later scrapped and never implemented is one such waste. Scrum urges you to not plan more than necessary.

To cope with change using Scrum you give one small team the authority to make decisions about what to prioritize, based on empiricism. The team works in small increments called Sprints, always working on the thing that creates the most value. After each sprint, shorter than a month, information is gathered and evaluated to determine what the next value creating step shall be. To create value and new information it is expected that each sprint will deliver a new software release, and that information is gathered from the customer or user.

Agile

The framework also mentions “lean thinking”, as in the production methodology Lean, and does in general conform with the four core values in the Agile manifesto:

The Agile movement as it is called, that produced the manifesto, scrum and other frameworks and ideas were driven by engineers and developers. The empowered Scrum team is not only good at producing value, it also leads to a better work environment for the developers. The “pull” mechanism were the team determines what they will be able to accomplish during a sprint reduces the risk of being assigned more work than can be done. There is more room for teamwork and creative problem solving than in a traditional hierarchical organization.

The Scrum Framework

The core Scrum framework is described in the 2020 scrum guide available on scrumguides.org. It is lightweight with only about ten pages to read. It explicitly says that if you are only doing parts, you are not doing Scrum. You are free to amend it with compatible methodologies and practices.

Corporate Scrum

Giving a team so much autonomy and authority may be an alien and scary prospect for a traditional manager. Managing several scrum teams is also a challenge to be handled. There are many extensions to Scrum to address these concerns. They tend to make the framework more complex and rigid, and is sometimes called Corporate Scrum. It is often criticized for diverging from the core principles to the point that it no longer is Agile.

Predictive planning and its problems

According to the Cambridge definition a project needs a plan. The purpose of a plan is to answer questions like: “What will it cost?” and “When will it be done?”. To answer these questions it is also concerned with a high level “How?” and “Who?”, and the availability and coordination of resources. Another valid question that should be answered in a project plan is “What are the risks?”.

A common follow up question is “Can we do it faster?”.

Estimating time

To answer the questions about cost and when the project will be completed you need to figure out what needs to be done, and estimate how much work that is. This is usually a difficult task, and it requires some effort. There is a correlation between how much effort you put in and the accuracy of the resulting estimates. You will need to balance the cost of estimating and creating the initial plan versus the need for an accurate plan and the risk that your work will be obsoleted by changing priorities, changing requirements or new insights discovered along the way.

Evolution has made humans into optimists, likely to underestimate difficulties and risks. Your organizational culture may also affect estimates by either promote self confident optimistic estimates, or by “punishing” those who fail to complete task within the estimated time.

Changing and keeping the plan up to date

“No plan survives first contact with the enemy.” [Helmuth von Moltke, paraphrased]

The plan needs to be updated as the project meets reality. The world will change and affect the project, and the plan will need to be changed to reflect that. Without support from a good project planning tool this can be just as much work as creating the plan in the first place. The more infrequently you update the plan, the more work it will be each time. A plan that is not up to date is like an inaccurate map, and can be worse than not having a plan at all, as it may actively mislead people.

Managing work loads and coordinating projects

All work in a project must be performed by some person. If that person has other tasks too, maybe in other projects or outside of project plans, care must be taken to coordinate when and how much work is assigned. Without proper care or a tool to assist, over-assigning work is a real risk. This leads to plans not working out, and to unnecessary stress.

Waterfall problems

Originally the term waterfall model was coined to describe the lack of feedback loops in a process diagram from 1956. It later came to be used to describe more general problems associated with the lack of feedback and iterations in processes and organizations. In practice maybe most felt in the handover between departments.

Nowadays, the term waterfall is used mostly as a synonym for predictive planning, to differentiate it from adaptive approaches like Scrum. Still, however, with a slight negative connotation.

Waterfall problems are not inherent to predictive planning. Not even the originally criticized diagram was intended to be interpreted as if there were no iterations and feedback in the process. Waterfall problems can occur from rigid processes and from how responsibilities are departmentalized in an organization.

Can You Scrum

First you should consider if you should use Scrum. Are the problems you have problems Scrum is designed to solve? If it is, then check if you can. There are some prerequisites or assumptions Scrum rely on, that may not be automatically true, especially outside of pure software development.

The Team

The Scrum team is a cohesive unit of professionals focused on one objective at a time, without internal hierarchies. The members have all the skills necessary to create value each sprint. If the operations of your project requires different type of expertise at different stages, you may not be able to create one consistent cross functional team fully focused on a common goal.

Sprints

Can you create customer value each sprint? Is less than one month enough time to create something meaningful and valuable? What you create has no value until it benefits a user or customer. You will not get feedback from users or customers if they can not experience the value you have created.

Backlog

In Scrum desired or suggested features are entered as items in a product backlog. At each sprint planning, starting a new sprint, the value of the items in the backlog are evaluated. The team determines how many of the most valued items it will be able to implement during the sprint.

Will you have gathered new empirical information about the backlog for each sprint? If you don’t expect items in the backlog to frequently be added, removed and reevaluated, this exercise is less meaningful, and maybe even a waste of time.

Inspiration or Cargo Cult

It is very common to talk about sprints and daily scrums even when that is the only things from the framework you do. Regular planning meetings and daily team meetings alone does not make it Scrum. That is OK; It is good to be inspired by ideas from different sources and to create routines that fit your unique organization and your special problems and needs. It is very seldom a general recipe for success will work right out of the box.

Cargo Cult is when you imitate a behavior in hope that it will bring you good outcomes, without understanding why or how it works. If your personal work desk has a marked parking space for your coffee mug, you are in a Lean - 5S cargo cult. Make sure your borrowed Scrum practices are not just cargo cult.

Modern Adaptive Predictive Planning

If you have determined that Scrum will not solve your problems, and traditional planning has failed you, but you still need to plan and manage projects in an uncertain and ever changing world; What to do?

There are tools that can help you alleviate many of the problems with predictive planning, and that also lets you be adaptive and agile. I am of course specifically talking about The PlanMinder.

Automation

The PlanMinder uses automation to reduce the work of maintaining project plans. Automatic scheduling is combined with feedback from time reports of what work the team actually does. As team members report what they have done, it also becomes natural to update estimates when more is discovered about the tasks at hand. This keep plans up to date at all times.

With automatic scheduling there is no resistance to changing the plan. Change priorities, add and remove activities and reassign work. The new schedule and what effect the change has on all projects the tool handles are immediately visible. You can try different scenarios before you decide on implementing a specific change.

If you are an organization that runs several projects at the same time, sharing resources like experts, The PlanMinder will make it easy to coordinate and see how changes in one project affects others. You can be much more flexible in how you create project teams without running in to coordination trouble.

Estimation

In The PlanMinder you estimate time with uncertainty. You have a well defined definition of what your estimate mean, and you provide information on how much or little you know of the activity you are estimating. This improves estimates and gives you more valuable information than a single number does.

Time reports from earlier projects, once you have projects to look back on, can be used as a reference and will help you get better at estimating.

Article: The art of Estimating Time

Risk management

Work estimates with uncertainty combined with automatic scheduling makes Monte Carlo simulations possible. The PlanMinder will not tell you a specific date a milestone will be reached. It will give you a probability distribution. If you have a deadline The PlanMinder will let you know how likely it is that you will reach it on time. You can monitor how the probability changes as work progresses. That way you will get an early warning if you need to take action. Early enough when there is still time to take effective actions.

The PlanMinder can also handle discrete risk, like the risk of failing a certification test, and can visualize how that may affect your timeline and budget. This is a much more visual and powerful way to handle these kind of risks than just entering them in a risk register.

A risk affecting your project may originate in another project not releasing the resource you need in time. Traditionally it would be difficult to be aware of and quantify such risks. The PlanMinder calculates schedule risks accumulated over all projects it handles.

Working conditions and stress

The automatic scheduler will not over-assign work to any individual. The scheduling is based on the individuals own estimation of amount of work, and how much time they have available for scheduled activities. If any of that is changed, the schedule is updated accordingly.

The PlanMinder empowers the team to use their own judgment over blindly following a plan. All information about priorities and how the plan fits together is readily available in the tool all use daily to report work. Team members can help each other out or change the order in which things are done without messing up the plan. It will be updated automatically based on what work was actually done.

Being empowered and having agency increases job satisfaction and reduces harmful stress.

As a project manager you are tasked with making sure that the project delivers on time and budget. With The PlanMinder you have a tool that gives you a much better view of whether that is possible or not. It gives you the means to detect and to try out different ways to solve problems while there still is time to make meaningful changes. It also helps you communicate these insights. The sense of being in control improves your working conditions relating to stress, while it also improves your ability to be successful.

Other stakeholders dependent on project deliverables will also be able to worry less and trust forecasts they are given more, with information and insights they get from The PlanMinder.

Continuous project planning

The PlanMinder is just a tool. If you want to associate a methodology with it it would be continuous project planning. Continuous as in you are continuously updating the plan with new information.

Should you still have regular project meetings to evaluate goals, progress and risks? Yes of course, but you don't need to set a fixed interval. Have meetings as soon as you can when the need arises. Schedule the next meeting to when a milestone is expected to have been reached, or to when you predict that there will be something interesting to discuss; Or schedule it for when a meaningful amount of work is expected to be completed. In other words, have meaningful meetings.

Should you have daily team meetings? That depends on your organization. The flow of information within a project is one of the most important responsibilities of the project manager. Information must reach those who need it. Regular meetings is one way to do that, but having them daily may not be the most efficient way. Especially if not all team members are fully dedicated to one single project. Individual check-ins with each active team member from the project manager is another way, combined with a readiness and ability from the team to communicate with each other as soon as the need arises.

As remote work becomes more common, natural spontaneous meetings become more rare. Meetings become more important to create group cohesion and identity, and to grow a team or company culture. If that is the purpose for a meeting, adapt the meeting for that purpose.

Conclusions

So, should you Plan or should you Scrum?

If you are creating software you can release with added value every few weeks using a small team, then do look into Scrum or maybe it sibling Shape Up. Check that it attempts to solve problems you actually have, and that you can do all things the framework requires you to do. Specifically check that you have someone that can fill the new critical role as product owner in the team.

If you are doing something else than pure software development consider what problems you actually have. If they are related to project planning, consider how you can improve that process rather than using a framework designed to solve other problems. If you still need to plan and coordinate, Scrum will not help you.

If you have a long development process ahead of you, where a large number of non optional requirements has to be fulfilled before you have anything you even are allowed to ship to a customer, you will need to plan, and Scrum does not make any sense.

What problems you have and what solutions will work does not only depend on what you are doing. Culture also plays an important role. Sweden, for example, is known for flat organizations, consensus culture and very little hierarchy. Compared to the US, the norm most frameworks are written for, there are also countries where hierarchies are stricter and more important. Find a system that work for your organization by evaluating that the changes you make has the desired effect. And use the tools you need to help you get there.

The tool you need is quite likely The PlanMinder.