Should we leave Scrum behind?
Modern Agile and Scrum: is Scrum unfit for purpose?
We do Scrum and… — episode 1
It’s no so long ago that I first heard about Modern Agile. I got intrigued by the idea and I decided to dive into it.
A lot of things are spot-on. Things that I posted and twittered about before, without knowing that Modern Agile existed. And I also found out that people that I interacted with or followed used the hashtag #modernagile occasionally or even frequently, but that I never noticed that.
So what is Modern Agile?
Modern Agile is introduced by Joshua Kerievsky. He says:
Modern agile methods are defined by four guiding principles:
“It is based on modern approaches sharing a focus on producing exceptional outcomes and growing an outstanding culture. It transcends software development and the principles of the Agile Manifesto of 2001.”
I am enthusiastic about Modern Agile and the Modern Agile principles. I see it as important concepts to be able to take the next step in this competitive world. This is why I am looking at how I can use Modern Agile within my own working environment which is based on Scrum.
But…. does Scrum fit into this?
Joshua Kerievsky is very clear about this in his Agile 2016 Keynote speech about Modern Agile. Scrum is outdated. It is no longer fit for purpose. People are bending over backward to deliver the items that were promised during sprint planning and items tend to go from one sprint to the next and so on. Or people do bad things just to get ‘Done’. It’s like mini-waterfall. I have this picture of a record player in my mind. Used to be great, but we have other ways now.
Is this really the case?
I personally think Scrum has evolved and that it fits within Modern Agile. But let’s spin the Modern Agile wheel and see:
Is safety a prerequisite within Scrum? Here are some vital passages from the Scrum Guide on this:
- It starts with the Scrum values of commitment, courage, focus, openness and respect. These are embodied and lived by the Scrum Team.
- “Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.”
- “For the Product Owner to succeed, the entire organization must respect his or her decisions.”
- “No one can force the Development Team to work from a different set of requirements.”
Development Teams have the following characteristics:
- “Development teams are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.”
- “The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.”
- “If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”
So I’d say that safety is covered within Scrum!
Deliver value continuously is about two things for me:
- Focus on value, not on number of stories done or story-points done
- Focus on continuous deployment and make the concept of sprints obsolete
Let’s start with the definition of Scrum: “a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” This statement is clearly about delivering value.
The Product Owner is responsible for maximizing value. Again the word value. Joshua Kerievsky also mentions an issue with the Product Owner role, but I want to dive into this when discussing ‘Make people awesome’.
Many companies are looking at story points, velocity and other metrics. What about that? Well, the concept of story, story points, burn down charts and velocity are not mentioned in the Scrum Guide. Scrum has evolved here and I’d say that is with good reason.
Continuous Deployment is the other topic. I think it is key to move to automated testing and continuous deployment. If you don’t do this you can’t keep up, let alone be a front-runner in your field. It’s key for survival.
There are two topics within Scrum that appear to be conflicting with the idea of continuous deployment: The concept of a fixed sprint length and the sprint goal.
The fixed sprint can be considered as a project according to the Scrum Guide, to accomplish something which is translated into the sprint goal. On the other hand: Scrum allows changes, as long as it doesn’t endanger the sprint goal.
My team is working with the practice that we plan every two weeks, but that we tackle the items one by one. This allows us to have the full focus of the team on that one item. We are still in the proces of improving our deployment process, but as soon as we have continuous deployment fully in place we will deploy an item whenever it is ready for that, so continuously.
The other concept is the sprint goal. I think I see how the sprint goal can be seen a something rigid. Because what happens with the sprint goal, or with the sprint for that matter, when the feedback on the first item of the sprint would push us another way, resulting in picking up other items than initially planned? It might be that my understanding of the sprint goal is insufficient, but I indeed see it as an issue. Either you’d have to define a very generic sprint goal or the sprint goal would become obsolete resulting in cancelling the sprint. The latter sounds silly and unnecessarily disturbing , the first sounds like making a sprint goal for the sake of making a sprint goal.
So I believe Scrum is suitable for ‘Deliver Value Continuously’, but with some issues on the sprint goal.
So, does Scrum allow experimenting and rapid learning?
The Scrum Guide says the following: “Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known” and “three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.”
So I’d say Scrum is indeed about experimenting and learning. But what about rapidly?
If you are restricting yourself to two or four week sprints and adding value only at the end of the sprint you are not delivering and learning rapidly. At least not in 2018. We now have other ideas about rapid. I see multiple ways to improve on this within Scrum:
- Reduce the sprint length to one week or even a number of days.
- Deliver (experiment) and get feedback (learn) continuously.
- Make your items smaller, allowing you to get feedback earlier.
I’d argue that you can do all of this within Scrum.
Many see the roles, events and artifacts of Scrum as rigid themselves. I’d argue that it is good to have these in place to create clarity, to have everyone at the same page on what to expect.
How about ‘Make people awesome’?
This is a broad topic. It’s about the entire ecosystem, which includes users, coworkers, managers… everyone should feel awesome. Making awesome products, working in an awesome environment.
Joshua Kerievsky says that the handover to the Product Owner is an outdated concept. The users have to tell you what’s done, not the Product Owner. The users determine if the feature works for them. I’d argue that this can be achieved with Scrum. Simply add it to the Definition of Done!
Scrum has the Sprint Review, with -among others- the following elements:
- Attendees include the Scrum Team and key stakeholders invited by the Product Owner. So let’s have the users attend the Sprint Review. Make them have a say about the items as well. Make them a part of the journey to be awesome
- The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning. With users attending the review this can be pretty effective.
So…
I argue that Scrum
- makes safety a pre-requisite
- allows to deliver value continuously
- allows experimenting and rapid learning
- can help to make people feel awesome
I even want to take it a step further: you can use the Modern Agile principles to verify if Scrum is properly implemented with the right intentions. Without a safe environment, without allowing experimenting and rapid learning, without continuous delivery of value and without people feeling awesome you have issues.
Scrum misuse
Joshua Kerievsky mentions a lot of issues with Scrum, during his keynote speech:
- Scrummerfall: working Waterfall with a Scrum package
- Misuse of story points and velocity
- Ineffective stand-ups
- Steering on stories delivered instead of on value delivered
Although I acknowledge that many teams are in this situation, I do consider these as bad practices. Scrum teams should steer away from these. That’s why they are not discussed in detail in this write-up.
So…
Let me know what you think! Do you agree or do you see it differently? It’s not that I want to hold on to Scrum at all costs, but I do not see why Scrum would be unfit for Modern Agile… Am I a lost case now? j/k
All Modern Agile pictures in this post are from the site modernagile.org
Direct quotes from the Scrum Guide and modernagile.org are between brackets.
Did you like the article? Then it would be awesome if you’d clap 👏🏻
My twitter profile is https://twitter.com/WJAgeling
