Scrum-Butt: 3 Fundamental Changes That Make Scrum Work

If you’ve been around software development in any capacity in the last decade, you’re at least familiar with the concepts and principles of Agile and Scrum. Whether or not you can strictly define either or accurately characterize each as a methodology, framework, recommendation list, etc., is a whole other story that we won’t bother to touch here.

In any regard though, if you’ve ever asked anybody the question “Do you do Scrum?”, the answer invariably begins with “Yes…buuuutttt”, followed by a list of where their implementation of Scrum differs from the most traditional sense. It happens so often, that I simply refer to it as Scrum-Butt. The following is our own version of Scrum-Butt as applied at my company, Primero Systems.

In Primero Systems, we love the principles of Agile Software Development…and who wouldn’t? It’s hard in most cases to find anything wrong with the 4 key values of agile as described in the ‘Manifesto for Agile Development’:

• Individuals and Interactions over processes and tools
• Working Software over comprehensive documentation
• Customer Collaboration over contract negotiation
• Responding to Change over following a plan

The items above in bold are always preferred over its counterpart to the right.

OK…so far so good!

Scrum then is the methodology that we’ve employed for almost a decade now to help us adhere to the principles of agile development as listed above. This of course, isn’t anything new or special, as Scrum seems to be the method de rigueur of modern software development teams. We’ve been using it extensively across dozens of projects, clients and team members over the years.

However, Scrum in its purest sense, hasn’t always served us as well as we would hope. There are some fundamental challenges built into it that we feel take us too far away from our over-arching priority which is to build great software as efficiently as possible.

Let me explain a little…

Traditionally, the Scrum process looks something like this:

• Build a prioritized backlog of tasks (stories) to accomplish.
• The closer a story gets to the top of the list, the more decomposed and detailed it should be.
• Run development cycles in (typically) 2–3-week sprints.
• Prior to a sprint, size the stories and determine what the team will commit to getting done in the upcoming sprint cycle.
• Hold daily “stand-up” meetings with the entire team.
• The team is made up of self-organizing, cross-functional members, generally from 3–9 in size.

The list above certainly doesn’t cover every ceremony, artifact or task within a typical Scrum approach, but it’s enough for our purposes here. Let me take a moment to review each of the items above and see where we differ from the more “traditional” implementation of Scrum.

Build a prioritized backlog of tasks (stories) to accomplish.

No problem here. As a matter of fact, this simple step can and should have a profound impact on not only your development process, but more importantly, in making your efforts more transparent to the project stakeholders. Whether your project stakeholders are internal or external clients, exposing and prioritizing a backlog can be quite the eye-opener.

What may sound simple and trivial at first blush can start to be somewhat quantified in the stakeholders’ eyes simply by reviewing the backlog.

The closer a story gets to the top of the list, the more decomposed and detailed it should be.

Again, no problem here. You simply can’t expect a developer to read your mind. As an (absurd) illustration of that here’s a conversation you could be having when your expectations aren’t clearly known:

You (to developer): Bring me a rock.

Developer: (Brings rock to you) Here you go!

You: No, I wanted a black rock!

Developer: (Brings black rock to you) Here you go!

You: No, that’s not what I want at all. Yes, I want a black rock, but I also want it to be smooth and…

You get the point. This is a conversation that could iterate forever, and in the development world, it causes delays and bloated bottom lines. In short, be specific in your requests, and you’ll get exactly what you want out of it.

Run development cycles in (typically) 2–3-week sprints

Again, this one generally makes a ton of sense. The more often you can demonstrate working software, the more chances you get for valuable feedback and course corrections where necessary.

Let’s face it, as a developer of software, you often have no problem visualizing that final look & feel and user experience. However, for stakeholders the reality is often quite different. They often need to literally see and tinker with the final product in order to formalize a final opinion on it.

Of course, there are scenarios where such short sprints make almost zero sense. For example, extremely complex systems where there is only a simple (or no) user interface, and it has very little demonstrable value until it nears completion is an example.

We always have to be cognizant of this and shouldn’t try to force every project or task into a framework that isn’t well suited for it. But that’s a conversation for a different article. Let’s get back to the point.

