If Scrum isn’t agile, a SaaS solution could be

This article is contributed by Nick Hodges, developer advocate at Rollbar.

It’s been about 20 years since the Agile Manifesto was released. While the manifesto itself is great, many of us have been a touch misguided in our implementation of it. 

Let’s all be honest — how many of us have actually read the Agile Manifesto? If you haven’t read it, read it now. I’ll wait.

Interesting, isn’t it?

Scrum seems to be by far the most popular way to “implement” agile development. There are scare quotes there because I’m not sure that Scrum can actually be considered agile. In fact, in a way, Scrum might actually be the exact opposite of what the Agile Manifesto is all about. And it’s time that we all admit that.

That’s a pretty bold claim. Here are the three main reasons why this could be the case:

• Scrum creates false deadlines.
• Scrum can’t and doesn’t always deliver working software in one sprint.
• Scrum ceremonies create busywork.

False deadlines

Scrum has you break your work into “sprints,” usually a two-week chunk of work where a developer agrees to complete a given amount of effort (usually measured in hours or Story Points). At the end of every sprint, the developer is supposed to deliver working software — something that in theory could be delivered to the customer.

Well, not every project fits into a two-week sprint. What if the work is actually three weeks long? That’s a conundrum. Scrum tells you to break the work down into two portions: one that is two weeks long and one that is one week long. Then, of course, you have to determine what to do with that extra week at the end of the second sprint because you need to deliver working software at the end of that sprint, too! 

Scrum creates all these deadlines and makes you fit your project into them whether that project likes it or not. And in my experience, most projects don’t like it. All too often, a project is a single entity — it either works or it doesn’t — and breaking it into deliverable chunks isn’t really possible. And even if you do break it down into pieces, those pieces cannot be considered functional software to be delivered to customers.

Working software in two weeks?

Delivering working software every two weeks makes a huge assumption — that work can be divided into deliverable, functional, two-week chunks. Sorry, but we all know that this simply isn’t the case. It just doesn’t work that way all the time. It’s like trying to fit a square peg into a round hole. 

Sometimes a project will take three months to complete. Creating false deadlines for that project every two weeks just doesn’t make sense. It creates overhead and false divisions of work that make things inefficient. An eight-week project is an eight-week project, not a 4 or 2-week project. Trying to make it so is simply wasted time and effort.

Standing on ceremony

Scrum dictates that you have a 15-minute daily stand-up, a one-hour backlog grooming session, and a one-hour sprint planning and retrospective session. Then, many teams even do a one- or two-hour sprint demo at the end of each sprint. 

If I have my math right, that’s at least eight hours of time every two weeks spent in meetings that — well, let’s be honest — don’t all need to happen. If those meetings run over — as they tend to do — that is more than a whole workday every two weeks. 

The backlog grooming session is typically spent trying to break large projects down into those two-week chunks. You get out the knife and try to cut that large piece of cheese into exact, equal pieces, two weeks long. You get it done, but really, some of those chunks are probably weirdly shaped. 

Then, you conduct those sprint planning meetings and take those weird chunks and fit them into the slots of your sprint. Maybe it makes sense how things work out — or maybe not. You also do a sprint retrospective to figure out what might be done better.

And then every day you get together and tell each other how it is going with those weird chunks. 

At the end of those two weeks, you’re supposed to have something that you could ship to customers. But how often is that really true? I’m guessing it isn’t very often. Most often, you’ve taken the time to break a 10-week project into five artificial two-week slices, none of which are actually deliverable until they are all done.

When you can’t be agile

There are certain situations where a software development organization simply can’t be agile.

The first is where there is a fixed deadline. If there is a deadline, you almost certainly can’t make adjustments that may be necessary to finish the project. Changes to what you are coding almost always mean a change to the date. What happens if, when you do the sprint review with the customer, the customer asks for changes? You can’t roll back a whole sprint, redo the work in a different way, and then still ship according to a contracted date. If you can’t adapt to changing requirements, then you aren’t being agile.

The second is when there is a fixed cost. This works very similarly to what I described in the previous paragraph — if you are only getting paid a set amount to do a project, you can’t afford to redo portions of the work based on customer feedback. You would very likely end up losing money on the project. 

Bottom line: If you have a fixed deadline or a fixed amount of time, you can’t strictly follow Scrum, much less the Agile Principles.

Hard to call it agile

In the end, the Scrum methodology is hard to call agile. It usually doesn’t deliver working software as it says it should. It calls for a lot of time-consuming ceremony time. It creates busywork as you try to split up something that doesn’t really want to be split up. It’s a mystery to me how this system was thought to meet the principles of the Agile Manifesto in the first place.

