Four Reasons why your Scrum is Painful

In lieu of a neatly wrapped conclusion: your team may have more than four!

Photo by Maria Lupan on Unsplash

Sometimes in programming there’s what we call a code smell. It’s a few lines of code that just look wrong — you don’t quite know where the rot is, but you can tell that something is off. And then you need to decide if you want to dig deeper, or roll some glue over the top and move on.

We can have the same experience in meetings too. You’re 15 minutes into a one hour grooming meeting, and there’s no chance of getting out. You don’t quite know where things went off the rails — maybe the 3 minutes in the beginning someone spent sharing photos of their cat? But you have this underlying sense that something is very wrong, and you’re sure that no one is walking out of that meeting with a sense of accomplishment.

This pattern, continued over weeks and months, may lead people to declare that scrum is an annoyance, a series of arcane rituals and cliquey language that amount to a hindrance to real work. A true scrum team would have the independence to cast off or modify the structure of their sprints and groomings, but a true scrum team would have addressed these problems before they became a routine. Many teams don’t have such independence, whether that is due to organizational decree or just a perceived lack of freedom to be contrarian. And so the cycle continues. Even though everyone involved recognizes the pain, and projects continue to fall behind schedule, there is no option other than to continue.

The worst offense is that you’re exporting your failure. Those team members will eventually, perhaps sooner than eventually, move onto other teams, where they will relate their disgust of scrum and allow the cycle to ripple out.

Your product isn’t ready for scrum

This isn’t meant as another guide on converting an old, stodgy, waterfall process that takes six months to plan a four month project. There is another end of that spectrum that scrum tries to strike a balance with. At the other end of the spectrum are teams that have essentially no preplanned work at all, no agreed upon process, and use people as glue and grease to keep their machines running.

If your team walks in each day to a new set of unplanned work or root cause analysis demands, the idea of having a dedicated two weeks long block of time to planned, estimated work will seem like a luxury you can’t afford. If your team could go on forever, never planning any of their own work, and yet never be idle, you’re not ready for scrum.

Because of How Complex Systems Fail¹, systems are rarely totally inoperable, and the idea of a software system being engulfed in flames is not accurate. An unstable system is more similar a ship taking on water as it crosses the ocean. You can still move, steer, and maybe even serve meals, but you’re probably going to sink before you reach your original destination. Why bother estimating when you’ll reach port if you’re never going to make it?

If this sounds accurate, there’s probably a wealth of stabilization opportunities. Here’s some questions to ask yourself:

1. Can the system easily be configured by a user into a broken state?
2. How much money, in the form of time, do we spend trying to figure out what the system is doing?
3. Do we have processes that contain “Contact David in engineering…”?

One of the goals of a sprint, usually two weeks, is that you have some allocated, uninterrupted time to work. The block of time needs to be sufficiently long enough to give people time to solve problems on their own, but short enough that the team can incorporate changes in the external environment. If you’re embarking on a brand new product, you won’t know the volatility of that environment. But after several months or a year, it’s your responsibility to understand that volatility well enough to be able to either adapt or get out.

Your team has varied expectations of scrum

Often times, the most valuable parts of team building happen when people are sharing what they assume everyone else already knows or understands. The reason those moments are valuable is that no one else already knows or understands what is being shared.

All of these innate, “obvious” aspects of what scrum is and how a team should use scrum should be written down, agreed upon, and used like bylaws during conflict resolution. And like a law, it should remain subject to challenge and modification through the same process by which it was originally codified.

Does everyone know who is responsible for presenting user stories in a grooming session? Probably. But, does everyone agree on what metric is used to determine a particular task is too large? And does everyone agree on who is responsible to decompose it?

Is a story done when the code is ready? When the pull request is merged? When the tests pass? When the change is in production? When the feature flag is turned on? When the logs show it’s working as intended?

These are the types of questions that, most likely, everyone on the team has an internal, personally rationalized answer to. While each of those rationalizations is valuable, the really important part is getting the team to communicate those, and then agree, even hesitantly agree, to a standard to which the team can hold themselves and each other to.

Once that’s defined, like any non-sensitive document, it should be published as publicly as possible. Maybe not on your organization’s marketing website, but maybe on your tech team’s blog, or at least on your private intranet. There’s something about publicity that helps ensure a degree of reasonableness, and it’s another opportunity for feedback. Building feedback cycles and incorporating that feedback is critical to a successful scrum team, and any opportunity to hear feedback should be taken.

You aren’t making second order investments

