Software Development Done Right

In Software Development, the term “Scope Creep” is scary. It’s a feeling that something is not right, but you just can’t put your finger on it. It’s something that is lurking below the surface, causing your project delays in release schedules and milestones not to be hit. It leads to features showing up in the product that were not asked for initially, rewriting code, documentation, and tests. All of this ultimately causes not only the project timelines to slip, but the morale of the team to suffer. I’ve seen this time and time again and this is a doozy as it encompasses many of the concepts I’ve written about in prior chapters. According to one statistic:

 

“50% of all Software Development projects experience some form of Scope Creep” - Project Management Institute

 

However, I would argue that it’s likely closer to 90%.

 

In this chapter, I’ll touch on the high points that I’ve shared with many people from business leaders to engineers on not only why this happens, but how you can mitigate it.

 

What is Scope Creep?

 

“Scope Creep (also called requirement creep, or kitchen sink syndrome) Refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins… It is generally considered harmful.”

– Wikipedia

 

While we have a definition of what it is, we also need to consider the team working on the project and if you look back to Chapter 1 of this book [ LINK TO CHAPTER 1], you’ll see that Software Development is Emotional.

 

The people working on the project want to help and to do that will take on whatever is being asked of them. So they accommodate the changes without realizing what it means to add additional features. A few interesting things then come in that I’ve discovered in my research.

 

1. Optimism Bias - which is defined as “failing to consider how long it's taken us to complete similar tasks in the past.”
2. Overconfidence - “Assuming that we won't run into any complications that will cause delays.”

 

In short, humans just aren’t good at estimating time. I’ll discuss practical ways to help with this later in the chapter.

 

What are the signs?

A few of the many signs of Scope Creep are:

1. Constantly slipping schedules
2. Going over budget
3. Delivering undocumented/unrequested features
4. Rewriting code, documentation, or tests
5. Adding tasks after the Sprint has started

 

I won’t say that if these are occurring that you for sure have scope creep going on, there are many other reasons, but just be aware of these red flags.

 

Is It Ok for Scope Creep to Happen?

Absolutely. It’s certainly acceptable and I would say in projects following the Agile Methodology, it’s encouraged to allow the product to evolve and change over time. To quote PMI it says,

“Because agile frameworks are designed to welcome and manage change, the scope does not ‘creep’, because change is expected and accepted throughout the life of the project.” - PMI.org

What I want to stress here is that we accept it, and then apply the tools and techniques to help us work through it.

 

So, How Do We Manage It?

Here’s a short list in not any specific order. I will share the slides from a presentation I have done many times before at the end which expands on these, but here are the high points.

1. 1. Remember: Software is emotional and can be irregular
      • Make sure you have clear and consistent communication with all members of the team
      • Multiply your time estimates to make any changes by at least a factor of 2.
   2. Create a template for each body of work
      • Having a standard template when creating a task to outline the preconditions, steps to complete, expected results, errors, logging, and automated tests will force the team to make sure they are thinking of the entire scope.
   3. Allow the team to suggest alternatives
      • Quite often someone else on the team might have a faster or better way to clove the problem presented by the product team.
   4. Always shave sprint reviews and retrospectives
      • Discuss why a feature might have taken longer tan expected. Quite often you’ll find that additional scope was added.
   5. Demo working code - this will help to catch tasks from going off the rails early.
   6. Use tags and labels to not forget about important features, but tag them for future releases
   7. Most important - have a formal change request process!
      • While I like the whole spirit of the Agile Manifesto, I personally believe that it can’t be a fee for all. As the teams get larger and their sub-systems need to work together, everyone needs to be working in alignment. The only way that I have seen this working is when representatives from Product, Engineer, QA, and Documentation are working together to identify the impact of the change, communicate that to the stakeholders, and changes are formally approved or denied. Complex software systems can’t have various teams making changes on their own.

Conclusion

I hope you have started to see that Scope Creep, which left to its own devices, can sink a project. There are a number of techniques that can be applied to help mitigate the risk. 

If you are interested in learning more, I’ve created an entire presentation on Scope Screep that I hope you download and review can help your organization after reading this article. Of course, I’m always open to discussing your specific issues and goals. Just reach out through our contact form and I’ll set up a time to learn about your challenges and give you personalized guidance.