Get certified - Transform your world of work today


Live and Let Die

An Ethical Look at Task Management

1 October 2013

Haim Deutsch
Agile Spirit Ltd. (Former Agile Planet)

Live and Let Die is the eighth James Bond film, and the first with Roger Moore in the role of 007. This picture tells the story of Mr. Big, who decides to get the other drug barons by filling the streets with tons of free heroin -- until our famous agent puts an end to this plan.

Similar to stock exchanges, where we can sometimes see "blood flowing the streets," ScrumMasters and product owners sometimes flow to the streets with tasks, but not just tasks . . .  uncompleted tasks.

I mean automatically moving uncompleted tasks to the next sprints. After some time in the sprint, the team discovers that tasks are taking much more time than planned. The ScrumMaster, intending to uphold his team, and willing his team to taste success, moves these tasks to the next sprint. It happens also that our SM splits these tasks into two or more new tasks, declaring part of them as Done, and others as To Do.

The team is happy with this decision, which makes it look like an incredible team, completing its tasks.

The PO is comfortable, feeling that everyone is doing real Scrum, giving a clear vision of the real situation, and allowing him to easily get insights about the implications of longer tasks on the release plan.

The SM and the PO both feel at their ease, knowing that not everything will be finished by the end of the sprint but that this knowledge is helping them properly focus on reprioritizing the sprint tasks. In addition, they are not cheating; even if the tasks are split over sprints, the feature/story remains undone until the last task is done and its DoD verified.

In summary, we have a great team doing the best Scrum ever!

So please, explain to me why I'm feeling, at the least, uncomfortable with this practice, and as though we are missing something very central, something at the core of Scrum?

In my opinion, we are facing a deep moral challenge. As human beings, we are champions justifying improper comportment with ethical justifications. In my humble opinion, here we have one of these cases. Under the cover of acting for the best of the team, for the sake of improved transparency and procrastination-predictability improvement, we are hitting the very core of our values. As always in such situations, I'm asking myself: What do I get from this decision, and what price would I pay otherwise?

And the main question is why am I moving tasks that take more time to the next sprint? Why not just let them remain in the current sprint and finish it with incomplete tasks?

The answer I'm giving to myself is: RIP -- Real Invincible Principle. I want to look good. My pride dictates to me to throw away these irritating, incomplete tasks. As part of the team, I want to show a clean sprint backlog. As the SM, I may be feeling an inappropriately proprietary feeling about my team's accomplishments. As the PO, I want to show the stakeholders that everything is under control.

Now let's have a look at what we are losing by tricking ourselves:
  • If the sprint looks good, what is our incentive to bring up impediments during the retrospective? We are missing core information that would be really shocking if spread all over the board. It will not make us seriously invest energy in understanding why tasks took longer than planned. What could we have done differently? Where do we have to improve communication to avoid this situation in the future?
  • The secret of a genuinely hyperproductive team is its ability to self-organize, dealing with challenges and overcoming the obstacles. We will never succeed in training great athletes by removing the challenges; on the contrary. We don't only want to see teams able to meet their commitment; we want them to produce more and better products. Tasks are taking longer, so let the team to figure out how it will still succeed in meeting the commitment. This is the difference between stress and pressure. Stress is undesirable because it is the pathological aspect of pressure, but that doesn't mean that pressure is always bad. A sustainable pace always includes some built-in pressure.
  • SMs, always remember that you are not gardening your team, you are empowering it.
  • We are missing the chance to improve team spirit, to build closer work relationships and communication within the team and between the different functions in the team.
  • We are not adding transparency; on the contrary, we are adding chaos. We are showing false velocity, causing less clarity regarding our ability to meet milestones (this point turns to be crystal clear when velocity is computed as the planned task effort per sprint). The situation turns out to be much more acute when scaling the development, in cases of required synchronization between several teams with mutual sprint goals.
  • Within a couple of sprints, nobody will remember anymore what happened, nor will anyone be able to learn from mistakes.
  • We are teaching the teams and the organization that cheating pays, because everybody understands that this is cheating. Currently we have unfinished tasks, but they don't appear anymore. From there we open the door to more deviations. Why not change the DoD in the middle of execution, and why not get back to separating development from QA by redefining "tested task" DoD criteria to "unitested task" DoD criteria?
So be courageous, face the reality!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (1 ratings)


PREETI ARUN KUMAR, CSM, 10/20/2013 11:53:05 PM
Hi Halm, excellent article and a real practical situation that me and my team faces in couple of our sprint...the solutions we derive is either team puts in extra efforts to complete the task, more team members start working, or as you mentioned move on to next sprint...But I really want to understand how do we cope with this situation, what is the ideal solution for this issue.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up