I’m a complainer. I’m good at it. Like every good complainer does, there’s a time for ranting against “We do it this way because that’s how we’ve always done things”. If the idea of your team meeting in a grooming session to discuss the complexity of each task your team needs to complete seems inane, it might be because the tasks you’re doing are ripe for optimization.

I’m not suggesting your work is easy, or even simple, but if the tasks are so well-known and repeatable that they don’t require individual estimation, then it’s time to start thinking about investing in some tools to automate them. This might be in the form of building integrations between systems your team uses, or building some tools so other teams that you support can operate in a more self-service manner. Regardless of what the task is, you should recognize that automation is hard. It requires absolute knowledge of and representation of a process that a human being, with all of the capabilities of their brain, was previously in charge of.

First order investments are the things that needs to be done in order for your organization to get paid, or fulfill its commitments. Investments in scrum, like the type discussed in the last section, can be considered third order investments— that is, something that can help you improve how you improve, but it doesn’t offer its full scale of improvement on its own, it only really improves second order investments. Second order investments are the things that help you deliver your client commitments in a more efficient manner, or potentially even let your clients fulfill these things themselves, like a vending machine.

For example, if you’re running a package delivery company, your first order task is to get the package from the source to the destination. Maybe your local or state government has invested in building some roads between common sources and destinations, and this represents a third order investment that can be leveraged for many different purposes. You could certainly carry the package on your back, walking down the road, and fulfill your customer commitments. This is still better than walking through a forest, but it’s going to become inefficient if you end up with more than a couple of customers. Your second order investment is purchasing some type of vehicle, leveraging the paved road, and dramatically increasing your ability to deliver many packages to many customers. Without the vehicle, the paved road seems like an awful waste of taxpayer money.

Some examples of the types of things that indicate it’s time for a second order investment:

1. You have a template for certain tasks that you copy every time you get a particular request.
2. You have a documented procedure to run certain scripts every time a particular complaint is made.
3. You have high degrees of algorithmic or logical duplication in different aspects or features in your system.

Each of these is an opportunity to reflect on why you decided to produce some kind of repeatable process, and then reflect on how you can remove the need for your team to be involved each time that requirement comes up.

You’re trying to use scrum to measure performance

In object-oriented programming, there’s a set of principles named SOLID², and the “S” stands for “Single Responsibility Principle”. This roughly translates to the idea that modules in a system should have only one reason to change, or that a single aspect of a system should have only a single stakeholder that it serves.

If the purpose of scrum is to improve the ability of the team to meet the most important priorities of the client, it cannot also serve as a stand-in for individual performance measurements. This might happen because it is notoriously difficult to measure the productivity of individual software engineers, or because the organization doesn’t have any other quantitative, objective performance metrics by which they can evaluate their employees. Neither of these are easily tractable problems, but we can also acknowledge that neither problem was solved before the introduction of scrum. While I’m not dismissing the importance of solving these problems, this is a problem that management and people operations (aka HR) needs to solve outside of the team’s project management framework.

1. If you start making individual measurements and goals around completion of tasks within their estimates, you’ll end up with inflated estimates and fulfillment of Parkinson’s Law³.
2. If you start measuring each person’s total completed story points (or whatever estimation metrics you’re using), people will stop collaborating to complete tasks. People will also internalize knowledge on aspects of the system, carving out miniature fiefdoms, so that they’re guaranteed the opportunity to work on tasks with high estimates.
3. People will generally become more risk averse, and your grooming meetings will grind to a halt. Estimates will no longer represent educated guesses, but instead will represent quantified treasure points to accumulate and count when it comes time for annual reviews and bonuses.

I’m not suggesting that people are inherently manipulative or overly selfish, but if you need the project management system to produce successful projects, you can’t ask that much more of it.

You probably have a bunch of really smart people on your team, and one of the fundamental tenets of scrum is open access to information. If you setup a system of punishment and reward based on a process with open access to data, data that is generated by those being punished and rewarded, they will find the quickest paths to the rewards and tactics to avoid the areas most likely to incur punishment. This is exactly what the entire business organization is trying to do in the first place, and there’s no reason to think that your individual team members don’t recognize that.

[1] Richard I. Cook, MD. 1998, 1999, 2000. https://how.complexsystems.fail/

[2] Robert C. Martin. 2000. Design Principles and Design Patterns.

[3] Parkinson, Cyril Northcote (19 November 1955). Parkinson’s Law. The Economist. London. https://www.economist.com/news/1955/11/19/parkinsons-law