My older daughter got married recently. About a month before the wedding, I realized I would dance with her and then with my wife at the reception afterwards. But uh-oh: I haven’t danced in quite some time. I needed lessons.
But I didn’t panic. How hard could it be? Patrick Swayze sure made it look easy. And I didn’t think my daughter or wife would be expecting me to hold them overhead.
It turned out to be quite hard, even though it looked so easy. As I struggled to learn, I realized dancing was much like Scrum: Easy to understand but hard to master.
Let’s look at eight reasons why Scrum is hard, probably even harder than learning to dance.
Problem 1: All Change Is Hard
If the new way of doing something were easier, you’d probably already be doing it that way. There’s usually a reason we’ve chosen to do something the way we have. A few months ago I noticed that I always whisk food in a clockwise motion. Just for fun I started whisking in the opposite direction. It’s hard.
When a team adopts agile it affects nearly every aspect of how team members do their daily work. A pervasive change like that is challenging. Even if team members are motivated to succeed at the change, there will be times they question whether it’s worth the effort.
It’s true: Something that is simple to understand can be difficult to master. To take some of the pain out of learning, give people a clear path to follow and a lot of clarity on the how and the why. My why for getting a dance refresher was that I didn’t want to embarrass my wife and daughter at the wedding; and my how was lessons.
Problem 2: Sprint Reviews Are Scary at First
Showing your work to others and hearing their opinions about it can feel like a threat to your self-esteem. Will they like it? Will the system crash during the demo portion of the sprint review? Did we do enough during the sprint? These are intimidating questions.
Yet these questions, and others like them, pop into our heads when Scrum teams first begin giving demos during sprint reviews.
The good news is that after a while, reviews become second nature. As development teams see the benefit of receiving fast feedback, they can shift to eagerly anticipating reviews rather than fearing them.
Problem 3: Knowing What to Do with Feedback Is Difficult
Even after team members become comfortable showing their work every couple of weeks, knowing what to do with all that feedback can be challenging. With feedback coming fast and furious, teams need to decide which feedback to incorporate and which to ignore.
There’s the timing of it, too: With a waterfall process, feedback is solicited at the end, after the team feels like the project is over. When feedback is provided more incrementally, every couple of weeks, teams can feel overwhelmed. They feel like they get further behind every time they ask for feedback.
One solution is to…prioritize your product goals. This will help you sift crucial feedback from details that needn’t be dealt with right now. After all, not everything can be Priority A.
Problem 4: All This Collaboration Seems Slower
Before I became a programmer, I worked in a darkroom developing photos. I started each day by taking a bunch of undeveloped film into my darkroom. I didn’t open the door until lunch, when I put the morning’s photos in a bin. I got lunch, a new pile of film, and sequestered myself in the darkroom until quitting time.
I liked the isolation. And that continued as a programmer when I’d put on headphones, turn up the music, and code in isolation all day.
So I can relate to those on agile teams who wish they could just be given a big task and then go away and do it for a couple of weeks (or longer) with no need to communicate until the task is done.
But the products we build today require much more collaboration than they did when I began my career. And sometimes collaborating with one’s teammates does feel like it slows us down.
The key is realizing that all the talking, emailing, messaging, and meeting helps prevent problems. What you hear and say in a meeting will sometimes not be helpful. But very often, in a well-run meeting, what you hear does solve a problem, and what you say turns out to be helpful to someone else.
Problem 5: Story Points Are a New Way to Estimate
The idea of estimating in story points can definitely be a challenge for many team members. I can almost hear them thinking, “I have a hard estimating in days and now I have to estimate in an abstract relative unit I’ve never heard of before?”
Story points are a definite challenge, yet they’re worth the effort. As abstract relative estimates of effort, story points enable better conversations about how long work will take.
Without story points, a senior programmer and junior programmer have conversations that devolve into, “That’s how long it will take you, but it would take me twice as long.” And then the two pick an estimate that is horrible for one of them or, perhaps even worse, they split the difference.
With story points, the senior and junior programmers can consider adding a new feature and both agree it will take twice as long as doing a simpler feature. They then give the bigger item an estimate twice that of the simpler item.
Estimating in this relative manner allows developers to agree even if they would never be able to agree on how many hours or days something would take. Bonus: story points discourage managers from comparing team velocity.
Problem 6: People Complain There Are too Many Meetings
A common complaint about Scrum is that there are too many meetings. It’s a fair criticism, but I don’t think it’s justified, because each can be quite efficient. Let’s consider the recommended duration of the meetings of a two-week sprint, as summarized in the table.
| Meeting | Time per Two-Week Sprint (Hours) | |
|---|---|---|
| Daily Scrum | 1.5 | |
| Sprint Planning | 2 | |
| Review | 2 | |
| Retrospective | 1 | |
| Backlog Refinement | 1.5 | |
| Total | 8 |
That’s about eight hours. So is eight hours of meeting time in a two-week sprint too much? First, keep in mind these numbers are conservative. Seven hours may be a more realistic total. Eight hours is a lot of time, but I don’t think it’s excessive.
Meetings in Scrum are like the lines on the highway. The lines are there to help drivers proceed quickly and safely. Scrum’s meetings should feel the same way. They keep team members safe by ensuring they each know what the other is doing.
The meetings should help the team move more quickly by creating opportunities for communication. If your team’s meetings do not feel like the white lines on the highway, consider shortening or eliminating a meeting.
Problem 7: It Isn't Easy Being a Scrum Master
You are right. Scrum isn’t easy. And it isn’t easy being a Scrum Master either. But most jobs aren’t easy when you’re new to them. Stick with it long enough and it does get easier.
And by this point, there are plenty of books, courses, online forums, and more about being a Scrum Master. You’re never too far from advice.
Problem 8: Being a Product Owner Is a Tough Job
If you thought being a Scrum Master was tough, try being the product owner. Product owners get it from both sides: Teams ask for clarity and more details, customers and users ask for features. Being a product owner requires balancing these competing demands for their time.
Scrum Is Hard But It’s Worth It
Adopting a Scrum approach is hard. There will likely be times you want to throw your hands up and go back to what you were doing before.
Usually those thoughts are quite fleeting. Stick with it, though—I’m sure you’re already far better at it than I am at dancing. And I haven’t given up yet. I’ll stick with it if you will.
What Do You Think?
What aspects of Scrum have you found hard? Were there times when you were tempted to abandon it? Did you stick with it? Was it worth it? Please share your thoughts in the comments below.
