When should you NOT use Scrum?

August 21, 2013

I was asked this question in a class recently.  (When should I not use Scrum?)  I gave an answer, but I want to give a better answer, or at least a different one.

To be fair, it is a hard question. And a hard question for me.

My personal answer, which I gave, is I have been doing projects for 20+ years in lots of environments. I cannot think of a single project (product, effort) that I would not have wanted to use lean-agile-scrum on (ie, use Scrum as the core).

Did I make projects work with waterfall, and have some success? Sure.  And I feel sure that I could have had much more success with Scrum.

***
Are there other types of work other than what I have done?  Of course!

So, when would I not want to do Scrum?

I gave two examples.

1. If two people on the 7 person Team say “I hate Scrum”, then I probably would not do Scrum with that Team.  Almost surely they will make it fail.  Maybe you would do waterfall instead.  (I might fire myself, though, and get myself on another Team.)

2. If they give you an impossible project (say 18 months of work that must be done in 12 months), and if you don’t succeed they will fire you — then, I recommend waterfall.

Management won’t really know how the (waterfall) project is doing.  Just say: Green.  You will have plenty of time to work on your resume, post it on Monster.com (or CareerBuilder), have some interviews, and get a new job.  It is important that you protect yourself and your family from these jerks (or this situation). (Firing someone for not accomplishing the impossible is being a jerk.)

Some people laugh when I describe that situation, but seriously, you have to protect yourself.  As you are leaving, wave goodbye and tell them the project is RED.

***
Are there other cases?

A. If the Team is doing exactly the same project again, and you can accurately predict that no other significant change will happen, then maybe consider waterfall.  (How can you accurately predict the future?)

B. If you have a completely dysfunctional Team, …well, I wouldn’t do Scrum or Waterfall or anything. Get yourself off the Team!

C. If you can’t get anything like a real Team.  Not stable, no Team coherence….then maybe I don’t want to use Scrum.  Really I think that knowledge creation in a Team is so key to all our work, so I want to go to ‘management’ and say ‘You all are not committed to getting this done, so let’s delay the project until you are committed and we can get a real Team.’

D. No one on the ‘team’ is at least 50% dedicated to the Team.  Then not Scrum, again.  Probably nothing else either.

E. People allocated 50%, but clearly no prospect of moving the allocation above 50%.  Umm, makes me question using Scrum. Or even doing the work.  Give us work where you do want to allocate people 100%.  (If the work is important, 100% allocation is the only reasonable thing to do.  Well, … a later post.)

F. Skill sets that are not ‘overlapping’ at all (eg, A-skill people can not help with the work of B-skill people).  In the time line, we need to do A-work early, and B-work later.  In light doses, we have this scenario to some degree every time.  In small doses.  In this specific case, it is extreme.  There is no use in a cross-functional team.  Should we use Scrum?

I suppose one might use Scrum and a (small) Scrum Team to get the A work done, and then another Scrum Team to do the B-work.

But lots of questions.  One: if this is such a big impediment, why can’t we fix it?

***
You get some ideas.

Ultimately, it depends on common sense (as Ken Schwaber says).
Then he says: And common sense is very uncommon.

***
More later on other situations, and some ideas on the best conditions to start Scrum.

 

« « Creativity and Process || When would I not want to do Scrum? » »

Posted in: Better Agile, Getting started
Tagged: Tags: , , , ,

