In recent years, Scrum has surged in popularity, becoming the go-to framework for agile development in many organizations. In fact, a staggering 87% of respondents report that their company utilizes Scrum or a Scrum-based framework at scale, such as LeSS, Nexus, or SAFe.
But here’s the catch: despite its widespread adoption, the number of truly successful teams and companies boasting remarkable results doesn’t quite match up to the hype surrounding Scrum. So, why is it that despite its ubiquity, many teams still struggle to achieve the promised benefits of Scrum?
Today, we’re diving deep into this question by dissecting some of the most common failed promises of Scrum and the real-world impacts they have on teams and organizations.
if you have been using Scrum for a while now and you feel it has not yet delivered on all the promises you heard when you started, you are not crazy, you are definitely not alone, and your story is actually a cautionary tale about the hype versus the reality of becoming more agile.
If you are the reader type, wanting a bit more detailed insight, please continue on the blog. If you want to hear me talking about it, albeit in an abridged version of this post… off you go to the video.
1 – Twice the Work in Half the Time?
Let me start with my usual dose of honesty. This first one, I’ll say personally I don’t enjoy at all, and I think it’s one of the worst marketing approaches ever, like old 1990’s sleazy sales slogans. Yet, that’s the name of the book Jeff Sutherland, the co-creator of Scrum wrote in 2014.
Scrum sold us on the dream of achieving twice the amount of work in half the time, or so says Jeff Sutherland in his book. But the reality? Instead of twice the work in half the time, what I see is 3 or 4 times more pressure to deliver and none of the support required to run scrum successfully. Here’s how it fails:
First off, this promise sets unrealistic expectations. Sure, in theory, it sounds amazing to deliver projects at lightning speed. But in practice, it puts immense pressure on teams to constantly churn out work without considering the quality or sustainability of what they’re producing. Chasing the end of the sprint becomes more important than the proper finishing of a piece of work.
And let’s not forget about the impact. When teams are pushed to work at an unsustainable pace, it leads to burnout, stress, and ultimately, a decrease in overall productivity. Instead of achieving more in less time, teams end up feeling overwhelmed and exhausted, which can result in missed deadlines and subpar work and frustration.
When an executive or manager reads this book, they may buy into the hype and implement Scrum without fully understanding the implications or providing the necessary underlying conditions for its success. And even if they wanted to offer the support… well, scrum doesn’t teach how. It doesn’t talk about you any of that! Scrum doesn’t tell executives how they must show up and support their teams. In fact, scrum doesn’t talk at all about what needs to change in the higher layers of the organization.
Plus… come on. What a clickbait-y title. The math doesn’t add up. Deliver more in less time is a function of a lot of efficiency and quality in the way you do your work. You can’t simply become more efficient with work. Once again, nothing that scrum itself, on its own, will ever teach you about.
What can you do to improve quality and speed?
If you’ve heard of value streams, attending to flow, controlling lead time, continuous integration, know that these are some of the tactics required to actually go after better speed and consistent quality.
My take though, whenever I hear about the need for speed, which I love and believe in, is to remain curious before any suggestion of improvement. The best is to first understand what is your current speed. Literally setting up tools to collect historical data so that you can understand if the need for speed is a hunch or a fact.
How?
By observing the gap between what the current state is versus what they want to achieve. Is the customer or other departments complaining about the speed? In what case in particular? Observe trends, seasonality and variability of speed and quality. Only then do something about it.
Then craft a plan. And for that plan to make sense, ask questions about what speed means, what is the best speed possible, the worst, what happens if the speed would never change, who would care, etc.
So, before I continue, let’s set realistic expectations: Scrum is not a magic solution, nor a shortcut to instant team greatness. Instead, I view it as a solid starting point for team agility. If you’re interested in making Scrum work for you in a practical way, I’ve got you covered.
My ebook can help you get started in just one afternoon, without breaking the bank $$ or dedicating days to training. Simple, pragmatic, accessible intellectually and financially… go check it out!
2 – The Illusion of Customer Happiness
Another one of Scrum’s big promises: happier customers. But let’s be realistic here. Have you actually seen a significant improvement in customer satisfaction as a result of solely implementing Scrum ? I’m not talking about team happiness. I mean the customer at the very end of the line. Scrum promises to deliver happier customers.
why is this a scrum failed promise?
The intention behind Scrum’s sprint reviews is to involve customers early and often, showcasing incremental product developments. However, in reality, this rarely happens. Instead, layers of managers and teams attend these reviews, while customers are often unavailable or uninterested in attending frequent meetings.
Then we have the Product Owner role, which is supposed to bridge the gap between the development team and the customer. Yet, we also expect every developer to be aware of and care about the customer’s needs, which kinda makes the Product Owner’s role redundant.
Scrum’s promise of faster delivery and more frequent releases via sprints is supposed to lead to happier customers. But this assumption falls short because more often than not, we might be speeding up our delivery process without actually developing speed as a capability, with quality suffering as a result.
The truth is many aspects of software development can’t fit neatly in sprints. Plus, generating value involves multiple stakeholders, not just the customer. Customers may think they know what they want, but they’re not always right. They might be unaware of or unconcerned about crucial aspects of the system that have a significant impact on the final product.
Moreover, gathering customer feedback requires techniques like iterating, surveying, and coding to discover trends and needs – none of which are addressed by Scrum. It’s easy to say that the customer will be pleased, but the reality is much more complex. It’s not about having a lot of feedback, but the right type and timely feedback.
What can you do to create more customer satisfaction?
In order to increase customer satisfaction, you must know what it means! Get to know everything about current levels of dissatisfaction. And a few ideas can come to mind.
First, on the broader aspects, have at least one good workshop where Design Thinking is used, so that the team and extended stakeholders can understand deeply what can please the customers. Many organizations have been doing that since 2018. Yet, it can’t be the only thing you do. Customers evolve in their needs and taste.
That’s why another great way is observing customers as they use the tool or product. Ethnography, surveys, embedded code and anything that can show what the customer thinks but also what they actually do.
And of course, speed and quality will be important. So, hopefully you already attacked the items of the first failed promised!
3 – The Myth of Productivity via Collaboration and Sprints
Next, we have the failed promise of productive work.
Scrum is really set that by operating in sprints and fostering collaboration, we’d achieve productive work. But what actually happens? I can tell you from my experience coaching teams: they say it often feels like they’re stuck in a perpetual cycle of back-to-back meetings, with the expectation that every second week, we can request yet another big batch of features.
Adding to that, in this collaboration style, everyone is expected to talk to everyone!
While collaboration is crucial for most agile teams, this overly synchronous approach is not appropriate for software development and it overlooks the unique challenges of distributed teams, which make up the majority of development teams today. What distributed teams need are great dashboards and streamlined communication channels, not endless meetings. Oh, and they need a LOT of focused time, where people can put their heads in the sand and code away their features.
But let’s not forget about specialization.
Most training in scrum does not address the true nature and intricacies of cross-functional teams. While a powerful alternative, cross-functional teams are not always possible or desired. If your team operates in a highly specialized way, with certain people being responsible for certain functions, you can’t force everybody to work differently to fit a framework. It might not be desirable. It’s OK that you hire an expert consultant to do parts of your system. And that for now they are the only people who can create certain pieces of your product. That’s actually how you go after excellence, by hiring people who really know how to use certain technologies or who understand the industry like no other.
These consultants would work together with your team, but it’s unrealistic to expect that everybody will lean and execute together at that level. It’s not fast, it’s not effective. I mean, you can’t take 10+ years of experience from someone and make your team generate something like that in, say 3 sprints.
But perhaps the most damaging aspect of this failed promise is the artificial constraints it imposes. Scrum dictates that development cycles must fit neatly into sprint’s length, regardless of the complexity or requirements of the task at hand. The sprint ends up being nothing more than an artificial deadline, when in fact certain tasks can take up to week 15 days while others take 3 and that would be perfectly fine.
In fact, while I think scrum is an interesting framework, too much can go wrong, especially if you decide to adopt it outside of a single team. In reality what I’ve seen is that all the events and roles make people have infinite discussions about irrelevant problems that the department or the teams did not have before scrum as implemented.
What can you do to increase productivity?
The flabbergasting piece here is that productivity is not a matter of doing more, but becoming better at deciding what is worth doing. And then doing it with focus.
You know I’m not one to suggest recipes, so I’d say you have to test the waters here t understand what the true problem of productivity is. Quite often it will be about wanting to do everything, instead of doing what is worth doing. What has the best ROI. Sometimes even understanding how to calculate an ROI of activities and projects is hard in departments and teams. So I wouldn’t be surprised to start there.
We can then talk about understanding where the current Lead Time and Cycle Time are landing. But that is irrelevant if you can gain speed but still be doing the wrong bets as far as the features you decide to deliver. You’d be fast at delivering not-value-add items. Who’s that helping?
Have the conversations about the inevitable reality of time constraints (time will forever be a limited resource) and decide what must NOT be done, can’t be done, or shouldn’t be done. Yes, make decisions on what’s out of the list, of the roadmap, of the request queue. It’s too easy to think about what we must and want to do. Maybe flipping the script puts the conversation in the right mode: there are constraints and there are next best options. But you can’t possibly do everything.
4 – The Mirage of Empowered Self-Organizing Teams
Another scrum failed promise? Empowered and self-organized teams rub some people the wrong way. Scrum certainly sold us on the dream of autonomous teams, yet managers and individual contributors alike are not so sure about the reality of self-organization.
Let’s address the elephant in the room. Can the team truly self organize? If they decide to NOT use scrum, can they really do that? The truth is there are constraints to how much teams can self-organize. And when they truly do try, many times they are ignored in their claims. One example?
Scrum advocates for team decision-making, yet not all teams can make decisions in all circumstances. There are more than valid reasons for teams maybe only be allowed to present options, with final decisions resting in the hands of their managers. I’d argue that many teams don’t even want to make certain decisions, they just want to code their products and deliver great quality. They want decision-making only when it’s about something rather technical.
Another example? Of course, we should all understand where our customers come from and what they want from the products we create! But we already have the product owner, marketing, business and so many more people looking at that aspect. Who else, however is looking at great aspect of the technology behind how we service our customers?
You guessed it: only the technical team.
This is the disservice I feel Scrum implementations can bring. Developers should understand their customers and should create the best product possible. But let’s not forget their focus and the superpower they bring to the table is rather technical. Being technical is how developers serve their customers. How often do you see product owners reluctant at when the team advocates for more time for better quality or paying off technical debt? But the scrum playbook has zero words on how to improve technical excellence.
Scrum can be rather flaccid on all aspects of technical expertise. Which makes it a sore point. While the framework says it’s like that, incomplete that by design, you could argue that it should at least propose in the famous scrum guide that this gap MUST be filled in real life with great engineering practices otherwise Scrum cannot work. But it doesn’t spell it out. I mean, I remember being the only one in the room advocating for practices in quality and continuous integration that many coaches and product owners did not know or didn’t care. And I’m talking about several different teams in several organizations.
So, have you ever met a couple of developers that did not trust the scrum master, whether that was you or someone else? Have you seen developers raving about the magnificent powers of scrum? I bet you haven’t met many… And these are just some of the reasons why.
What can you do to help teams self-organize?
Teams can and should self-organize about what they control and master, in this example, the whole aspect of software production and delivery. They are constrained about other aspects in the organization as far as the product goes AND this is normal.
As a coach I would reset the expectations with the teams so people are not left feeling they could have a saying on EVERYTHING in the organization. A certain level of compartmentalization allows for people to be very good at what they do. And it’s by partnering together with clear interfaces and attending to constraints that they can operate at their best sustainable possible.
I’d have teams and their leaders clarify expectations, constraints. Start teams the right way or reset them. Teams have a reason to be. Teams should agree on a process for great work to be developed. I wrote about some of my favorite team models and how they can help in that sort of conversation in this post.
When you do so, you’ll have invested, accountable, motivated people. Because you hire and grow your people to their best and trust them to make great decisions on the realm of their expertise.
5 – The Promise of Predictable Delivery
But before we close this post, the final scrum failed promise I want to mention, is that Scrum hints predictable delivery through short iterations, your sprint. But is that predictability? That’s predictability about when to have a sprint review alright. But the scrum guide tells you:
“Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.” — Scrum Guide 2020.
But predictability is not inspection against a goal. Predictability is about being able to tell when something will be done, given a certain percentage of confidence. Like saying “I’m 75% confident that we will hit our target date of May 1st”. This sort of thing has a name and it’s called probabilistic forecasting, and you can achieve that if you can keep track of units of work (user stories, tasks, whatever name you give to things) and the time they’ve taken. Historically.
Running sprints do nothing really for forecasting. You can put a rule that a release must happened by the end of every sprint. That’s great news! But there is no guarantee that each release will add up to the scope you want in the timeline you desire. So in that sense it’s a scrum failed promise because it’s an empty promise.
Now here’s the truth worth knowing: there ARE some levels of predictability and forecasting inherent in software development. It’s possible alright, especially when a team understands deeply their work or when they do some sort of repetitive or catalog-based work, like when they only build REST APIs, or websites, or maybe they’re responsible for a layer of the application, say the database scripts. Or maybe they do the custom installation of a software. In fact, the more mature a team, the more they’re able to tell you with a certain level of confidence the order of magnitude about how long it takes to complete certain types of work.
The team is not responsible for the calendar deadline, but for the effort though!
Now there are unforeseen issues and changes that can happen in any project that can affect deadlines. I would argue they come from PMO and business side a bit too often. And because we created the illusion of twice the work in half the time, there are way more demands placed on a team than they can realistically handle. And that constant pressure and juggling… most certainly can’t help you achieve predictability, even if you meet every other week and call that a sprint review.
Running sprints in itself does nothing really for forecasting. You can put a rule that a release must happened by the end of every sprint. That’s great news! But there is no guarantee that each release will add up to the scope you want in the timeline you desire. So, in that sense it’s a scrum failed promise because it’s an empty promise.
How to achieve predictability?
That is probably one of the most difficult aspects of agility, because predictability requires a ton of proactive management.
This could be a whole series of posts, so I’ll not attempt to give one single solution here, although I’ve already hinted at forecasting, value streams, controlling lead time. Transparency and commitment at all levels is needed as well. You see, when a team is delivering something, they will already encounter problems and they might need leadership support to take impediments out of the way.
If managers and unable to help with impediments and on top of that don’t commit, AKA, keep asking for other features, changing their minds way too often, the team is at double loss.
I’ll leave you with this thought: predictability can happen at any level in the organization. Maybe your team cannot be any faster, but they can have some level of predictability given their constraints. And consider that the higher the layer of the organization you can push for, the more predictability your whole system will have.
Scrum Failed Promises… Now What?
I know this might be ending a bit too cynical or sour. But please don’t be jaded or cynical. I started this conversation on the limitations of agile frameworks a while back to remove the fake power of these frameworks and give it back to you.
And another piece of the truth? Scrum can help you get started with agile if you’d love to try and need a bit more structure. Scrum will fail however if you are led to believe this is all you need to “become agile”.
It is also overdue to rethink the role of framework certifications, especially when you spend no less than 2 full days and pay more than a thousand dollars to reach level 1 on Scrum… and that certification and experience will not yield preparation for yourself or guarantee success for your team, should they adopt scrum.
But here’s the silver lining: Scrum’s greatest contribution might be popularizing agile retrospectives. Love them or hate them, retrospectives are an incredible tool for collective learning and team performance. When done right, they can be a game-changer. Imagine having a dedicated space to reflect on what’s working and what’s not, to identify areas for improvement, and to make informed decisions to optimize your team’s workflow! Retrospectives are an opportunity that Scrum’s failed promises shouldn’t take away from you.
That’s what I’ll post about next week!
