Why Don’t We Like Scrum Anymore?
When I’ve entered in this mad industry, Scrum was a thing. Nowdays seems that the dream has come to an end for everyone; Disillusion started sneaking inside startups and enterprises. Oppression for developers, confusion for the business, the medicine that became even worse than the desease that used to heal, that’s how many Scrum teams started to crumble
In this article we’ll go through common criticisms and disbeliefs around Scrum, using a fictional back-and-forth in which I’ll try to address main issues I’ve found during my experiences and research. At the bottom of the article, the reader can find some references that inspired me and gave me some food for thoughts
DISCLAIMER #1: As of today, when we talk about “Scrum” we are actually talking about a blend of the original definition of Scrum methdology and eXtreme Programming: for example, it’s common belief that Scrum involves usage of User Stories and story points for estimation although these concepts are part of XP practices. This is just one of the implementations of Scrum, but for the sake of simplicity we will assume that this is the way we intended to apply Scrum
DISCLAIMER #2: It’s frequent to assume that Scrum IS Agile or that Agile is achievable through the usage of Scrum. Nothing more wrong than this: Agile is a mindset which drives a company towards its goals while Scrum is a project management framework (which usually fits with software projects) inspired by the same principles as Agile. turns out that Agility is rather a pre-requisite that helps creating successful Scrum teams.
Everything as an MVP
I really like the idea of creating incremental changes and continuous evaluation of our priorities, but that’s not how it works in my company: stakeholders expect MVPs within certain deadlines to make evaluations and respect business plans
Let’s recall that MVP stands for Minimum Viable Product. Although sometimes the term is not used according to the initial intended meaning for MVP, in practice we do expect that we are developing a “product” that is
- Viable: it’s possible to create a working version with given resources (time-people-money)
- Minimum: contains only characteristics that add enough business value to accomplish MVP goals
It may seem that the definition of an MVP goes against Scrum way of working, but it’s not: every Scrum sprint can end with an MVP, but in some contexts MVPs become so little “minimum” and “viable” to transform themselves into weird hybrid monsters halfway between Agile and waterfall
As an engineer, too much time I’ve had conversations that were like
<<Hey Carmine! So, you’ve studied requirements, you know the code and the people, how long do you think you guys will take to implement all these stuff?>>
<<Well, to be honest I’ve found a lot of corner cases, some of them are not addressed in the reqs, moreover we will need some refactoring and accurate regression tests. I think this project is quite large and it will take 6–10 weeks, if nobody gets sick>>
<<Oh, that’s a very bad news man! Directors wanted to see this by the end of the month because they want to unveil the new feature in the FooBarEvent, you know that all the world is gonna watch us there>>
The precise idea behind a Scrum working model is to take this conversation as a starting point, and apply it to the MVP in order to (re)define a scope. We cannot increase the resources and it’s very important for the company success (yeah, the company that pays team members and promote them) to not take more time than the expected. So the only thing left to do is to discuss on the scope
But how to do it? estimations are always guesses, there is always the risk of neglecting important cases or just end up writing code for the most critical feature just the day before the demo (one day I will tell about how I ended up implementing a feature in a car, driving on the Bologna-Milan highway, but that’s another story). Application of Scrum methodologies already overcomes these issues. The MoSCoW approach can be used to assess the impact of the planned activities over the final (initial, indeed) proposition of the product. This, though, needs to be carefully shaped with a PM/PO who has enough autonomy and buy-in to take informed decisions along with the team. Proxy Product Owners are an anti-pattern found in many organizations where the Scrum way is not fully understood or accepted
Deliverables are not Releasables
Let’s be honest: in an ideal world would be very nice to work on small user stories, let our customers see our platform improve day by day, but most of times the way we split features into user stories just doesn’t make sense! what’s the point of implementing a “checkout” button in the e-commerce section without the “clear cart” button?
There is a common misconception about user stories and sprints, and it starts from the idea that, at the end of the sprint, we have to release some value while user stories should represent a minimum increment of value. So you may wonder about “what it’s really valuable? do we only care about the marginal value we introduce with a story? or should there be some interaction between factors?”
Not the first nor the latter. We can simplify the problem just separating the concept of delivery from the concept of release. Let’s provide some definitions:
- Deliverable: An activity produces a deliverable when meets the expectations set up through a “definition of done”. Delivery of the feature is a tactical concern and tech team is responsible for ensuring it. For example, we could consider a story as the minimum deliverable feature
- Releasable: A feature is releasable when it provides enough increment to product value that the customer is ready to start using it. Thus, release of a feature is a strategic concern. For example, we could consider an epic as the minimum releasable activity
So it’s clear how, in the Product Backlog, we are creating a two-layered planning which has the goal to define a roadmap that encompasses both tactical and strategic standopoints. Turns out that we cannot correctly apply this mechanism without the right toolings that ensure an effective separation between delivery and release. Tech industry practies are fundamental in the waypath: Feature Toggling systems, DevOps culture, SRE methodologies and all related and alternatives approaches (as well as release strategies, experiments) are the tooling that you will use to take your recently completed item from the backlog to production hand-by-hand
Why this is Overwhelming?
Oh, I like Scrum, I understand the benefit it’s bringing to us, but we have the planning meeting, then the demo…and what about the infinite grooming sessions? without forgetting the endless daily standup, then the retro..How much time is left to work? why can’t I just assign a task on the fly?
Some people took Scrum as a religion, some people took whatever as a religion, perhaps we just need to believe in something to turn off our brain and be confident that our behaviour is the best and will take us to paradise.
But, if Scrum is not a religion and we won’t follow the Bible, what Scrum really is? How to make sure that your idea of Scrum does what Scrum supposes to do while addresses the problem stated in the quote?
First and foremost: the problem is not that you have too many meetings or that they take too long, the problem is that you are not improving your process. Scrum masters are made for this: they should not be project managers “in disguise”, but people whose goal is just to analyze problems in the day to day job and propose remediations, observing some sort of team level OKRs
The planning meeting takes two hours because people discuss too much about stories descriptions? extend the grooming session, set up 1:1 calls with POs to pre-refine backlog items, kill the dev who talks too much about code during the discussion, do whatever you need but keep in mind that the idea behind most of the Agile-related methodologies is that those methologies are not a recipe for the success but a forma mentis that needs to be trained and refined to meet the necessary goals…which are
- Eliminate unclarity: everyone knows exactly what it’s expected and they know so much about it that the solution is trivial
- Provide visibility: everyone knows everything about everything in the team and if a guy has a problem, another guy has the solution for it
- Work for a goal: The final result has to be tangible and it’s clear what are the motivations that drive the team towards it. This is true for business side with respect of technical activities as well
- Track the progress: Every day the team knows exactly what else is needed to reach the goal and is able to predict if the goal can be reached. Everyone should have a feeling about whether the overall performance of the team are improving or not
- Enable Feedbacks: every action should lead to an outcome, people have room and confidence to provide a transparent feedback and use it to improve the product and the process
- Self Organization: the team has all the tools needed and provided from the outside in order to reach the goal, they are empowered to take decisions without interference
As you see, Scrum is not about the meetings but the purpose of these. Shape it in the most preferred team’s way to reach these goals
Efficiency or Effectivness?
From when I’ve started working with Scrum, the only thing that matters is to get the job done. All the team is focused on delivering stories at the end of the sprint, while tech debt increases and we have never time to really do something innovative
You see here, Scrum is a methodology which should adhere to Agile principles. It’s not useful here to recall what Agile is and what principles it fosters: the ugly, old (but gold) Agile Manifesto website is enough for us. One of the principles that I like more, and I’ve found totally fitting with the Scrum process is
Individuals and interactions over processes and tools
It’s all about that: the success of a project is the result of an equilibrium between business needs, technical concerns and the collaboration that both ends have to define a roadmap. Only great professionals will create a great Scrum team, that’s the sad thruth and I suppose there is nothing else we can do to fix this*: it’s time to admit that every solution that promises to make a product look better than the people who have built it, is a false promise
So how we can leverage this epiphany? At te core there’s negotiation, trust and mutual understanding. Business needs are not more important than technical concerns, they have just a faster payback period. Technical excellence, in turn, is a consequence of the business needs, since solutions are good only when they solve someone’s problems.
Scrum teams should have an high velocity, not an high speed. They have to know when to sweep under the carpet and when to face the problem. Two-weeks sprints are not always the right size for having a feature done in the proper way. There should always be some room left for improvements, like solving tech debts, making experiments. All these activities have a part in the process and provide a value increment for stakeholders: because the team itself is a stakeholder, am I wrong? Summing up, the fastest path to a failure is to worship efficiency, fearing the effectiveness. Turning your process into “eating tickets” without a purpose-driven mindset, and no means to evaluate the future impact of today’s choices will kill every business regardless on what project management framework it will adopt
*except for training people or making agile skills assessment as part of the hiring process ;)
Conclusions
At the end, my personal take is that nobody really dislikes Scrum or criticizes against the purpose of Agile. There are so many deviations that ended up wrapping the old way of working into new fancy empty boxes, hoping to get problems solved.This made drop the trust on those things. What I’ve learned during the last years working in/for Scrum teams is not only that Scrum alone is not a magic formula, but the key of the success is to abandon the idea that a magic formula exists. Agile, at the end, was made to embrace the complexity of the new world we have built, not to hide it behind reassuring recipes
