When not to Scrum? PDF Print E-mail
Written by Ed Willis   
Thursday, 05 April 2012 00:00

Do not Scrum!In Scrum training sessions, someone would invariably ask variants of these questions:

  • What kinds of projects aren't a good fit for Scrum?
  • When would you advise against adopting Scrum?

I always managed to get caught flat-footed by those questions.  I'd stumble through some sort of response but all the while I knew I hadn't really given the matter enough thought.  This article is intended to address that.

When should you not Scrum?

My approach is simply to review what Scrum asks us to do and then imagine projects and environments where this will be either prohibitively difficult or less useful.  I know I have not been exhaustive - I have no doubt that my own experiences and biases have shaped what I've listed.

One point regarding difficulty - many coaches and trainers aim right for the hardest problems in the hopes that a they'll put a big dent in the overall organizational impediments to agility.  I don't think that's necessarily wrong but do think it risks outright failure that will be hard for teams to overcome.  Most of the below items can be properly characterized as impediments of some form and so, in reality, each would speak to the potential value of adopting Scrum.  That said, Scrum adoption (like any other organizational change initiative) is typically very sensitive to early failure - it may be better to start successfully and then build on that to larger and more significant successes than to fail by less and less each sprint.  So an impediment that dramatically increases the chance of failure (even if it really is something that would be valuable to fix) may be sufficient reason to not do Scrum at a given moment in time.  That said, if team desire is strong enough and the sponsorship determined enough, there's little doubt that these obstacles can be surmounted.  The lists below then are not so much contra-indications for Scrum in an organization are they are indications that adopting Scrum may be more likely to fail in the absence of really solid organizational resolve - in which case, they may suggest that this isn't the right time or situation in which to try adopting Scrum.

Organizational culture:

  • Being open and honest about impediments, project progress and team performance is likely to be punished.
  • There are obvious, critical organizational impediments that are currently impossible to remove so impediment identification and retrospectives will become exercises in futility.
  • There is strong opposition to Scrum in powerful segments of the management group which really need to be on-side to give the teams a fighting chance.

Project management:

  • Management will not yield to the team's judgement in areas Scrum leaves in their hands like estimation, scheduling, team processes and norms, and design decisions.
  • Rational estimates are not valued in the organization (for example in an organization that typically sets dates aggressively early in the hopes that, while these dates will almost certainly not be achieved, they will nonetheless drive earlier schedules than would otherwise be the case).
  • There is a strong contingent of project managers or a PMO that will not yield ownership of project management to the team.

Engineering:

  • Engineering practices in place in the organization have waterfall lifecycle assumptions baked in (possible examples include things like architecture review committees, Byzantine change management processes, complex traceability processes, time-consuming review and approval processes and a high degree of reliance on manual testing done in regression passes reserved for late in the lifecycle).
  • Assessing done-ness in a meaningful way is currently too expensive in duration or effort to be performed each iteration (tons of manual test cases, external compliance testing).
  • It is currently impossible for the team to produce something demo-able in even a longish sprint.
  • The current software architecture makes defining Scrum teams that can produce "Sashimi" slices of working product difficult because even minor changes affect everyone.
  • The current software is extremely brittle, making the costs of change prohibitively high.
  • All requirements must be delivered (e.g. implementation of a published standard, some contract situations) - there's little point in prioritization by value (because backlog items have uniform priority) or in backlog grooming (because there's very low requirements volatility).

People:

  • There is more than one person feeding requirements to the team and naming a single Product Owner is impossible or no candidate can be identified who is willing to spend the time product ownership in Scrum demands.
  • No suitable candidate can be identified who is experienced or knowledgeable enough to fill the ScrumMaster role.
  • Organization structure makes it impossible to form cross-functional teams (e.g. the organization is structured along functional lines and the test manager wants to do Scrum but the development manager does not).
  • The team really doesn't want to do Scrum.
  • Turn-over is excessively high - retrospectives will have a tougher time producing sticky value and team dynamics will be shifting so much that team productivity will suffer.
  • Everyone is so specialized in the work they do that forming a feature team becomes next to impossible - the minimum number of people who can produce a working end-user visible feature is much higher than 7+/-2.
  • The organization's geographic distribution makes feature team formation very difficult due to (e.g.) language barriers and time zone differences.
Last Updated on Thursday, 05 April 2012 15:37