Nobody: Should my team adopt Scrum?
Me: I don't know, what's your context? What are you trying to achieve? What do you want to improve?
It seems very difficult to talk about Scrum these days. Many folks see it as either the one true path to successful product development, or else a pyramid scheme for snake-oil salescrtitters. That's a shame, as Scrum still has a lot to offer.
Scrum seems to excel at three things: two specifics and one more general point.
Specifically, Scrum is great at unwedging a team that's stuck, either with what we used to call “analysis paralysis” or maybe “yak shaving”, or “bike shedding”, or whatever it may be.
Specifically, Scrum is also really good at bringing under control a team that is running around in a state of chaos, or maybe frantically fire–fighting, and never quite manages to get anything done.
Generally, Scrum is also really good at breaking the cycle of escalating “watermelon” status reports (a watermelon is green when viewed from the outside, but red when viewed on the inside) which can occur for the above and other reasons, and which leads to no one believing anything anyone says about the work, which is both demoralising and makes it impossible for anyone to effectively help.
If you don’t have those problems, Scrum might not be the way to achieve significant improvements in performance. There used to be this line that Scrum is the “secret sauce” for “hyper–performing” teams. I don't think that’s right. I think that Scrum teams go at about the pace a well–functioning team should go. When Scrum was first described, in 1995, well–functioning teams going about as fast as they should were a bit of a rarity in mainstream corporate software development. The baseline was very low, so going from there to “can get anything done” really was a huge improvement. But that was then.
One weird trick: to see any of the effects of Scrum, you have to do it. If you don’t do it, you will not see the effects.
This is not to say that if you don't use Scrum things will necessarily go badly for you (one common misreading of this sentiment), there are others ways to be successful at developing software–intensive products. And neither is it to say that if you do use Scrum things will necessarily go well for you (one common bit of snake–oilery). In many ways, the best you can and should hope for from Scrum is that immediately after adopting it, you will correctly understand the status of your development activities, which might be quite bad, and you will have some pointers for things to try to make it more as you might wish it to be, which might be not a lot. But you will know, and folks should believe you. This is non–trivial and not to be sniffed at. It is at least a great place from which to start improvement.
But, to see the effects of Scrum you have to do Scrum. Saying that you want to do Scrum will not have these effects. Saying that you do Scrum will not have these effects. Saying that you do Scrum, and hiring a ScrumMaster, and finding excuses not to do what they recommend will, in particular, not have these effects.
It‘s OK to decide that Scrum isn't right for you. It‘s OK not to do Scrum. Doing Scrum is not in and of itself a valuable thing. But, if you do want to do Scrum, do it. As they say, say what you do, do what you say. If you allow what you do to diverge from what you say you do, then you are creating confusion and may be sabotaging yourself. Cut that out.