How to Screw Up Your Scrum

scrum stand up meeting

When it’s done right, a scrum-based environment can turn a stagnant, slow-producing development process into an iterative wonder. Unlike waterfall or XP that is linear and more like a relay race, scrum depends on team dynamics as well as individual commitment.

Effective software development is more about the team and its commitment to the process and not the framework being adopted. You can have the best scrum implementation plan in place and it won’t do you any good if the teams and individuals involved choose not to follow the rules or constantly challenge the process. Adoption of a process meant to improve and drive development in an iterative way can be challenging; but the end result is that all involved and committed parties work together and produce a high quality product.

However, scrum is not an easy framework to work with, especially when your team is used to the traditional software development process. Development teams that are new to scrum can derail their process without realizing it. The following are the most common and insidious ways to screw up your scrum.

Let Someone with Little Management Experience Act as the Scrum Master

Great scrum mastery requires experience working with development teams in general. You can’t fake that or attempt to learn it on the job. An inexperienced scrum master can demotivate and derail a project unintentionally just because he doesn’t have the background to guide the team.

The scrum master doesn’t have to be a technical genius but should be someone who understands which roles need to be filled (Business Analyst, UX, Developer) and how to find help for any impediments team members may encounter. Effective scrum masters act as both servants and leaders. Their job is to do everything in their power to make sure that the project moves forward. They need to motivate, inspire, and help the individually committed team member deal with any impediments to completing their tasks. The scrum master is not there to tell the team how to do their jobs, but to help them with whatever the team members need to make sure the job gets done.

Be Inconsistent

Either scrum or don’t scrum. Don’t scrum haphazardly.

Originally designed for small teams, the agile nature of scrum lulls people into thinking it’s acceptable to skip a process here or there. One reason that scrum adoption succumbs to inconsistency is that newly minted teams tend to jump in with both feet and expect all the elements to be perfectly executed from day one.

Perfectionism works against agility. Even if you don’t feel like “scrum” is being done exactly right, continuing to push through the process builds confidence across the team. Attending daily stand ups and weekly sprint planning and retrospectives should not be negotiable. Attendance and engagement is most important for consistency.

My friend Laura Klemme is a certified ScrumMaster. Her biggest issues with guiding scrum teams is that Product Owners are so busy they don’t really iterate across sprints as they should. Once a sprint is completed, the Product Owner should bring the results back to the stakeholders for feedback; then that feedback is rolled into the next sprint. However, she found, in most cases the Product Owner (a user representative) meets with the stakeholders/users at the beginning of the project but does not go back to them again until the project is done. This introduces the possibility of dissatisfaction with the end result because no one confirmed that the features being built are what the end user asked for in the first place. One way to relieve an overtaxed Product Owner, she suggests, is bringing on a UX manager who can coordinate the product backlog (or have the coordination included as part of the sprint).

Skip Daily Stand Up Meetings (or Sit During a Stand Up)

It’s a sinister thing; you don’t realize that you are skipping meetings until it’s too late. That’s especially true for those of us who tend to be self-directed. We put our head down and dig into a code base; the next time we look up it’s hours later.

If you have the usual 5-7 member scrum team then a daily 15 minute standup meeting should become second nature. What did you do yesterday? What are you doing today? And what, if any, impediments got in the way? It may seem like this is of no intrinsic value and get easily bypassed but this daily round of questions can make the difference between successfully meeting sprint guidelines and having to explain why you didn’t get things done during the retrospective.

The daily stand up provides a number of things, beginning with the positive “yay team” of acknowledging we are in fact going in the right direction. But it’s even more important to respond to changes and problems. Because of the iterative nature of scrum a simple statement from a stakeholder can change the requirements in a heartbeat. If you don’t stop to take stock in where you are and what has been accomplished, on a daily basis, time and money could be wasted on unwanted or unnecessary features.

Sadly I’ve been in stand ups that looked just like this parody:

Establish Sprints with No Clear End Goals

What is not started today is never finished tomorrow.”   — Johan Wolfgang von Goethe

Determining what can get done during a sprint takes a lot of experimentation. You’ll overestimate and underestimate on a regular basis until your team recognizes how long it takes to get things done. It’s better to set a goal and not quite reach it then to not set a goal at all.

What is considered done? That’s the first thing you need to decide on as a team. Is “done” releasable code? Is it code that’s gone through testing? Whether you strive to complete an entire story or certain tasks within that story, know what your deliverable will be at the end of the sprint. The sense of accomplishment will encourage you and your team to take on a bit more (or reduce your work load!) depending on results. You must establish that goal each and every time or you’ll find yourself unable to track whether progress is being made. Lack of progress ultimately leads to frustration and indecision.

Rule with an Iron Hand

With scrum – and any Agile process – you want your team to work in a quick iterative manner, but you have to give the team members the room to work within their own comfort zone. As scrum master you are not really “in charge” of your project in the traditional sense, as decisions are made by the team. Unfortunately, this introduces issues with unproductiveness and failure because there is no clear direction.

