Let’s say you created a new product. You think it’s beautiful and perfect. You go out and test it on real people—your target customer. And to your surprise, they don’t interact with it the way you thought they would. They stumble on things. Some of them don’t get it at all. Are your customers broken, or does your product need improving? Perhaps you can evolve your product to meet your customer's needs.

Now the same logic applies to Scrum. Are there so many scrum teams failing to implement scrum, or could there be reasonable improvements to scrum?

I’m in no way attacking scrum. I actually quite like it. I founded the scrum project management app Sandglaz. It’s just that too often there are teams spending their scarce time and money trying to implement scrum rigidly, and gaining little value out of it. And for what? Scrum is not a religion. And scrum is not your goal. Scrum is just a framework to help you move faster towards your real goal.

By watching many teams implement scrum, I have gathered the top four improvements to scrum. These improvements are not the kind of improvements that come out of a formal decision or a retrospective (although they certainly could!), but they are the kind that often happens organically in high performing teams as team members tend to do what is faster and makes more sense for them without thinking about it.

1. Decoupling releases from sprints.

A team can deliver live software multiple times during a sprint. The fastest Scrum I know today is at Hubspot where they deliver 170 live feature updates per day and almost 300 new releases a day at peak.

—Jeff Sutherland

In scrum, you release at the end of each sprint. This is when you present your product to your customers (or customer representative) and get feedback. When scrum was written, two week releases were considered often, but nowadays it’s common to release every day and even multiple times a day. Don’t let scrum stop you. There is no reason not to release to customers more often, but hold your planning meetings at the end of the sprint.

Some good reasons to release more frequently than sprints:

  • Shorter feedback loops—you learn what you did right, and what you did wrong sooner—so you can act on this feedback faster. For example:
    • Start running the next A/B experiment sooner.
    • Start collecting qualitative feedback from customers sooner
    • Learn about and fix bugs faster.
  • Encourages smaller increments of work, which is a safer way to iterate on a product. Especially true for junior developers. Most senior developers work in small increments regardless of how many times they release.
  • Gets you closer to continuous integration, since you will need to automate most of the process to be able to release daily.

2. Beyond the Scrum of Scrums

Scrum of Scrums can itself be a bottleneck if it is the sole owner of dependency management.

For those who are scaling scrum to a larger organization, you may have heard about the scrum of scrums. This technique consists of dividing the organization into scrum teams of 5-10. Each daily scrum within a team ends by designating one member as “ambassador” to participate in a daily meeting with ambassadors from other teams, called the scrum of scrums. The scrum of scrums has been criticized that it creates a hierarchal, tree shaped communication network rather than promoting self organization of teams. On the other hand, some teams find it helpful when used for removing impediments rather than updating status.

While scaling scrum is not an easy problem to solve and it doesn’t have a one solution fits all, it is possible and the successful implementations have a few things in common:

  • Teams are organized to reduce coordination overhead. Team members have complementary skills, but a common responsibility and accountability and a common work goal. They are cross-functional teams based on context.
  • Information flows across and through rather than up and down. Cross team communication is made explicit.
  • Continuous integration is done within context, while integration across contexts is done as a second level.
  • Product dependencies are actively minimized to simplify context links. Teams should mutually agree upon and develop automated tests across context boundaries.

3. Drop estimates

The scrum book recommends estimating how long tasks take. However, in software estimates are usually way off, and when people give estimates they tend to treat them like promises—they do anything to keep them. This might mean working faster and cutting down on value, or it might mean working slower.

To help you decide whether or not you should keep estimating ask yourselves these questions:

  • Are you making worthwhile decisions based on these estimates?
  • Does it take more time estimating a task than doing it?
  • Are estimates being used as a forecast or as a promise?

The important thing is to focus on delivering value and quality rather than adhering to predetermined project plans.

4. Stop optimizing velocity

Scrum Velocity
Your team can’t keep worker faster and faster. They’ll burn out. Measuring and optimizing velocity is arguably a waste of time.

You might be thinking the goal of scrum is to optimize responsiveness to customer needs, and if you optimize your velocity then you move faster and can be more responsive. True in principle, but not in practice.

Velocity is measured by story points per sprint, and you don’t want to encourage team members to try and get more story points done each sprint on the expense of code quality. What increases the speed of development is how well your code is organized and how close you are to continuous integration. Assuming it is possible to estimate well—which it probably isn’t—the estimates on a story will simply go up when the developer is aware of all the code smells and lack of unit tests she has to work with. Therefore stories will be allocated more points, points per sprint will go up, but not your true velocity!

 

These are the top improvements I am seeing. They may not all be applicable to you, but they are worth reading about. Chances are you’ll find some relevant to you, or at least they may trigger other ideas of improving scrum that works for you and your team. To reiterate, I'm not welcoming adaptations of scrum to hide organizational dysfunctions. I'm welcoming adaptations to scrum that sincerely make you more effective and reach your goals faster!

How’s your implementation of Scrum? Are you making any modifications to scrum that are worth sharing? Please share with us in the comments below.