Common Scrum Pitfalls

December 28, 2012
By

Scrum is a highly viable software development methodology, and the teams implementing Scrum seldom experience failure. However, it would be wrong to assume that Scrum is a panacea for all sorts of problems and impediments surfacing during the development process. As a matter of fact, if the team implementing Scrum fails to deliver, Scrum is not to be blamed as a process by itself never goes wrong; instead, the shortcomings and flaws lie in the implementation of that methodology. To put this in other words, there are a number of pitfalls that a Scrum team can fall into as a result of which things can go haywire and the whole purpose of implementing Scrum can be defeated. Some of the common Scrum pitfalls are mentioned below:

  1. Excessive Up-front Planning – Scrum teams should not indulge in up-front planning; rather, the team should begin coding and development straight away. There is no point in wasting time on deciding the Product Backlog much in advance as the feedback gathered during Sprint Reviews and Retrospectives is important in planning the subsequent sprints.
  1. Focus On Tools – Tools are not important; people and processes are. So, there is no need to worry about tools. ‘Finding the appropriate tool’ is just an obstacle to getting started, so the teams should start with the development right away.
  1. Problem-Solving in the Daily Scrum – Daily Scrum is neither for discussing problems nor for finding solutions to those problems. Daily Scrums should essentially be time boxed to 5 minutes and be limited to answering the three questions.
  1. Management or Stakeholders managing the team – Scrum requires teams to be self-organizing and self-managing; therefore, neither the management nor the stakeholders should try to manage the team or should assign them work. On the other hand, the team too should not wait for either the Project Manager or the Team Lead to delegate the tasks to the team members.
  1. Scrum Master As a Contributor – Scrum Master is a specialized role; a Scrum Master is supposed to be watcher and a facilitator, not a developer or a tester. So, he should not be assigned any other duty. Also, he should not direct the team in what to do and what not to do as this would distract him from monitoring whether or not the team adheres to the Scrum principles.
  1. Imposed Deadlines and Resources – Scrum teams know best what to complete in a particular Sprint, so neither the stakeholder nor the management should try imposing deadlines or prescribing resources as this would not only demotivate the team, but also reduce their productivity and the quality of the software produced.
  1. Distributed Team – Scrum prefers collocated teams as distribution of team members impedes direct and open communication which in turn reduces productivity and quality.
  1. Product Owner Doesn’t Show – Presence of the Product Owner in Daily Scrums and Retrospectives is essential as he is the bridge between the technical team and the stakeholders. Since feedback given during the Retrospectives is important in planning the succeeding sprints, the Product Owner’s presence is vital.
  1. Stretch Goals – Since Scrum follows the iterative and incremental model of development, the team pre-decides what to do in a Sprint. As such, neither the management nor the stakeholders should try to overload the team with more work as this will result in decreased efficiency and in increased resentment.
  1. Individual over Team – Scrum believes in the dictum that Scrum team swims or sinks together. So, individuals should not try to work beyond their prescribed roles. Overtime as well as individual heroics should be discouraged.
  1. Fixing problems over restarting the Sprint – Failure in immediately restarting the Sprint is one of the major pitfalls. This happens because the team makes itself busy in fixing problems surfaced in the previous as a result of which the project gets extended beyond the stipulated time.
  1. Product Owner Specifies Solutions – Problems are bound to surface during the development process; however, the team, not the Product Owner should come up with the viable solutions to such problems. This is because the team is well versed with the technical aspects of the software under development.
  1. Compromising On Quality – Delivering a high-quality, business valued, and potentially-ship-able product is the very foundation of Scrum; however, many teams tend to give up on quality due to limited resources or due to pressure to release features. This is one of the most common Scrum pitfalls.
  1. Ceasing to learn – Scrum believes in evolutionary development, and this requires constant learning on the part of the team members; however, the team members cease learning and acquiring knowledge about the processes and techniques. This is because they assume that they have come to know all that there is to be known about this methodology.
  1. Frequently reconstituting Scrum team – A scrum team should comprise of experts in order to make it a high-performing team that delivers quality products. Practically speaking, it is very tedious and difficult to form such a team. So, shifting members frequently not only brings down efficiency and productivity but also demotivates the team members. Plus, this is wastage of precious time.

The above discussed points are the common pitfalls that a Scrum team can fall into; however, there can be number of other pitfalls as well since Scrum is a highly flexible methodology and software development is quite a dynamic activity. Whatever may be the scenario, Scrum teams can avoid such pitfalls if they adhere to Scrum principles as closely as possible.

 

Share

2 Responses to Common Scrum Pitfalls

  1. Catherine Morgan
    January 7, 2013 at 12:40 PM

    I agree to most of the points.

  2. February 15, 2013 at 10:11 PM

    Thanks for the nice list.
    Three more major pitfalls IMHO are:
    * not to measure your team development (by using agile measurements) and being able to verify that improvements really work (leading to a lack of subjective assumptions about the progress and intransparency for management)

    * having no top management or even worse no management commitment. Sooner or later you’ll face the border of the bottom up implementation and it gets really hard to cross this line if TMM is not committed.

    * too less POs or powerless POs – as this shifts often too much effort on the team in preparing the sprint and endangers the understanding of agile product development.

    Sebastian

Leave a Reply

Your email address will not be published. Required fields are marked *

*


× four = 16

Subscribe

Follow Us On

Post-Plugin Library missing