Scrum Smells: Going Along To Get Along

  1. Posted on August 5, 2009 6:54:PM by John Clifford to Retrospectives
  2. Methods & Processes, Technique, Agile, Scrum, Management, processes, product owner

A question was posed on one of the Scrum discussion forums recently about changing the sprint backlog during a sprint. The scenario was as follows: the sprint has been running for 2 days when the Product Owner comes to the daily standup and wants to replace a committed sprint backlog item with one of equal size in the product backlog. What should the Scrum Master do?

As this was a real question posed to the forum, I wondered how often the Product Owner comes to the team two days into a sprint to rearrange the sprint backlog? What a stinky Scrum smell this is.

One of the major hindrances to getting something done is the Tyranny of the Urgent. The reason that Scrum keeps the committed sprint backlog inviolate is to provide the team the ability to keep their heads down for the sprint instead of constantly being whipsawed by context switches forced on behalf of the crisis du jour. If the level of uncertainty is very high in an organization, the proper response isn't to relax Scrum rules by allowing changing the sprint backlog during the sprint, it is to shorten sprint duration so the organization (and the Product Owner) know that, at most, they'll have to wait for no more than two iterations to get a specific item.

In my experience, the importance of changing the backlog during a sprint is almost always greatly exaggerated. (The 'importance' is usually due to someone outside the team dropping the ball on a commitment, and trying to cover it up by breaking the Scrum process.) Scrum has a mechanism for ascertaining if it should be done, however, and that is by forcing the Product Owner to make the call on whether or not to abandon the current sprint and replan with the updated backlog. Yes, this will cost up to a team-day. But following the Scrum process is exposing your problem, not hiding it, and there is a problem here. Are you going to address it, or sweep it under the rug by enabling bad behavior?

I know, some people will wonder what the big deal is. Why not just go along to get along? My response is to reiterate that Scrum is as much about improving the organization as it is organizing project work. Why waste a great opportunity for improvement? What I like about this particular scenario is how it shows whether you truly understand that Scrum is really a tool for improving the organization instead of just another way to manage a project or set up the workflow. Sure, you can go along to get along by swapping out backlog items and getting the Product Owner off your back, just as you can put a penny under a blown fuse and get the lights back on, but you haven't solved the problem. In fact, you've made it more likely to blow up.

Others will wonder if this somehow violates the Agile principle of responding to change over valuing a process. I'm all for responding to change. What I'm against is abandoning the Scrum process, and I'm suggesting that there is a very good reason for the few simple rules that Scrum has. One of those rules is that the sprint backlog with the corresponding commitment is locked at the moment commitment is obtained and the sprint starts. Scrum allows for changes to the sprint backlog during an iteration; abandoning the sprint and replanning and restarting a new sprint. As an aside, if you're following Scrum you shouldn't be dropping items from the sprint backlog during the sprint either; that is just a way of hiding what is truly happening. Instead, during the retrospective the team should discuss why committed sprint backlog items couldn't or wouldn't be completed during that sprint, or why the team undercommitted (if new items are continually being dragged into the sprint backlog), and then brainstorms to arrive at a solution to this problem.

Stephen Covey, of Seven Habits fame, says that "courage is integrity at the moment of choice." Scrum, or any other way of doing things, won't work if the people involved lack courage, if the prevailing philosophy is "Can't we all just get along?" instead of "Do the right thing." The Scrum Master needs to demonstrate some integrity in this situation and require the Product Owner to follow the Scrum process. Either abandon the sprint or leave the backlog alone. Then, during the retrospective, a discussion on why the backlog needed to be changed should be held with the goal of trying to figure out what caused this (genuine unforeseeable emergency, bad PO planning, someone dropped the ball on a commitment, etc.) and how to prevent this in the future. Otherwise, expect constant pressure to change the sprint backlog.

Chad said:

August 6, 2009 7:36:AM

Preston Covey?  Do you mean Stephen Covey?

John Clifford said:

August 6, 2009 1:34:PM

Yep, I mean Stephen, not his brother Preston :-) (another interesting read). Thanks for the catch.

John Clifford said:

November 19, 2009 10:29:AM

Hi,

IMO, the "unspoken" contract of not changing the backlog mid sprint also relates to breaking the collaboration principles... i.e. is a bit like cheating the PO is cheating the team... if it happens once, it starts breaking the trust cycle.

I wrote on this topic a bit more previously in my blog.

http://bit.ly/3ikYmP

yes, yes, self-promotion... but it is relevant!

Victor said:

November 8, 2011 2:47:PM

To me this sounds like a crystal clear case of scrum fundamentalism. "It says in the Scrum manual that I cannot change anything in the sprint, therefore I can't cause then I wouldn't be doing scrum"

Instead, ask yourself if it is beneficial to add the item. Would the customer benefit from it, will this add value to product etc. Don't bother if it's scrum by the book or not.

Confused about modifying the sprint backlog during said:

May 23, 2012 12:08:PM

Pingback from  Confused about modifying the sprint backlog during a sprint | DIGG LINK

Post a Comment:

 
 

John Clifford

John Clifford is a Senior Fellow and Agile Practices Lead at Construx Software where he focuses on software development, project management, portfolio management, product management, and organizational management practices. John has three decades experience across the software development and organizational management spectrum, working for small startups and the world's largest software company. He has been an individual contributor, development manager, group project manager, development director, and CEO.

John has worked on software for everything from microcomputers to mainframes, in domains as disparate as mobile telephony platforms, desktop applications, asynchronous device drives, and computer-to-computer telecommunications. He has developed software in assembler, C, C++, .NET, and Java on platforms that include CP/M, Unix, VAX VMS, MVS/TSO, MacOS, Windows, OS/2, Windows CE, and Linux. He understands project management as a successful practitioner, and as one of the original software developers on Microsoft Project for Windows. His product management skills include the design and creation of industry-recognized software, and he has helped clients focus on the essentials to deliver more quickly with higher revenue.

John has led numerous successful Scrum and Lean-Kanban adoptions, and his clients include several Fortune 500 companies with locations across the US, Europe, and Asia. He holds Certified Scrum Master, Certified Scrum Product Owner, and Certified Scrum Professional certifications for the Scrum Alliance. He is a charter Kanban Coaching Professional, at the invitation of the Lean-Kanban University. He presents at Lean, Agile, and Scrum conferences, and has been recognized for his knowledge and ability in the application of Agile and Lean principles to all facets of software project planning, management and execution.

 

Contact John