Prior to a sprint, size the stories and determine what the team will commit to getting done in the upcoming sprint cycle.

Hmmm….here is where we start deviating, and I’ll just stick to the topic of sizing stories at first. Let me reiterate, we have almost a decade worth of experience in the world of Scrum development and have been part of teams led by our own personnel as well as integrated with client teams. We have seen and tried a plethora of approaches to help us land on one that is most comfortable for us.

When starting any new project with new personnel, story pointing is always one of the awkward topics to address. This is particularly true when your team has new people who aren’t accustomed to story pointing at all.

As a quick aside, for those of you not entirely familiar with sizing stories in the backlog, it’s simply a way to roughly quantify the effort any particular story will take. If it’s determined that the effort is too large for a single sprint, then the story will be decomposed into smaller stories. Eventually, multiple stories are planned for a specific sprint based on the team’s capacity to complete them.

OK, so that’s a mouthful already. There are many approaches to how to size a story. One of them (and the most ridiculous in my opinion) is t-shirt sizing. With this approach, each story is assigned a size of x-small, small, medium, large, x-large. Each size is relative to the other, and up to the team to figure out. So, is a small twice the size of an extra small? Hard to say, as there’s no right answer.

I’m OK with the relative sizing concept, but what doesn’t work for me is that sizing is used specifically to help you understand your team’s velocity. In other words — how may stories can a team get done in a typical sprint? One sprint may see 1 x-large, 2 large, and 3 small stories done. How exactly does that help me determine my capacity for the next sprint where all of the stories in it are size medium and x-small? This isn’t just a question of theory, it’s a question that has to be answered definitively in order for the concept of sprints to work.

If it were me, I’d then apply a point scale to each size in order to quantify the effort. So, if we then said that x-small, small, medium, large and x-large were worth 1, 2, 3, 4 & 5 points respectively, we could apply the math and say that the team accomplished 19 points worth of stories in my example above. Now, the next sprint, you can assume that a medium story is worth 3 points and an x-small story is with one point and plan your sprint accordingly. Maybe you’d end up determining that 5 medium stories (15 points.) and 4 x-small stories (4 points) is your target for the next sprint as that also totals 19, and the team just proved they can accomplish 19 points in a sprint.

Of course, that exposes the entire fallacy of using t-shirt sizing. If it needs to get converted to points anyway to be of any value, then you may as well assign points to a story to begin with. That is what we’ve always done using a modified Fibonacci sequence. Given that, a story can be worth .5, 1, 2, 3, 5, 8, 13 or 20 points. Anything greater than an 8 must be broken down even further before it gets into a sprint.

For years, we did the relative sizing using the modified Fibonacci sequence above. And frankly, in any given single team, this is adequate, and over time becomes very accurate and efficient. So, for many teams and organizations, this may be just fine. The problem we run into though is that at any given time we have multiple projects going across multiple clients and teams that have to be fairly fluid to absorb the ups and downs of typical development needs depending on what phase a project is in.

So…my 2-point story for one team, may be the equivalent of a 3 or even 5-point story on another team. Every new project with a newly formed team is expected to go through the growing pains of determining how each story point is relevant to the next.

Here’s our first point of major deviation from traditional Scrum. For us a story point relates to a day’s work (typically 8 hours)….

GASP!!!

I know, I know…every Scrum fundamentalist is already formulating their scathing response or writing me off as some deluded heretic as we speak 😊

Trust me, I understand the benefits of relative sizing and not wasting time on trying to be precise where absolute precision isn’t necessary. Along those lines though, we still use a modified Fibonacci sequence as our only pointing options. We still fully realize that the larger a story gets, the harder it is to accurately estimate.

HOWEVER, I honestly don’t think that Scrum traditionalists are giving their team members as much credit as they deserve. We don’t allow any story above 8 points to make it into a 2-week sprint, and strongly encourage only those of 5 points or less. I fully trust that my team members can accurately quote a story of .5, 1, 2, 3, or 5 points (days of work). Of course, they’re not always 100% accurate, but over time they’ll be pretty darn close to it. Any engineer worth a grain of salt can readily tell you how many days a task will take them if it’s less than 1-week (5 days) of effort. If not, then that is a skill they must build without exception.

