You are here: Home // Agile, Project Management Practice // 3 Points That Cause Scrum Backlash

3 Points That Cause Scrum Backlash

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 program 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 item backlog) they’ll tackle within the next 30 days; this becomes the sprint backlog. The objective at the end of 30 days would be to have a working application with a specific number of features completed.

I’m a massive Scrum acolyte. On many teams, this makes me a minority of one. I’ve been on numerous teams that have utilised the Scrum project management methodology for both software development and technical documentation production. In each case, the backlash against Scrum was so wonderful that these teams ultimately abandoned it in favor of that tried-and-true methodology known as “Whatever We Had been Doing  Before Scrum”.

What exactly is it that makes teams resistant to Scrum? In my experience, you’ll find 3 significant blocking points. The great news is, none of these will need be fatal. Teams can – and ought to! – adjust Scrum to meet both the requirements 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 particularly averse to alter when it means far more function! And no doubt about it: particularly in its early stages, Scrum is function. The team must develop a item backlog, a lengthy list of items broken down into tasks less than 16 hours lengthy. Team members should assign projected expenses to their work quanta for the first time, typically for the very first time ever. Everyday meetings, whilst brief, interrupt the flow of the work day. (A lot 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 making use of Scrum really should take into account adapting several features at a time, instead of the whole kit and caboodle. For instance, a team can invest a month or two utilizing the idea of a sprint backlog, but not concern themselves much with hourly estimation or the daily meeting. Or the team can choose to go The Full Scrum, but use the process for a point release as opposed to a significant ship date.

2. Every person hates the every day scrum.

In Scrum, the entire extended team ¡§C which consists of development staff, management, and project stakeholders – meets each and every day for no a lot more than 15 minutes (ideally). This is known as the every day scrum. Every single team member is supposed to discuss three points: what they worked on yesterday, what they strategy to work on right now, and whether or not they’ve encountered any blocking issues that may avoid them from completing their function items this sprint. It’s the duty of the designated ScrumMaster for this sprint to facilitate the resolution of blocking problems.

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

In one of my teams, we have tried every single which way but loose to restructure the every day scrum. Considering that our team was spread all through the United States, we took to meeting by way of instant messaging, where everybody could paste their everyday status into the chat window instead of read it out. Eventually, we abandoned the every day meeting altogether, and returned to our normal weekly team meeting. We continued to send out a regular burndown chart, nonetheless, that showed how rapidly we were resolving work items, and whether we were on track to finish this sprint on time.

3. Estimating task duration might be a nightmare for some projects.

Wish to know how long a software program development or technical documentation job will take: Effortless: take your best guess – and double it! Schedule estimation is actually a black art that quite couple of of us master. Hell, most of us would be happy to be mediocre at it. It doesn’t assist 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 function together with management and also the product owner to determine which capabilities may be completed in the allotted time. Planning is typically done as a team effort with a game known as planning poker, in which team members repeatedly assign their greatest estimates to project tasks until the team reaches consensus.

This approach to planning doesn’t function well for all varieties of projects, however. Maintenance projects and technical documentation projects in particular are usually composed of many modest, discreet tasks that take far much less than half a day to total. For such projects, estimating at a finer level of granularity (much less than four hours) can be a nightmare.

Now, there’s no getting around the want for estimation for planning projects and controlling costs. But for numerous teams, there’s also no need to program every little thing down to the man-hour. One of my documentation teams routinely dealt having a huge number of bugs that had been infinitesimally little; these bugs typically took less than 15 minutes to fix. Right after a number of frustrating months of assigning time quanta to these function items, we ultimately settled on the concept of “t-shirt sizes”, rating bugs on a scale between XS (extra tiny) and XL (extra huge), 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 greater sense of just how much time each category of bugs consumed, and how many of every bug type we could resolve inside a single publication milestone.

Keep in mind that there’ no ultimate authority dictating that your team need to implement Scrum “by the book”. Like other agile methodologies, Scrum is absolutely nothing more than a collection of excellent ideas. Take what you feel your team can use, and take it an idea at a time.

Tags:

4 Responses to " 3 Points That Cause Scrum Backlash "

  1. Parthenia says:

    We are a bunch of volunteers and starting a brand new scheme in
    our community. Your site offered us with helpful information to work on.
    You have performed an impressive activity and our whole group will probably be thankful to you.

  2. Mable says:

    Fabulous, what a web site it is! This blog provides
    valuable facts to us, keep it up.

  3. Doеs youг websitе have a cοntact ρage?

    I’m having a tough time locating it but, I’d like to send уοu an email.
    I’ve got some recommendations for your blog you might be interested in hearing. Either way, great site and I look forward to seeing it grow over time.

  4. It’s a little worrying that you would decide to drop the Daily Scrum but, in reading your article, I think you may have issues with implementation.

    Contrary to what you said, the Daily Scrum isn’t intended for an entire, extended, team. It’s intended only for the Development Team.

    The idea is simply that they can synchronise their work and mention obstacles that they’re facing. Although time-boxed for 15 minutes, the Daily Scrum can be far shorter, if the Development Team so desire. It’s not intended to be onerous.

    Also, elsewhere in your article, you talk about Scrum being used on maintenance tasks. I venture to suggest that this is not what Scrum is best used for. I’d use it on new, and/or complex projects.

Leave a Reply

Copyright © 2010-2012 Home of Project Manager. All rights reserved.
Focus on project management. Powered by MyPmHome Team.