Skip to main content

Should Our Team Use Scrum?

October 30, 2017

As a travelling Scrum and DevOps consultant I’m constantly asked “should our team use Scrum”? Now you might think that being a Professional Scrum Trainer – and serious Scrum fanboy – I would always answer “Yes!”. Well, you would be wrong. I frequently talk people out of Scrum – for the right reasons.

Professional Scrum Trainers know how hard it is for a team to adopt and practice Scrum successfully. Therefore, we want to make sure the nature of the work is right for the Scrum framework. To that end, I’ve come up with five simple, mostly non-scientific, yes/no questions that I use to survey the inquisitor.

My Five QuestionsFive questions

  1. Do you have at least three technical people to do the work?
  2. Are you developing a product/increment? (vs. just doing one-off/unrelated work)
  3. Is the majority of the work large enough to require a team? (vs. smaller, individual task-sized work)
  4. Is the majority of the work complex? (per the Stacey model)
  5. Is the majority of the work plannable? (vs. unplanned/support type of work)

If the person answers “yes” to all 5 questions, then I’ll recommend they move forward with Scrum. If there are 3 or 4 “yes” answers, the Scrum framework will probably help the team yield results, but they may experience some friction and waste. If there are only 1 or 2 “yes” answers, the Scrum framework will be more overhead than helpful.

It’s Not About Effort

None of my questions include any culture, behavior, or type-of-industry questions. I don’t really care about their existing management structure, level of trust, technical debt, if they have remote team members, or whether they are a government agency or financial institution. Those attributes relate more to the level of effort required for Scrum adoption to become successful. The five questions are more about the nature of the work and less about the current level of dysfunction the team or organization is experiencing (or causing).

Putting my consultant hat back on, the five questions tell me whether I should proceed with a Scrum training/coaching engagement or “fire the customer” before I get started. Follow-up questions about the culture, current behavior, and environment will tell me how much effort will be required. Incidentally, those are not simple yes/no questions, but an understanding that evolves over multiple in-person conversations and assessments.

Conclusion

My five questions are not weighted equally. For example, if someone answers “yes” to four questions, but answered “no” to having at least three technical people to do the work, then it may be a non-starter. Since opinions will vary on the weighting of these questions, I recommend using them purely as a guideline for your own questions or assessment.


What did you think about this post?

Comments (4)


David V. Corbin
02:41 pm October 31, 2017

An excellent frame of reference for starting an evaluation of the applicability of Scrum for a given organization. I would add that even for groups with "low scores" learning exactly what Scrum is [and is not] by spending some time reviewing the Scrum Guide is almost certain to provide value - even if Scrum is not adopted.


David Nielson
04:50 am November 1, 2017

Love it. I typically add “Is the work creative, something we’ve never done before, or are multiple solutions possible?” Since Scrum is basically a heavy duty incremental and iterative feedback engine, it’s not well suited to non-creative, repetitive task, easily sequences and estimated work - like a roll out. Too much overhead when constant feedback isn’t helpful.


Charles Bradley, Scrum Coach
04:42 pm November 2, 2017

I think #5 let's people off too easy. Many software devs, esp ones supporting prod systems, claim their work is unplannable. (Some of it is, of course, but not much)

I would say something more like:
"Do you have at least enough work queued up for the product such that you could plan out the next 2-3 days of work?
(remember, scrum guide only requires work be decomposed for first days (at least 2) )

Also, if your team does prod support like work, check out this way of using Scrum for that:
http://ScrumCrazy.com/bugs


Michael Chacon
03:22 pm November 16, 2017

Excellent! Very practical and avoids the all too common religiosity around Agile... Also clearly communicates what is required to get value from the framework. Pass it on...