Collaborator-8-3-CTA-banner

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:

Collaborator-8-3-CTA-article

subscribe-3

Comments

  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…

Trackbacks

  1. […] the whole scrum process AKA: “Either scrum or don’t scrum. Don’t scrum haphazardly.” Take the time to learn it for real and get good at it, especially retrospectives. Attend a few […]

Speak Your Mind

*