What will actually work

Okay, so I’ve made some bold claims, but I’ve backed them up. So, here’s a solution.

Your feature list will naturally divide into projects — projects that may vary in size and complexity. Embrace that. Accept that projects are different, individual endeavors. Then, do the following: 

• Figure out your best estimate about how much work each project is. 
• Put the projects in priority order, as estimated, on your schedule. You may have to play a little “Schedule Tetris,” but that will be doable.
• Assign a developer — or developers, if you think that will work better — and give them the specification. 
• Set them on their way developing the project.
• Bother them as little as possible, but keep an eye on what is going on. Have daily standups if you want, but keep them short and on point — as in “Do you have any questions or problems?” and be fine if the answer is “Nope” and the meeting is two minutes long. (Also, have that meeting on Maker’s Time.)
• When it makes sense, check in with the customer (whether that be the product manager or a real live customer) to see how things are going. Err on the side of doing this more rather than less.
• Make adjustments as necessary. Accept that things might take longer than you planned as a result.
• Deliver the project when it is done. (I’ll leave the discussion about what “done” means for a later time…)
• Meet and talk about how the project went well and could have gone better.
• Repeat this process — in serial and in parallel for as many projects as your team’s capacity can handle.

At this point, I have to ask — which of the Agile Principles does this method not satisfy? I’m going to go with none. This system hits all the principles and will deliver software when it’s ready — not any sooner, and not any later.

I don’t know what the writers of the Agile Manifesto think of Scrum. I just know what did and didn’t work for me, and Scrum never seemed to make sense. This plan always made sense to me: Figure out the project, do the project, and then deploy the project.

Note that I’m not advocating for a return to the Waterfall methodology here — far from it. Checking in with the customer is a critical part of the process. Adjusting on the fly is still a critical part of the process. 

True agile

I’ve proposed a way to do software development in an agile manner. It’s pretty straightforward. Can it actually be done? If so, under what circumstances are best? 

To answer these questions, I’ll make one more assertion: Being truly agile wasn’t really possible until one could do Continuous Integration (CI) and Continuous Delivery (CD) via a SaaS solution.

Another bold statement, I know. But hear me out — this is pretty cool.

The agile SaaS Model

The typical SaaS application is a web front end with a backend API that serves up JSON. Because the vendor typically controls both sides of this equation, it can make changes to either whenever it wants. 

Or, put another way, the vendor can continuously deliver new functionality to the customer, whether it be daily (or hourly!) bug fix updates or features delivered immediately upon completion. Your code and your project are continuously improving. You no longer have to hold completed work “in inventory” waiting for the next big release to deliver value. Value is delivered as it is created.

So, as a result, the following is not only possible but commonly done with modern software architectures:

1. A project is defined and assigned to a developer (or developers).
2. The developer(s) completes the project using the above methodology.
3. They merge their code onto the main branch.
4. The CI/CD system detects the merge, builds the new code, runs the tests (which pass), and then deploys the new code immediately.
5. By utilizing a feature flag, the code is only visible to the few customers who have agreed to beta test the feature.
6. The developer gets immediate feedback about the code from beta testers.
7. If changes or adjustments are required, the code changes can be rolled back, changed, and redeployed.
8. Repeat steps six and seven as necessary until everyone is satisfied.
9. New functionality is delivered to the entire user base immediately by removing the feature flag.

It’s really enabled by the SaaS model, which makes deployment simple and easy for every customer. Instead of having to wait and install a heavy client on every customer site, you can immediately deliver new functionality to all customers with the push of a button. 

Now that, my friends, is agile.

Don’t follow an arduous plan or a strict process

The Agile Manifesto was forward-looking. Perhaps too much so. And I believe it’s been pulled away from its original moorings. 

The Agile Manifesto explicitly states as its base premises:

• Individuals and interactions over processes and tools.
• Working software over comprehension documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

I feel bad saying this, but it’s hard to see how any of those four statements are satisfied by Scrum. The first and the last are particularly germane, as nothing could be “following a plan” more than sticking to Scrum no matter what. And what is Scrum but a strict plan to follow?

The Agile Manifesto foresaw what was to come and actually can be realized in the SaaS model. Perhaps it was just 20 years too early.

Nick Hodges is a developer advocate at Rollbar. He is a seasoned development technologist with over 30 years of leadership experience and a passion for leading, developing, and mentoring diverse development teams.