Skip to content


Agile Scrum | Three Things That Cause Scrum Backlash (And How to Fix Them)

Most people hear the word “Scrum” and think of something that’s stuck to the bottom of their shoe. Au contraire. Scrum is an agile software development methodology designed to foster iterative and incremental development. Scrum projects are broken down into 24-hour development cycles contained within 30 day sprints. Team members agree upon which work items for the product (the product backlog) they will tackle in the next 30 days; this becomes the sprint backlog. The goal at the end of 30 days is to have a working application with a certain number of features completed.

I’m a huge Scrum acolyte. On many teams, this makes me a minority of one. I’ve been on several teams that have used the Scrum project management methodology for both software development and technical documentation production. In each case, the backlash against Scrum was so great that these teams eventually abandoned it in favor of that tried-and-true methodology called “Whatever We Were Doing Before Scrum.”

What is it that makes teams resistant to Scrum? In my experience, there are three major blocking points. The good news is, none of these need be fatal. Teams can – and should! – adjust Scrum to meet both the needs and temperaments of their members.

(1) No one likes adapting a “new process.”

People are creatures of habit. Most of us don’t like change. We’re especially averse to change when it means more work! And no doubt about it: particularly in its early stages, Scrum is work. The team must create a product backlog, a long list of items broken down into tasks less than 16 hours long. Team members must assign projected costs to their work quanta for the first time, usually for the first time ever. Daily meetings, while short, interrupt the flow of the work day. (More on the daily meeting below.) All of this sudden change breeds anxiety, resentment, and fatigue.

Scrum is structured as an iterative and incremental process. Ironically, most teams don’t take an iterative and incremental approach to Scrum! Teams aiming to tackle projects using Scrum should consider adapting a few features at a time, rather than the whole kit and caboodle. For example, a team can spend a month or two using the concept of a sprint backlog, but not concern themselves much with hourly estimation or the daily meeting. Or the team can decide to go The Full Scrum, but use the process for a point release as opposed to a major ship date.

(2) Everyone hates the daily scrum.

In Scrum, the entire extended team – which includes development staff, management, and project stakeholders – meets every day for no more than 15 minutes (ideally). This is called the daily scrum. Each team member is supposed to discuss three things: what they worked on yesterday, what they plan to work on today, and whether they’ve encountered any blocking issues that will prevent them from completing their work items this sprint. It’s the duty of the designated ScrumMaster for this sprint to facilitate the resolution of blocking issues.

In theory, the daily meeting is a wonderful idea – a regular check-in that brings all stakeholders together in a collaborative atmosphere. In practice, everyone hates it. In a corporate world chock full o’ meetings, the daily scrum is just one more meeting. And, for most team members, it’s a boring and useless meeting. Unless you are significantly behind or have encountered blocking issues, the daily scrum feels like a waste of time.

In one of my teams, we have tried every which way but loose to restructure the daily scrum. Since our team was spread throughout the United States, we took to meeting through instant messaging, where everyone could paste their daily status into the chat window rather than read it out. Eventually, we abandoned the daily meeting altogether, and returned to our regular weekly team meeting. We continued to send out a regular burndown chart, however, that showed how quickly we were resolving work items, and whether we were on track to finish this sprint on time.

(3) Estimating task duration can be a nightmare for some projects.

Want to know how long a software development or technical documentation task will take: Easy: take your best guess – and double it! Schedule estimation is a black art that very few of us master. Hell, most of us would be happy to be mediocre at it. It doesn’t help that, in the words of Rockwell, it always feels like somebody’s watching us: if our estimates are incorrect, we’re afraid that the Managerial Wrath of God will descend upon us.

Scrum’s stated goal is to empower developers to control their development schedule. Managers and the product owner can (and do!) still set drop-dead dates. But team members themselves assign time estimates to each task, and then work together with management and the product owner to determine which features can be completed in the allotted time. Planning is usually done as a team effort with a game called planning poker, in which team members repeatedly assign their best estimates to project tasks until the team reaches consensus.

This approach to planning doesn’t work well for all types of projects, however. Maintenance projects and technical documentation projects in particular are usually composed of many small, discreet tasks that take far less than half a day to complete. For such projects, estimating at a finer level of granularity (less than four hours) is a nightmare.

Now, there’s no getting around the need for estimation for planning projects and controlling costs. But for many teams, there’s also no need to plan everything down to the man-hour. One of my documentation teams routinely dealt with a large number of bugs that were infinitesimally small; these bugs usually took less than 15 minutes to fix. After several frustrating months of assigning time quanta to these work items, we eventually settled on the concept of “t-shirt sizes,” rating bugs on a scale between XS (extra small) and XL (extra large), with each rating assigned an approximate time range (XS = under 15 minutes, S = 15 to 30 min. and so on). Over time, we developed a better sense of how much time each category of bugs consumed, and how many of each bug type we could resolve within a single publication milestone.

Remember that there’s no ultimate authority dictating that your team must implement Scrum “by the book.” Like other agile methodologies, Scrum is nothing more than a collection of good ideas. Take what you think your team can use, and take it an idea at a time.

Be Sociable, Share!
    The following two tabs change content below.

    3 Comments (Add Yours)

    1. it seems you are doing “scrum but”. you are doing scrum, but don’t have daily standup meetings, then you are not doing scrum. you are doing scrum, but don’t estimate your tasks, then you are not doing scrum.

      this can be good or even better than scrum in your environment and your problem domain, but this also misses the benefits from practicing these parts.

      but you are right, be agile and eliminate the problems you encounter. the question to you is: would you sacrifice scrum over your own solutions and doing a “scrum but” or could you find another way and doing scrum the way it is intended.

      also you are getting some things wrong on scrum. the only people which are required at the daily standup meeting is the team, not the scrum team. the scrum master and the product owner can come, but they mustn’t. stakeholders and all others are only welcome, if the team decides that they want these people. mostly this makes no sense, because the daily scrum meeting is time boxed to 15 minutes. after that it is hard terminated. so if your team consists of 7 developers, every one has only 2 minutes to answer these 3 questions. there is not much time for other things.

      also, scrum only give the advise to use the planing poker to estimate your tasks. you can use other methods, if they suit your problem domain better. but the planing poker is a very exact way to guess your estimates. 😉

      • I recognize the problem with the teams not being able to cope with the daily meeting. Continue to insist on having this meeting, my experience is, that in the end everyone will come to accept it and even find it very usefull. I have also tried having members from different timezones in the team (Denmark and New Zealand), so we had the daily meeting on mail, and once in every sprint we had a video conference. It worked very well and this team was actually the team with the highest performance.

        If your team is experienced and used to estimate tasks, I do not think it is necessary to use planning poker. I am only using it with inexperienced teams or if some disagreement arises.

        Remember only the Scrummaster and the team members have the right to speak on the daily meeting. If there are other participants they can not speak. I always ensure that this is the case, because the daily meeting is dedicated to the team.

    2. Not bad. I don’t think it’s so bad having devs pick their practices and thus being not pure Scrum; the two ‘Agile’ corps. I’ve worked at have done ‘Agile’ with /management/ doing the picking. If in practice it’s impure anyway, why /not/ let the devs bend it their way?

    Add Your Comment (Get a Gravatar)