A Twitter exchange yesterday and today has given me today’s topic. I love it when not having a plan comes together. (Hm. Societal impact is similar … see below.)
The Twitter exchange was with Ryan RIpley, with whom I am nearly in agreement. I’m sure you can find the thread if you need to, and I’ll be reviewing my side of it right here.
I want to emphasize that Ryan started the thread with a good idea: Scrum AND XP, not OR.
I am in violent agreement with this idea. If you follow my work you can guess why: I think that Agile cannot prevail without the Increment (working software). And I also think that XP is a great way to create the Increment and keep it alive.
So I agree with Ryan. I really do.
And … I began by asking “But once you have XP, why do you need Scrum?” That wasn’t just snark, although I’d be a liar if I said there were no snarks present when I wrote that. There are two main differences between XP and Scrum:
- Scrum requires a ScrumMaster role;
- Scrum makes review/retrospective explicit.
If I were condemned to do a software product with a team ever again, we’d be doing a thing that looked like XP plus product and process reflection on a regular cycle. In essence, I’d add “Sprint Review” and “Sprint Retrospective” to XP.
(I might start with a regular build-review cycle like a Scrum Sprint or XP Iteration, but I think we’d move quickly to a more continuous flow of development, using very small stories, and probably single-piece flow, unless the team was larger. I would keep the regular review cycle, just because a meeting every Friday is easier to live with than random meetings on random days.)
What about the ScrumMaster? Well, if I weren’t doing it myself, I’d like the team to have an XP Coach, with much the same responsibility as an SM, but with a deep understanding of XP technical practices.
Why? Because it’s software development, that’s why. ScrumMasters are rarely technical and if there’s one that actually has an XP heritage, I’ve not met them. They are more commonly drawn from non-technical roles. As such, they almost certainly don’t grok software.
The XP Coach knows things. They understand the Hill Rice ‘n’ Garlic rule: Take many more much smaller steps.
They’d go around saying things like “This step is too big”, and “We need more steps up in this biz”, and, of course, the ever-popular “We need a test for this”.
I’ve never heard a ScrumMaster saying any of those things. Maybe they do it where I’ve never been. I hope they do, but seriously, software is not in their wheelhouse.
A would-be agile software development effort needs agile software development training and coaching. ScrumMaster role does not include that. They don’t have it to give, even if they vaguely understand that it’s needed.
Now, before some highly technical ScrumMaster jumps me and tells me that they understand these matters, fine, yes, congratulations, I believe you. I’d love to chat about how you do it. My hat is off to you.
And I think you are an exception among ScrumMasters. Technical competence is simply not in the ScrumMaster curriculum to the level needed to do XP. You’re a star, a bright light among humans, and a rarity.
Where was I? Oh, right, this is supposed to be a rant. The above was just warmup.
Ryan, and all the Scrum people I know–and I know a ton of them. Ten tons. Perhaps 50 tons. I don’t know, we don’t usually weigh them. Everyone I know in Scrum is sincere, well educated in Scrum, and does their very utmost to deliver good training, good coaching, good guidance, to their customers.
These are sincere, hard-working individuals, and I think their work does help. Yes, they get paid to do it, and paid well, but there is no shame in being compensated well for what one does.
The people in the Scrum Industrial Complex are good people, working hard to help folx who build products.
It’s just that–at least for software–they’re doing it wrong (in my very sincere and quite strong view).
This is not because of ill will. It is because of ignorance, lack of understanding of what it really takes to build software in an agile fashion. In a word: the Increment. Scrum does call for the Increment, but it’s the rare Scrum expert who really gets how important it is, much less how to actually get it. They have a few slides in their pack about TDD and Refactoring, and most of them probably hope there will be no questions on the subject.
I have been trying to get this across to the Scrum Gods for years, surely more than a decade. They do, of course, offer various kinds of technical certifications and courses. There is incredibly low uptake on those materials. I believe this is because it’s much more costly to train a team of developers to become actually somewhat competent than it is to have a single ScrumMaster pass a quiz with a higher than random score.
In short, the certification and training approach to agile technical skills has failed in the marketplace. They’re still offered but have no wind in their sails, just a few trainers and consultants who keep trying.
So the Scrum Industrial Complex did what anyone with a filing product would do: they gave up. They threw up their hands and said “No one wants technical certification and training, nothing to be done about it.”
As a business decision, I’m OK with that, despite that I know things that could be done about it. No business should have to offer a product that it doesn’t want to offer.
But the Scrum Industrial Complex … well, in my mind … the Scrum Industrial Complex should be more than a business, it should be a humanitarian effort to bring effectiveness in software development to the world. That would improve the world in general, because your [DELETED] lightbulb has software in it now FFS, and when your lightbulb crashes it’s a pain to reboot, and it would improve the lives of everyone working in software development, because it would smooth the path to success.
I hate the fact that they’ve not picked up the ball on this, because they have the money and clout to do it. What they do not have is the wisdom and the will.
Ryan–remember, I agree with him–gets it. He sees the need for XP in Scrum, i.e. technical practice in software Scrum. But the people who run the Scrum Industrial Complex just look away.
They have the right to do that, but it is not right to do that.
So those of us who care, go another way. My colleagues and I are mostly independent. A very few companies understand the issues and work them.
Scrum isn’t helping us. It could, but by and large, it isn’t.
I’m grateful for the few people, such as Ryan, who get it and try to help. And, again, I know that everyone is trying to help, except for those few in power who throw up their hands and say “nothing to be done about it”.
It’s true in Scrum, and it’s true in society. There is something to be done about it. I guess it’s going to come down to individuals. The people we vote for, and the people who run our companies, well … they don’t seem to be here to help us, do they?
We can do this. We must try.
P.S. Surely societal ills are more important than a little Dark Scrum, unless you see a pattern of exploitation, a pattern of not caring about the underlings. It’s surely more important for all of us to work to heal society’s deeper ills. But, if you choose to work in software, that’s OK too. Healing an illness anywhere is a good thing to do.
We must try.