What is Flaccid Scrum or Flaccid Agile?

In the beginning, Scrum teams are moving along fast. They are doing most of what they say they will do in a Sprint and churning out code like a virtual code factory.  As time goes on, they may start to get slower. The development team hits less of their goals or they commit to doing less each Sprint.

One problem with Scrum is that it focuses so much on creating a releasable portion of a product each iteration that if the team is not careful, especially in the beginning, there will be a whole bunch of garbage code created. That code is then not working as well or as efficiently as it could be. It creates Technical Debt and will cause more problems the longer it is ignored.

The Scrum team is now dealing with a condition that Martin Fowler (one of the original signers of the Agile Manifesto) dubbed Flaccid Scrum. The team begins to slow down because they are constantly fighting with the old code as new features are added. With a focus on speed over quality, instead of doing things right the team hurried through to get it to a “releasable” state (I’ve been there ☹). So it works, but the underlying mechanism is junk.

This phenomenon is unfortunately not isolated to just Scrum. Other Agile frameworks can potentially encounter the same technical debt. It is also not really the fault of those frameworks. It is not Agile’s fault or Scrum’s fault. It is not just the development team’s fault either. Managers/Product Owners/Scrum Masters bear some of the burdens for pushing the team to develop code really fast and not bothering to make sure best practices were followed. A reigned in overbearing PO can go a long way to preventing technical debt.

It is caused by not focusing enough on the quality of the product you are creating. When you don’t adhere to all of the stressed principles within Agile frameworks, such as ignoring quality and failing to continuously work towards improving quality, quality will suffer.

“In defense of Scrum, it’s important to point out that just because it doesn’t include technical activities within its scope should not lead anyone to conclude that it doesn’t think they are important.”  – Martin Fowler (FlaccidScrum)

What Can Be Done About Flaccid Scrum?

I could probably build a 100-foot building in a week. It will be ugly, may not have any plumbing or a door, and won’t pass any sort of legal zoning inspection. Who am I kidding, I just took garbage and piled it up and called it a building – which looks a lot like your code.

Which brings me to my first suggestion – write code like someone is inspecting it…  and have someone inspect it.

*Additional note here – Inspection is one of the three pillars of Scrum

Improvement Ideas:

• Regularly carry out inspections on the code
• Keep the focus on quality first
• Bring in some best practices such as:
  • Regular refactoring of the code
  • Keep It Simple Stupid (KISS) – Simple code design
  • Shared codebase with continuous integration
  • Actually put comments in the code
  • Pair programming
• Include quality code in the Definition of Done
• When/if slowdowns occur, clean or refactor the code
  • Add it to the backlog as an item to be worked on in a Sprint

The Scrum Master (or Project Manager, Coach, whatever flavor of Agile) has several duties here. They need to ensure the Product Owner recognizes the value of a decent and well-refined codebase. They should stress the value of efficient code and ensure that inspections occur on the codebase.

Code issues, such as improvement ideas and problems found, should be addressed in the Sprint Planning and the Retrospectives. It needs to be a part of the product; quality should be built in from the beginning.

Reflection

Ideally, work should be done to prevent the code issues from occurring before they occur. Quality is not an afterthought. It is not something you do as a reaction to a problem. You have to be proactive and work to prevent the issues.

You won’t prevent them all. No one is going to be perfect all the time. Things will happen with the code that will cause issues down the road. You can’t always predict which features will be needed 6 months down the road. This is why as soon as you spot the issue, work to correct it. Leaving it unchecked, the code will eventually get so bad that no one will want to touch it and they will pretend it doesn’t exist.

You don’t want to ever learn what flaccid Scrum or flaccid Agile is from personal experience. It is better to read about it and laugh at everyone else than to go through it yourself.

Additional Information:

Scrum.org –  Improving the Profession of Software Delivery

Sources:

Fowler, Martin. (2009) FlaccidScrum. Retrieved from https://martinfowler.com/bliki/FlaccidScrum.html

Martin, Robert C. (2012) The Land That Scrum Forgot. Retrieved from: https://youtu.be/hG4LH6P8Syk

The Scrum Guide: https://www.scrumguides.org/scrum-guide.html