Now, my sprint planning suddenly becomes easier no matter what team I’m working with. If we’re planning a sprint and I know that there will be 4 full-time team members on it, then that means we can do 40 points (each member can work 10 days in a 2-week sprint). There’s no ambiguity left. And I also know that I can go back and look at multiple months’ worth of history to know precisely how accurate we are on our sprint planning vs the hours that we’re actually burning. This allows me to manage budgets and expectations across the entire enterprise to a much greater degree of precision than I otherwise would.

Even though I just explained some benefits for this approach from a management perspective, the most interesting aspect of this is that this idea came from the team members themselves. Previously, they had to live the reality of talking in terms of relative points, and how that varied from team to team or project to project. They didn’t like it. Period. The teams agreed unanimously that they prefer our current pointing system based on 1-point equating to 1 day of work.

This was an awesome example of where the team members’ desired approach not only made their lives better but made our job as managers and executives better too.

Hold daily “stand-up” meetings with the entire team.

Every organization knows what works best for them. For some, the daily stand-up is very valuable, and the benefits are apparent (although I haven’t seen that example yet in real life!). For others, a daily stand-up is a routine with little apparent value, but they do it anyway because they’ve always learned that this was the only way to do it.

For us, we generally have highly skilled and tenured engineers, analysts and QA personnel on every team. Many of these folks have worked for us 10+ years across multiple projects and teams. So…I understand that we may be the outlier here as we have an unusual amount of trust and respect for our team members.

Having said that, we generally find that only a single stand-up per week with the entire team is necessary. Anything past that provides a diminishing rate of return. There’s an important caveat here to consider though. Our team members are in constant communication during the week exactly how and when they need to be. There is no need for any team member to ever need to wait for a stand-up meeting to discuss anything.

It is our expectation that when they have comments, questions or concerns, they will be proactive in addressing the issue. From a management perspective, we have complete visibility of their progress simply by looking at JIRA, we don’t need them to tell us daily exactly what we can see for ourselves in JIRA. In the case where anyone may have an issue to address, the answer is always a quick communication away. Our stand-ups are still about 10 minutes or less, even while meeting only once per week.

Much as our story pointing behavior changed as described above, so did our stand-up behavior. In both cases it was in response to our team members’ desires. In the case of stand-ups, our folks felt like it was too inefficient. Coding and testing are disciplines that can benefit tremendously from times of uninterrupted concentration on the task at hand.

Asking our team members to interrupt each day for “only” 10–15 minutes has an undesirable compounding effect. The time wasted during that context switch is just as valuable as the actual time spent in the meeting. Multiply that across the number of team members, and you better be getting very real and apparent value from those stand-ups.

Personally though, I like the stand-ups as more of a team-building exercise than anything else. The benefits for us are more on the intangible side. As a company where we’re all dispersed around the globe, it’s nice to get each team together on a regular basis, even if it’s only for a quick stand-up. In reality though, I’d expect that if we had a stand-up meeting once per month that production wouldn’t suffer a bit.

The team is made up of self-organizing, cross-functional members, generally from 3–9 in size.

And now we get to the real meat of where we really vary in a huge way from a traditional Scrum project. First off though, I agree fully that a team should be limited to no more than 9(ish) people at any one time…so we can put that one aside.

It’s this concept of team construction that I really have the hardest time with, and I’ll start with the most egregious concept which is the concept of “cross-functional”. Seriously? Who in the world ever thought that was a good idea?

When it comes to my own personal health and maintenance, I would want a cardiologist to do heart surgery, and my dentist to fill a cavity, and my optometrist to test my eyesight. These people are specialists for a reason. There is no “cross-functional” general healthcare practitioner that I would want to trust every test, procedure and recommendation related to my body.

Why is that so different for software development? I won’t even bother getting into all of the specialties across different layers of the stack (front-end vs. back-end development for example), let’s just stick to the most fundamental issue of developers and QA team members. Expecting that either of them can do the job of the other up to our expectations is pure folly. And even more specifically, this becomes most apparent when developers are asked to perform the duties of QA, and in a typical Scrum scenario, this is often the case.