13 thoughts on “When should you NOT use Scrum?”

  1. Andrew Rusling

    I would not recommend the use of Scrum when the rate of business change is predicted to be higher then 25% of the teams work for 1 week. (1 week being the shortest available sprint length)

    One example of this is a Production Support team.

    ↓
    1. Joe Little Post author

      Hi Andrew,
      Why?

      First, let me assume that it is useful to be a Team.
      For example, by knowledge sharing, knowledge creation and working together, we can do better work (faster, high quality, something like that).

      And let’s assume we have items (support tickets) that could easily fill 50% of the work of a Sprint.
      So, we put those X items into the Sprint at Sprint Planning Meeting.
      And then we leave the rest of the work of the Sprint undefined (for now).

      But as items come in during the Sprint, the PO decides how to triage them. And the Team estimates them.
      And decides during the Sprint how many additional items it can do.

      And the business stakeholders review ‘what we did’ in a kind of demo at the end of the sprint.
      And we also do a Retro to deal with bigger impediments.
      Seems like it could be a pretty good Scrum. To me.
      What am I missing?
      Thanks, Joe

  2. Marie-Noëlle Baechler

    There is also the case of a very weak committment from the client (“I want something, but you have to guess what I would like”). And there are many cases where some people like DBA or system engineers are allocated much less than 50% to a given project.

    ↓
    1. Joe Little Post author

      Hi Marie-Noelle,
      1. Weak commitment. Yes, definitely a common problem. And if it is very low, a very big problem.
      2. Missing skill sets. (There are other ways to describe this problem.) Well, also very common.

      But some people assume that all people and all skill sets MUST be in a or the Scrum Team. I don’t see that as required.

      Yes, it would be better if a Scrum Team had 100% of the skill sets in the (fully-dedicated) team to ‘git-r-done’.
      But I find seldom is this the case.

      But hopefully we only are missing a small % of the skill sets. Let’s say 5%.
      As you say, a DBA is a very common example of this.

      Imagine 7 teams and 3 DBAs. Each of the Scrum Teams needs a DBA, but the 3 DBAs can handle (most of) the DBA work that arises.

      A partial solution is that each Team nominates one person to start learning to be a ‘junior DBA’. And then each Team manages the flow of work into its DBA (if one assigned) or into the DBA group. Clearly to my Scrum Team, the DBA or DBA group is a chicken, and hence not reliable. So we (my Scrum Team) must devise some way to manage them to achieve our success.

      So, the team must ‘manage’ the people outside the team, and ‘make’ them deliver those skill sets in a way that leads to team success.
      The Team must always deal with some chickens with special skill sets. And it MIGHT kill the team’s work, but usually it is a manageable impediment. And if we attack the impediments right, not such a bad problem. Or so I find.
      But it is, as you say, a very common problem.
      Thanks, Joe

  3. Jay Naro

    Joe, I would like to contribute to this interesting question, you know, I have more experience using the core of knowledge of the PMBok with iterative and incremental approaches in projects and with great success but also as Scrum practitioner and methodologist I would like to add some comments about you have mentioned here.

    When I started to learn and use what lean-agile-scrum was, I have found and I identified three mainly “impediments” to use SCRUM! Yes Impediments! because If you as a Scrum Master or Agile-Scrum practitioner cannot remove these implements , you cannot use agile-lean-scrum because It is going to lead you into failure.

    Moreover in my career I have learned a lot of methodologies to manage and control IT projects. Each methodology, model, approach, framework or whatever is has a main purpose and it tells you when you need to use it according with the TYPE OF PROJECT because each of these approaches has advantages and disadvantages. For example we have the rolling wave approach , spiral model , waterfall , RUP, PMBok approach, agile ( including scrum, lean, kanban, etc) , structured methodologies (such as Yourdon/De Marco, Gane&Sarson) and SO ON….

    to me, talking about SCRUM, the particular question raised here (in this thread) has two angles/perspectives:
    1. List of impediments / External factors of the project
    you need to identify and remove the external Factors (such as a list of impediments related with people, organisational structures, etc ) for avoiding you fail in the project. At a certain point if a list of impediments leads you into the failure several times, it is better to change your current approach. And I agree with you as you mentioned in your blog about the list of impediments that you have listed.
    2. the NATURE OR TYPE of the project
    the TYPE of the project tells you WHEN you need to use a particular “approach” and It is not a list of external factors which affect the PROJECT ( such as a list of impediments )

    by the type of the project, I mean :
    – Fixed price projects
    – Risky and not clearly defined projects
    – Follow the sun projects
    – Repetitive or predictive projects.
    – Maintenance or ongoing projects
    – New product development
    – Research
    – Critical projects with strict regulations and documentation
    – and so on….

    actually, people know that any model, framework, approach, or whatever is CAN FIT and BE USED in any project but you will have to DEAL with its disadvantages and risks .

    To me , it is now clear when and where I can apply/use SCRUM
    and even better, if you are able to identify in which cases SCRUM has disadvantages in your project, I know I need to DEAL with its risks in order to use it properly. 🙂

    ↓
    1. Joe Little Post author

      Hi Jay:

      I like your distinction between impediments and ‘type of project’. They are two different issues.

      Here is your list of project or work types:
      – Fixed price projects
      – Risky and not clearly defined projects
      – Follow the sun projects
      – Repetitive or predictive projects.
      – Maintenance or ongoing projects
      – New product development
      – Research
      – Critical projects with strict regulations and documentation

      Good list.

      My view is that Scrum is better than waterfall for all of these. I have done some of all those types.

      Now, I would agree that with each work type you would play Scrum differently. You would add different things to Scrum.

      For example: On the regulatory and document-required project — sometimes you have to treat that stuff with PBIs (their own stories) or in some other way. But there is no inherent problem between Scrum and critical projects.

      But, no doubt your projects or work have been different than mine. So, please give us an example of one of the issues you have had.

      Also, I would be interested in an example of where you think using Scrum would lead to failure. Having a dysfunctional team or having a team with the wrong skill sets could lead to failure. Or an impossible deadline. But I think you had a different thing in mind. What is it? (or are they?)
      Thanks, Joe

  4. Joe Little Post author

    There has been a bunch of discussion about this post in many places.

    Most of what I am hearing are ‘impediments’. Or at least so they seem to me. And, I guess is the impediments are serious enough, I would not attempt to do the work. Using whatever method we may have.

    But, as Ellen Grove observed, the PURPOSE of Scrum is to surface impediments, so they can be addressed (and sometimes pretty well ‘fixed’).

    Yes, Scrum has other purposes, but it seems fair to me to say that its main purpose is to help to identify and prioritize the impediments.

    Which raises the question — what is an impediment? Which I will talk about in post soon.

    ↓
    1. Malapine

      So perhaps the <140 character answer is:

      "You should not use Scrum if you already see blindingly obvious impediments, and you know they aren't going to be addressed."

    2. Joe Little Post author

      Hi Malapine:
      I always have the hope, and sometimes later it turns out to be true…. that even fools sooner or later must bend to reality. If we show it to them often enough. And Scrum shows it to them pretty often (eg, at the end of every sprint for some things).

      Perhaps more to the point: I have confidence in you, your ability (with time) to explain and learn and reason with people. And you will get them to address the impediments. Eventually.

      Despite many many impediments we can still get some work done. Usually. And I think always better with Scrum than Waterfall.
      Also, Scrum helps you identify your biggest impediment at any moment. Better. (Scrum helps them see; they do have to open their eyes and also think. But Scrum helps a lot compared to waterfall.)

      But you are right. At some point you can give up. Hence the phrase: “If you can’t change your organization, you must change your organization.”
      Human beings, as we see daily, can be wonderful. And then also, extraordinarily foolish. Extraordinarily! As we see daily.

      Let us be honest. Compared to the very few great ones who have walked this earth, all of us ‘great’ agile guys are hopelessly broken, incomplete and impediment-ridden. From the viewpoint of the great ones. And then, as we look ‘down’ we see all these other guys who are even more ridiculously screwed up than we are. (Let us just speak now in terms of doing new product development work). But let us have compassion and patience. However slowly (and sometimes very very slowly) one thinks that maybe everyone is on a path to getting better. Some for now are further up the path, some back. But all are moving. However twisted the path may seem at any moment.
      Regards, Joe

    1. Joe Little Post author

      Hi Russ,

      Well, maybe it sounds that way. Not really.
      Your question and that other blog post say some important things and deserve a longer answer (in a blog post coming soon). For now let me some quick things.
      1. By the blog form, I am restricted from explaining ‘everything’. Sorry. For example, my assumptions or limitations.
      2. I love Lean and Kanban. BUT, I feel most of what is known as Kanban (in the software dev area) is really, IMO, not very good. Still the cards are good, as far as they go. But the team is lacking the discipline to use them in a rigorous system in something like the way Taiichi Ohno intended when he invented Kanban. ….BUT…this basic thought takes some explaining if it would be convincing to a Kanban advocate.
      3. Software ‘kanban’ is good at least in this way. If you can’t get anything else to change, then if you can at least get them to start visualizing the work with cards, at least some of the problems will be a bit more … visual. Easier to see. And that is a good step forward.
      4. I should have said: Software kanban requires almost nothing. It is too loosy-goosy. All we have to have is a board and some cards and something ‘flowing’ somewhere. That is IT. No enough (almost always, IMHO). Now, many people who do software kanban add things. Such as a team. Such as a daily meeting. One of the key things they should do is at least review all the Scrum stuff and ask themselves: why are we not doing each one? (Of course, this begs the question: why do those crazy Scrum people advocate doing each part of the bare framework of Scrum? Most people can not explain every part well. And if they do not understand it, they will likely not judge well when to do it, and when not too.)
      5. I am concerned that you and the blogger are making the bare framework of Scrum far far bigger than it is. It is no more than what is in the Scrum Guide.
      ***
      For now: long story short, you ask a very good and complex question: when should we use Scrum or X or Y or Z or waterfall? Many many many many situations out there. So even if you ‘understand everything’ it is a long time to discuss.
      More later! Thanks! Joe

  6. Chris

    I would not use Scrum on building a house. Would you? it’s too big and complicated, and the risk of lateness and overspend is too serious, I’d use waterfall. Comments??

    ↓
    1. Joe Little Post author

      Hi Chris,
      You did not explain all the assumptions.
      If you build a house “the current way” (that includes no real team, lots of vendors that are relatively uncontrolled and who deliver when they want, lots of specialized skills that we get from very different people….)….if you have all those conditions, and do not improve ANY of them, yes, it would be hard to do it with Scrum.
      Well, Scrum would make very clear that VELOCITY is near zero and progress is slow.
      Useful.
      If you change some of those conditions, I think you could.
      Should you have SOME architecture before you start building? YES!. That does not mean you cannot be “agile”.
      ***
      Very good question that forces some key thinking.
      Not sure my short answer answers it as completely as it deserves. I will try to come back later and explain more.
      Thanks!
      Joe

Leave a Reply