The Short Answer?
Scrum is an Agile methodology that takes the story-based method and puts it on steroids. It is intended to be the silver bullet that vanquishes the Waterfall Werewolf and drives Agile Classic into a shame spiral that leaves it weeping in the dark corner of the basement in a pool of its own urine and scope-creeping requirements filth.
In pure theory, Scrum makes huge sense. Small, frequent releases, daily stand-ups, work tracking. On paper (or screen), that all sounds springtime fresh. But I have never seen it implemented in a real-world environment that lives up to its own theory.
What Scrum Does Well
Where scrum succeeds is that it creates an effective development execution and deployment machine. I have observed with pride how the development teams are able to bust out their stories quickly, and get them deployed effectively. There is no question that as a development methodology Scrum can be viable and successful.
I can’t even count how many nights I’ve spent over the years of midnight deployments of the behemoth 18-month Waterfall releases, with their massive complexity, overbloated scope, and propensity for failure and the inevitable dreaded rollback.
Scrum is highly effective at generating results fast.
When you need it to, it can be agile, no pun intended. We spend a good portion of time in UXI (User Experience & Interface) reaching out to users via quantitative surveys, 1-1 interviews, and combing through our site analytics for ways to improve our sites.
One of our applications is for managing domain DNS & Zones, which allows users to change settings for domains. It was setup with a progressive disclosure interaction that had several expandable/collapsible sections. This experience let the user open each section individually and make changes, then save their changes for each section. The theory being that due to the complexity of the settings, they would be more digestible in smaller, targeted chunks.
Earlier this year, we received some feedback from users that suggested the more tech savvy users wanted a faster, more holistic way to view and interact with those settings. Our solution was to introduce an “expand all” link at the top of the settings that opened all the editable sections at once. This let the user open and view all their settings, make their changes at the same time, then click an overall “Save” button. Fewer clicks, happy users. We also included a checkbox to save the layout so anytime the user returned to the page, the sections remained all expanded for them.
It is a small change with a big impact to usability and user satisfaction. Scrum can lend itself nicely to these kinds of small wins, if it has short sprints, and frequent releases to production.
How Scrum Sucks
Vision vs. To-Do List (Or Strategy vs. Tactics)
At a company that had implemented Scrum, I once asked a product owner “What is your vision for your application? Can you tell me where you want it to be in a year? Two years?” His response was, “I have 100 stories in my backlog.”
A backlog full of stories is not anywhere near the same thing as a Vision for his product or application. What he was describing was his To-Do list. When I reviewed the list, it was filled with stories about “add this form field” or “add an export function to this table” or “add templates”.
It was all tactical. It was not cohesive. There was no strategy. There was no rhythm to the rhyme. It was as if Animal from the Muppets during the middle of an especially furious drum riff, simultaneously vomited right onto the snare, exploding a splashy chaotic fireworks display of chunky spew in all directions with each slam of his sticks.
That was their Vision.
Without strong, solid, vision and leadership from product owners, Scrum often devolves into the priority du jour. It is tough to have a long-term vision when you are trained to look at everything in the context of a two-week sprint.
One drawback that the speed of Scrum introduces is that often quality control is tough. When a team is SO focused on speed — especially when they have an almost religious devotion to Scrum — sometimes the quality suffers. Sometimes it suffers lots.
I recently had a business owner come to me and complain about how some newly deployed features remained unused by any of the site users. These were features that users had requested and desperately wanted, but when they were deployed… (crickets). My first stop was at my analytics which yielded no answers, there was simply no traffic post-deployment. My next stop was to go to the pages themselves, and this is where I found the culprit.
The developers had simply tacked the new features into the main site navigation, at the bottom of a hierarchal submenu so over-filled and tall that the menu dipped well below the bottom of my 1920×1080 screen. These new features had fallen BELOW the fold, and even when you attempted to scroll down, the menu disappeared. There was literally NO way for users to even see the features, let alone access them.
According to Scrum, was this a success? The story was clear, and it was completed quickly in 1-2 sprints. It went live without a single hitch. On paper, this was exactly how Scrum was supposed to work. And yet the fundamental purpose of the function was missed, and in the end, it was a miserable failure.
Are We Missing the UX?
I once had a boss who did not quite understand how User Experience worked. He would use this wholly inadequate analogy that UX was like a library book that you occasionally took off the shelf when you needed it. And then you put it back when you were done. I was never successful at penetrating his myopic view of the User Experience. Not even when I countered with analogy GOLD such as:
“User Experience is the dish and utensils for every meal served up. If you are serving soup, it might be faster and cheaper to serve it in a strainer and give the diner a chopstick and 3 crayons you found in your kitchen junk drawer. But in this case, the speed and cost are far less important than making sure the meal is served in the right dish, with right utensils, in a way that is consumable and enjoyable by the diner.
User Experience should be part of the discussion in every part of the process, in every meeting about the feature, every stand-up.” – Aaron B. Case
OK maybe I only silvered in Analogy, but it is still a far more accurate description of how important UX is. It is equally, or in many cases, MORE important than the code portion, or the security portion.
Library book. Hmph! A pox on all your houses.
Collaboration vs. Competition
I have often said this one absolute truth in regards to Scrum:
If you need Scrum to keep your people in line, you have the wrong people.
Do you really need that much oversight and control over your people? Look we are all professionals (or at least semi), if we have a task that needs to be done, we will do it. If we need clarification or help, we will ask. If we are given deadlines, we will meet them. You should be able to trust and rely on your teammates to do their job while you do yours.
If you can’t, then there is a problem with your TEAM, not your PROCESS.
Waterfall in Disguise
Here is the unspoken secret people don’t want to talk about with Scrum. What I have seen happen again and again and again (did I mention again?) is that when stories are completed, they frequently get bucketed together into a larger release and then pushed to production. In theory, you are supposed to have something deployable with each sprint.
But because of the sloth-like overhead associated with things like UAT, QA, OPS, overloaded deployment schedules, I have never seen that happen. Not once. What happens more often than not, is that stories keep getting bucketed into larger releases — monthly, quarterly, even bi-annual. Larger releases, less frequently. That is the antithesis of Agile.
And to that, I will simply say this…..
If you are doing quarterly or bi-annual releases, you are not Agile. You are Waterfall with a slightly streamlined requirements process.
Scrum Can Be Great
With the proper vision, team, UX, quality oversight, and timeliness, Scrum works just fine. I’ve just never seen it live up to that bar. Without addressing the inherent weaknesses in the Scrum process, you will not get better results than Agile Classic, or Waterfall.
You’ll just get those results faster.