Anybody who has put any amount of time into using Scrum knows exactly what I’m talking about. The sprint gets down to the last few days and one of two things happens:

Either developers start finishing their assigned stories and there are no development tasks left in this sprint, or development continues to the last day, putting QA in jeopardy.

This of course is where the cross-functional concept comes into play. Supposedly, that developer who is finished early should chip-in and help QA to finish their tasks. Or maybe she has enough time to pull another development task into the sprint…which of course ends up putting QA into a bind at the end of the sprint. Or maybe, that developer is supposed to start “preparing” for the next sprint by studying the stories and doing any necessary research (which blows away the entire concept of pointing and velocity of course).

No matter how you look at it, QA ends up most often suffering in traditional Scrum frameworks, and if you want a business that lasts, that is the last place you want to cut corners isn’t it? Expecting a developer to come in and do the job of QA is simply unrealistic. And I say this as someone who used to do exactly that! (way back in my programming days — decades ago!). Isn’t it past time that changes?

I also say this from the perspective of my most trusted and productive developers that we employ. They are awesome developers. They rarely have bugs and can always be depended on. Even so, these are not the people that I want doing my final QA.

QA professionals have a skill set that developers don’t generally possess. They are trained to look for the edge cases, and the complex scenarios that a developer may not always consider. They use different tool sets and have a different view of the world than developers. It clearly is not right for anybody involved to put the squeeze on QA

Let developers do what they do best, and let QA do what they do best. Hire the best in class in both cases and set them loose to do their job! The quality of the software produced, and therefore the viability of your company depends on this.

The Big Reveal

Here’s where our company goes way off the rails and deviates from traditional Scrum. In short, we needed an approach that provides primarily for two things:

1. Allow developers the ability to devote as much of their time as possible doing development tasks.
2. Give QA personnel the necessary time to do their jobs not just adequately, but to the best of their abilities.

Expecting the entire team to start and finish a sprint on the same day works against both of those goals. Development and QA clearly can’t finish on the same day if each is doing the job that they’re best suited for. The best developers are not the best QA folks…that’s just a fact of software development.

So, here’s what we’ve done to accommodate both priorities. We technically use 3-week sprints which are comprised of 2, two-week elements that overlap for one week. The first two weeks of any sprint is for developers to work on development tasks. Starting at the end of the first week, QA begins their two-week effort. Once the developers are done with their two weeks of development, they move on to the next 3-week sprint and begin the 2-week development phase. Wash, rinse and repeat. Here’s a visual to give you a better idea of what I’m talking about:

As you can see in the image above, the dark blue and light blue boxes on a line represent a single 3-week sprint. The first week is devoted to development work, while the 3rd week of each sprint is intended to give QA ample time to complete their own work.

In any given sprint, the sooner that QA can get started on it the better. If QA finishes their work on a sprint early, there’s certainly no harm in pushing the build to validation whenever the customer agrees that it would be beneficial to do so.

In the end, this was the 3rd “leg” of traditional Scrum that we’ve decided knock down due to our team members’ feedback. And I must say, once again, that due to the desires of the team and at their request, we’ve ended up with a better mousetrap.

Conclusion

The last part of the topic above that we haven’t yet addressed is the concept of self-organizing teams. It’s one of the most important principles in our Scrum framework, however my definition of that may differ from others. I like to think that we as a company extend that concept to allowing the teams to decide how they want to work and listen intently to their preferences and desires.

Having done so, we now:

• Create story points based on the common-sense concept of a single point representing a full day of work.
• Limit ourselves to a single scheduled stand-up each week.
• Allow our team members to focus on the skill sets they do best.
• Provide our developers and QA dedicated time to complete their tasks.

In that light, it’s important to remember that what matters most is the end result and satisfying the end user. What should be of less importance is strict adherence to any particular framework or approach simply for the sake checking off the appropriate boxes. Do what’s best for you. Right now, this is what’s best for us…your mileage may vary.