The other end of the spectrum is running the project so tightly it frustrates the team and they stop producing. “Management will end run the Scrum process by asking for special work to be done by individuals on the team,” says Laura Klemme. “This is ‘unplanned’ work and is off the board. Totally disruptive. But, management has the mentality that the higher ups don’t need to follow the process;  they can ask for things and everyone will jump for them. Most of the time, the work was known about in advance but the management just didn’t ask for it when the sprint backlog was being created.” The bottom line is that management can be the worst offender for a team trying to stick to a scrum process, she says, since managers are used to managing by demand.

Scrum, when implemented correctly, feels good, not painful or an exercise in drudgery. If the process feels wrong than it probably is being done wrong.

All hope is not lost even if you do fall into a pattern that is leading the team to a methodological implosion. The immediate solution is to gather your team and determine if any of the aforementioned issues are throwing a wrench into your progress. If they are, then step back and evaluate how to fix it. Fix it as a team, and you’ll encourage ownership of the scrum implementation by everyone involved.

See also:


  1. Jessica Darko says:

    The funny thing about Scrum, like communism, is whenever you point out that it doesn’t work, people say” they weren’t doing it right!”. It’s a religion more than a process.

    Here’s the bottom line: If you’re having daily meetings… that is, every day you destroy 3-4 hours of each programmers time with a stupid pointless meeting, you failed and you should not be managing programmers.

    If you need to know status, issues, blocking, etc, get that asynchronously by having the programmer update an issue in an issue tracking system or any of a million other alternatives that don’t involve wasting programmer time.

    Also, it’s wrong to make programmers stand for 15 minutes while some idiot “scrum master” drones on about BS. Oh yeah, I know, if they’re droning on, they’re “not doing it right”…tell you what– find a video of a perfectly executed scrum meeting, and you’ll have 15 minters of an idiot droning on.

    SCRUMM is a management technique developed by non programmers that is foisted on programmers (and kids who don’t know any better) as The One True way.

    My life got a lot better when I stopped being a pushover and letting incompetents impose mindless BS like this on me and my team.

    IF you are going to do SCRUMM, make the “master” stand, and give the programmers the power to leave at any point. I shouldn’t have to stand for your stupid meeting… I don’t even want to be there… and in fact, I would never show up. (I’d be back updating my resume in this hypothetical situation, but the reality is, I run my own business and manage my own team of programmers so there’s nobody around to bring their cargo cult religion into the office.)

    PS- I don’t know who “Donna Snow” is. I can’t find any evidence you’re a programmer, so I’m going to have to guess that you’re a “project manager”. Let me tell you something, you don’t understand the process of programming and you shouldn’t be writing articles on the internet about it.

    I know, “smart bear” wants to SEO optimize and so spewing this kind of content is a strategy…. but the fact of the matter is this kind of article indicates that you’re a company without proficiency in the very market you seem to want to sell into!

    • But why are you mad though?

      • Jessica Darko says:

        I’m one of those people who finds stupidity, or more precisely, the choice not to think, to be offensive. I wouldn’t say I’m mad, though.

        It is a tragedy to see a whole generation of engineers have their skills squandered by terrible management techniques.

    • Donna M Snow says:

      I’m sorry to hear that your experience with Scrum has been so negative. 3-4 hour long meetings? That is crazy long and I’ve never been stuck in one that went on-and-on like that.

      Poor management is poor management regardless of the industry, but good managers can make their team achieve success in a number of different environments (they are also great timekeepers and know how to move things along without being insulting).

      There are good Scrum Masters just like there are bad Scrum Masters. It doesn’t matter which industry you are in any environment that encourages discontent through lack of regard for key players is heading for a crisis.

      The daily stand up is just that a daily stand up and if the “manager” is sitting down and treating his team like second rate citizens that’s just an example of a bad manager. It doesn’t mean the process itself is broken.

      The daily meetings are not exclusive to Scrum, I’ve found they come in handy in any team situation where the end result is a one cohesive piece, like a news report. A reporter could be out in the field every hour of the day reporting on what’s happening, but it helps to bring them in and hold quick editorial meetings to make sure they’re on track, working on the right piece, and that they don’t have any road blocks in their way. That’s how a good manager runs meetings – whether it’s an editor or a Scrum Master.

      I’m interested to hear what sort of process or tools you use to manage your team. It sounds like you found a way to work with your team without the annoyance of daily meetings?

    • NewsMaster69 says:

      Totally agree Jess… It is absolutely exhausting listening to people who have never ONCE complied anything in there entire lives. I was just told today by the scrum master that she is technical and she has a computer science degree…… FROM 1971!!!!!….. Really!? It is a soul crushing model to force intelligent people to be dragged into nonsense and the second you speak up you are labeled a problem child….. Seriously, I’m just ready to give up on this whole sector….. No wonder so many indians are in this field. They never say no, use communication as an excuse and can disappear on a whim…. oh he had to go back to india for a week…. smh

    • Wow – clearly from an (angry) developers point of view. However, producing a software product is NOT all about the code and it is not all about developers. IT IS all about a TEAM of different skillsets producing a solution that the solves a problem for a client. I am a software developer turned systems analyst and back in the day, programmers did everything from analysis to deployment. And unfortunately, it produced a number of spectacular failures.

      Scrum may not be the ultimate methodology for producing software, but it is a heck of a lot better than the old ‘toss the requirements over the wall’ waterfall processes that allowed developers to do whatever they felt like doing whenever they felt like doing it, regardless of whether it solved the problem or not. Scrum forces everyone to be accountable and I see no problem with that, but clearly some people do…

      • For some people the old way you describe has never existed in the real world. I’ve only ever encountered it once and that was a case of very dysfunctional management. Sure things went better after they introduced scrum, but they also ripped the upper management and replaced them. Truth is they could have continued without scrum and still been successful.

        In no other place have I seen requirements tossed over a wall or programmers doing whatever they like with no regard to solving the problem.

    • That’s clearly not Scrum at all, stand ups should be everyone talking for a minute and 3-4hr meetings about what? That’s the real problem with Scrum, it’s trendy to say you’re doing it and too many people think they’re clever enough to make sweeping changes for no reason that harm the process. Hey if they’re using the terminology then it’s still agile right?

      • Jasper A. Visser says:

        Obviously, he means 3-4 hours total time for the whole development team. If we assume there are 9 people in his team, then a 20-minute meeting costs a total of 3 hours.

    • @Jessica Darko

      Scrum was actually a framework created by software developers -> mistake no.1.

      Daily stand-ups (huddles we call them), don’t even last for 15 minutes, in our case it’s only 5. If you respect the condition that the Scrum team shouldn’t be over 9 people that is -> mistake no. 2. And we sit btw. Still works.

      Daily stand-up never took away from the devs time -> mistake no.3. If it does, you don’t plan it properly (you can do 5 minutes first thing in the morning, before they even start working).

      Daily stand-ups are used by other frameworks (Agile) also, and in other situation (product teams, purchasing teams, etc. used this method for quick, productive meetings in my former companies) -> mistake no. 4.

      Scrum was implemented at the request of devs in our company (we are a over 200 people company).

      Scrum process is entirely lead by the Dev Team – why do you put so much power into the Scrum Master? In our case, the devs decide: when to have the meeting, how to do their work, how much time the work takes, have a heavy say on sprint goals and what needs to be delivered. They hold the entire power in Scrum, not the SM. The SM is there to solve conflicts and remind them that meetings need to be held, people have to be present etc.

      Most of my work – as SM by the way – is following up on feedback from devs on all the above. If they ever said the daly huddle takes away from their dev work, I’d do something about it.

      Scrum is a framework. It fits some companies, doesn’t others. But the way it sounds to me, you had a really bad SM (btw there is no management in Scrum, the Scrum team it’s an entirely self-organised team, and the Scrum Master is NOT a manager, doesn’t tell people WHAT to do, or HOW to do their work, WHEN to meet, just has to find solutions for removing impediments and making sure devs can work uniterrupted and most efficiently).

      How many people are in your company? How do you work? Instead of cursing and blowing off here with hatred, how about you tell us what worked for you when Scrum didn’t?

    • And Jessica Darko… ad hominem is not the best argument, actually it’s a logical fallacy. Surprising to come from a software dev, the people I work with have an entirely different language 🙂 The ones that are critical of Scrum have proper arguments. You’re just venting off, with nothing useful said. I’m really curious to see the product you guys work on, and meet your devs 🙂 It sounds to me they need a good SM to talk to.

  2. Hi Donna,

    Thanks for this nice article. We figured out that standup meetings are great but needed improvement (they took a lot of time and de-focused our colleagues). Because of this we developed a SaaS tool to “automate” the daily standup meetings – with just a single email. If you like to take a look:



  3. It would be great if you did an article on how to deal with the Jessica Darkos out there. As a new Scrum Master, I find it challenging and encounter her sentiments often.

  4. Vinod Mahadik says:

    Great article! If the activities are performed by an scrum master or someone who has a good experience,chances are it won’t screw up. QuickScrum is a leading scrum provider, they also train and coach employees for better management and hassle free implementation.

  5. Interesting claim regarding who should be the scrum master. My experience is exactly the opposite, that management people are the last ones who should be doing it.

    Stand-ups can be redundant. I know this is anathema to scrum evangelists, but teams are capable of organising themselves without a daily report back.

    Whether goals are necessary must depend on the team. The teams I’ve worked with know what they’re working on and how far they are without any need for a goal. Having a goal made no difference to their morale either.

Speak Your Mind