Scrum Is Not (Anymore) Software Specific Process Framework

Lately I’ve seen tweets (like above) about Scrum and how it appears to lack software development specific ingredients. Which I do agree - at least to some degree. It depends on what is Scrum.

Few words about origins of Scrum

Scrum (Jeff Sutherland & Ken Schwaber in other words) was influenced a lot by The New New Product Development Game article by Hirotaka Takeuchi & Ikujiro Nonaka in 1986. I don’t want to dive into the history of Scrum in this post, but if you’re interested, you might want to check out The History of Scrum and Lessons Learned from the First Scrum.

I want to mention though, that first experiences with Scrum involved utilizing Extreme Programming (XP) paradigm. And also ideas from James Coplien related to daily Scrum meetings.

So that was roughly 20 years ago. And it’s hard to say if the way that Scrum is applied in companies these days, reflects on what Jeff Sutherland had on his mind early 90’s. Because if you check Scrum Guide - the word ‘software’ is not mentioned even once. Which is one indication, that Scrum is these days higher level process framework that is by no means tied to software development.

Scrum requires context specific software development patterns

I’ve personally seen it mentioned many times that Scrum requires XP, in order to be truly useful software development process approach. And in a sense I can agree with that. Except that it doesn’t have to be necessarily XP. Whatever patterns suit your context and help you in meeting stakeholders needs most effective way. If XP is only thing you can come up with, then that’s perfectly fine.

There’s an effort though also from Scrum Pattern Community for coming up with patterns that amplify the current superficial process framework of Scrum toward something that can truly make software development teams hyperproductive.

I guess in the end any tool can be misapplied. It’s the same with Scrum. You need to first be aware of what you’re doing at the moment. Then one by one question the purpose of roles, workflow and artifacts of Scrum. By doing that you can better understand their usefulness to your context. After that you can think what else you need to make it a software development process framework that suits your context.

But how many goes through that instead of blindly following the default approach? And is that then the fault of Scrum or people trying to blindly apply it without considering modifying it to their unique context?