My response to the talk “Modern Alternatives to Scrum”
Or is it “Modern Alternatives to XP, Dark Scrum, Zombie Scrum and Scrumbut”?
Joshua Kerievsky is the creator of Modern Agile. I like the concept of Modern Agile and I wrote a lot about it. It inspires me.
I do have my reservations though. These stem from an earlier talk by Joshua Kerievsky. I liked 80% of the talk, but I had issues with how Joshua discussed Scrum. My stance was and is that Scrum and Modern Agile can be a great fit.
Then I saw Joshua Kerievsky’s talk “Modern Alternatives to Scrum”. And again he stated that Scrum is old-fashioned. That we should move on. Below is the link to this talk.
I will explain where the talk misses the mark. Here follows a point by point response to Joshua’s claims.
Detailed response
I invite you to watch the talk. In my response below I specify exactly where you can find the remarks to which I respond.
At 0'15" Joshua Kerievsky starts with the question how many attendees use Scrum and then states “I’m not trying to make you uncomfortable.” Which of course is a sign of things to come. And it’s a clever way to come across as the good cop.
At 0'43" he states: “I in fact used Scrum. I didn’t call it Scrum, we called it Extreme Programming.”
Scrum isn’t the same as Extreme Programming. Sure there was a lot of cross-pollination. But Scrum has always been a framework where XP always has been more as it includes many set practices. XP talks about Pair Programming, practices to design, practices to test. There are far more rules to XP than to Scrum.
Joshua is leading up to a Straw Man argument. He takes Scrum as a starting point, then pushes the listener away from it: “I in fact used Scrum. I didn’t call it Scrum, we called it Extreme Programming.” So he didn’t Scrum, but in fact did XP. Hence this talk is largely discussing XP, not Scrum.
At 1'15" he states that he used Scrum for about eight years. This means that he stopped using Scrum somewhere around 2007. This is three years before the first Scrum Guide was published. And it is after the first Scrum book and around the time of Mike Cohn’s strong involvement. This is very interesting to know. Joshua is not discussing modern day Scrum, he is discussing a historic version of Scrum. When he doesn’t discuss XP that is.
The notion that Joshua states he did XP and the fact that he stopped around 2007 explains a lot of what he says during the talk. Joshua stopped with Scrum when he found some problems with the techniques. This is interesting, because Scrum is a set of artifacts, roles and events. Scrum doesn’t mention techniques.
At 1'50" he states he is not bashing Scrum. He says it’s the same as bashing a phone from the nineties, which is stupid. He states that we have outgrown some early ideas of nineties Agile. Then he elaborates why we should inspect and adapt. I believe he is right. I think that Ken Schwaber and Jeff Sutherland also saw this. Hence they have adapted Scrum several times. At the heart Scrum is still the same as in the nineties, but it is adapted to fit our current needs.
At 3'44" Joshua is talking about trying to get the perfect velocity for the system so that you can get the exact amount of work done as predicted. Within Scrum this is an anti-pattern. Why? Well you work in a complex environment. If you aren’t in a complex environment you shouldn’t do Scrum. Scrum is founded on empiricism: transparency — inspection — adaptation.
And what’s more: Scrum works with Sprint Goals. The items you pick to plan the Sprint should help meet the Sprint Goal. The objective is NOT to finish the items. The objective is to meet the Sprint Goal. Hence Joshua comes with something he sees as wrong about Scrum while it’s not about Scrum. It is about wrong implementation of Scrum.
05'05" Joshua says “For a lot of people Agile equals Scrum”. I want to bring it a bit further: for a lot of people Agile equals zombie Scrum/Dark Scrum/Scrumbut: having the roles, artifact and events in place without understanding WHY they are there.
A lot of people take the recipe, cook something completely different, then wonder why they don’t get superpowers like Asterix & Obelix — Max Heiliger
05'40" is where Joshua introduces the Agile Happy Meal: “The certified ability to sprint, estimate with story points and do stand-up meetings. It’s good that he calls it the AGILE Happy Meal (although it’s from McScrumm’s). Because it’s not Scrum. Story points are not Scrum: you are free to estimate in whatever way you want. Scrum doesn’t know stand up meetings. They are called Daily Scrums. And oh…. Joshua said he’s not here to make you uncomfortable, remember?
06'10" Joshua now comes with the “Agile DUI”. DUI stands for “Definitely Unshippable Increment”. He then proceeds to bring forward two other anti-patterns:
- teams that are incapable of making their items small enough.
- teams that focus on items finished instead of meeting the Sprint Goal.
Stories (again the word stories — not in Scrum) are being pushed from Sprint to Sprint. If this is a standard routine for Scrum Teams, then they are definitely not getting what Scrum is about. Joshua recognises this. People don’t adapt their way of working after introducing Scrum. That’s indeed a common issue: Zombie Scrum/Scrumbut/Dark Scrum. Clearly this is a major issue in the Scrum domain. In fact, it’s a reason why Serious Scrum exists: to tackle these bad practices.
08'10" Joshua talks about taking bad decisions to “make the Sprint”. This is another anti-pattern. The Scrum Guide is very clear that items should meet your own Definition of Done. You should not cut corners.
08'50" Joshua states that many think that the solution to “not making the Sprint” is getting better at estimating. Also this is an anti-pattern as these people should come to realise what Scrum (and Agile) actually is about. This includes accepting that you don’t finish an item and learn from this. You should inspect and adapt. As an example of inspect and adapt: in this case solutions could be to plan less and have smaller items.
09'45" Joshua discusses the endless Product Backlog. Now I’d argue that a super big backlog is not automatically a problem in itself (although it mostly is). But Joshua also states that people would groom (yikes, please call it refinement like it is called in the Scrum Guide) the entire backlog. Now THIS IS another anti-pattern. A good practice is to refine your items just-in time. Only those you wish to have ready for the Sprint to come. The rest of the backlog remains high-level, which is perfectly fine.
Also the ordering of the backlog is magnified as a major issue. Yes, it will be an issue if you wish to have the complete gigantic backlog perfectly ordered all the time (even the items that are not in sight to be picked up). But this is a stupid idea. I smells like Big Design Upfront and it is NOT what Scrum is about.
10'35" Joshua touches upon the Product Owner role. According to him making one person responsible for what to build is not a good idea. Instead you should collaborate to decide on what to do. Well, according to the Scrum Guide the Development Team is also allowed to update the Product Backlog. And during Sprint Review stakeholders work together to discuss what to do next. There’s plenty of room within Scrum to collaborate on what to do. Indeed Scrum says that the Product Owner is responsible for maximising the value of the product. How this is done however, varies greatly.
This is the first time that Joshua actually criticises something involving Scrum itself. And while I understand his point that a Product Owner could veto something that could have been great I also believe that the Scrum Team should be protected from stakeholders pointing them into all kinds of directions. I do agree that a Product Owner that only listens to his/her own ideas is doing it wrong.
13'25" Joshua states that there’s no Agile authority and then comes with the Merriam-Webster definition. I beg to differ. In my humble opinion the Agile Manifesto is the authority.
16'30" Joshua talks about dropping Sprints. In 2007 they found it better to work on something, ship it, then work on the next and ship it. This is done regardless of the time it takes. He puts it as Flowing instead of Sprinting. Guess what: Scrum allows you to ship as often as you wish during a Sprint. The concept of Sprint doesn’t limit you to build and ship faster.
Apparently this insight liberated Joshua and his team because now they didn’t need to discuss what would fit in a Sprint and they could stop with story point estimating. It appears that they could finally drop the wrong way of doing Scrum.
18'15" Joshua comes with alternatives for the Product Backlog. He starts with Chartering. He explains a practice that can easily be used within the Scrum framework. Chartering is a great way to come from vision to a sort of backlog (which doesn’t have to be sequential in Scrum!). This is the good thing about Scrum: you can experiment to determine what tools and techniques work for you.
19'45" Joshua introduces Release Planning. I am hesitant to embrace this idea. It has a Waterfally smell. I say this because how can you possible plan more than a couple of weeks ahead in a complex environment?
Joshua then mentions User Story Mapping, which is an excellent technique to maintain a Product Backlog (indeed non-sequential!). But also Story Mapping — though a great idea, as Scrum is— can be mis-applied by the same people that mis-apply Scrum.
The techniques that Joshua proposes here won’t convince the people that wish to fit the old into a new process without wanting to change the old ideas.
20'45" Joshua mentions the Scrum Team. He has issues with the word Developer and states that many more roles exist in a modern Agile team, because a team should be cross-functional. This is exactly what the Scrum Guide says. It’s in the Scrum DNA. Scrum can be used in all kinds of domains.
The reason why the Scrum Guide doesn’t mention all kinds of possible roles is because the list of options is endless. On top of that: it allows you to make the environment a level playing field, getting rid of management layers. Granted, calling it Development Team and all roles “developer” can bring people to the wrong ideas.
22'15" Joshua speaks about evolutionary design. In no way does he explain why this can’t be applied within Scrum. Because it CAN be and it is often applied within Scrum environments.
He also discusses component teams here. Component Teams that can’t produce a “Done” increment are Scrum anti-patterns. Joshua basically explains why people fail with Scrum. Fixing this list of anti-patterns will make Scrum work for most teams.
26'15" Joshua mentions how important is to learn how to split stories. Indeed this is very important. There are all kinds of reasons to have small items. And the nice thing is: this works perfectly with Scrum. His shopping cart example is exactly describing how we do it at our company. And we use Scrum.
27'43" Joshua touches upon evolutionary planning and he talks about 2 month release plans. In a complex environment this is dangerous stuff. Many don’t understand the nature of Agile planning with forecasts instead of promises. People might mix it up with old-fashioned project planning. Also, suppose you do it well and you manage expectations well: this practice doesn’t rule out Scrum.
29'43" Joshua criticizes the rhythm of the Sprint Review. You should be able to demo anytime. Scrum doesn’t stop you from doing so. You can demo as often as you want. He also comes with an exotic example of why people can’t be at a certain place at a certain time (a colleague working in a remote area of Brasil). I however argue that with the rhythm of the Sprint Review comes predictability which allows stakeholders to plan their attendance. It raises transparency.
32'15" Joshua acknowledges that it is good to have regular retrospectives. So why isn’t this also good for the Sprint Review? He also argues that you should aim to retro anytime. Well, why not? Scrum doesn’t stop you to do this!
33'00" Joshua makes a point that Knowledge Transfer isn’t in the Scrum Guide. But why should it? It’s a framework, not a set of best practices. He then continues to discus Pair Programming and Mob Programming. Pair Programming has been used by Scrum Teams for many years. Mob Programming is used often too. Scrum works perfectly with those techniques.
35'45" Joshua stipulates that a ‘potentially shippable increment’ is outdated (Scrum Guide says releasable increment). We should do continuous deployments. Also this fits perfectly with Scrum. We do it at our company. But Scrum is a framework, used in many areas. There will be teams that will NOT be able to ship their increment, for all kinds of reasons. In other situations the Product Owner decides not to ship yet. Should these teams be excluded from Scrum? Why?
36'20" Joshua argues that we should always be bargaining for ideas, to go for the highest value with the lowest cost. Well this is what Scrum wants to achieve too. You wish to work on the most valuable item next. Joshua mentions Bargain Hunting, which is a great complementary practice to achieve this.
What also is interesting to note: when Joshua explains how the Bargain Hunting technique works with a real-life example he demonstrates how he is acting as the Product Owner by setting the boundaries of the proposals. This is interesting, because that role is apparently obsolete.
38'50" Joshua now proceeds to say that a Scrum Master only looks at Scrum, ignoring Kanban, Lean, Toyota Production System, Lean Startup and all kinds of best practices or experiments. This of course is as far from the truth as possible. A Scrum Master should find techniques to help the Development Team and the Product Owner to be more effective. This can include everything Joshua has mentioned in his talk.
On top of that Scrum communities are very active in bringing them forward too. One example is Scrum.org’s classes regarding Scrum and Kanban. Another is Scrum Alliance’s where they bring forward all kinds of practices that can be complementary with Scrum. I shouldn’t forget our own Serious Scrum as is a community of Scrum practitioners helping each other out with good practices.
40'15" Again Joshua discusses the issues with the Product Owner role with no real new insights.
42'05" Joshua claims that you shouldn’t focus on the product, but on the user, the customer. The Product Owner should make the users awesome, regardless of the product. This is a great notion. However at a certain point you need to create something. Let’s call that a product.
Faulty logic
The recurring theme of the talk is that Joshua addresses many Scrum anti-patterns and then blames Scrum. Joshua explains why here:
I don’t agree with this. I’d say that the following is the correct way to put it:
Blaming Scrum for the use of anti-patterns is like blaming the car for crashing after reckless driving.
I believe that if people don’t want to grasp a certain concept but still wish to use it that they are always bound to fail. I think this would also apply for Modern Agile:
Many organizations and teams don’t have what it takes to Scrum. Is Scrum unfit for them or are they unfit for Scrum? — Sjoerd Nijland
Thanks for the contribution Sjoerd Nijland, Paddy Corry, Daniel Westermayr, Gunnar R. Fischer, Scrum Rebel, Max Heiliger.
Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!
My twitter profile is https://twitter.com/WJAgeling
Do you want to share an article in Serious Scrum? Connect with us and make it happen!
Also, you’re all invited to the Serious Scrum Slack workspace. Come join the conversation!
