Its like piling the family into the minivan for a cross-country trip. Then going 85 down the highway until the first exit. Then everyone gets out, trades places, and you barrel down the highway at 85 until the next exit. Repeat a few times and then halfway to California you have to hitch up a trailer to the minivan and start going 120 between exits while also sending status updates at every mile marker.
What they're talking about is a process that someone is calling Scrum, but is nothing of the sort.
A real Scrum process can be modified at any time to make it more workable/manageable/realistic. The Sprint Review is FOR modifying the process.
If Sprints seem to be never-ending-stress, then you're self-selecting too much work for a Sprint. Yes, self-selecting. In real Scrum, everyone chooses what tasks they agree to get done in the next Sprint. You set your own pace, and it's meant to be sustainable and constant, unlike the pressure-buildup in Waterfall work.
Sprint was a bad choice of name. It shouldn't have been related to races at all. If anything, it should be more like walking. It's about figuring out what pace is sustainable for your particular team, and sticking to that pace. Not driving anyone too hard, but delivering value (i.e. working software features and updates) at regular intervals. If a feature is too big to deliver in a single increment of time (Sprint), then it should be broken down into multiple features that build upon one another to eventually become the whole thing.
"Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants"
-- Yes, and prescribed by whom? THE SPRINT TEAM! The people doing the work. You. The default times are just a starting point, and are limited to help prevent wasting time in meetings. You can modify anything about Scrum after you have used it for a bit and know what works for your team and what doesn't.
"Autonomy — the ability to direct one’s own work—plays a significant role in how work is experienced."
-- The post stated this as an argument for NOT using Scrum, but that's exactly what Scrum is meant to provide you with.
"In Scrum, programmers are like those mice subjected to involuntary effort, forced to run on treadmills of our bosses' making"
-- In Scrum, you don't have a boss. Your team has members, and everyone who's part of the team does real actual work in the Sprint. Yes, you have a Scrum Master, but they are part of the team, not a "supervisor". Their entire job isn't to track your hours, or force you to commit to something -- it's to run the Sprint meetings, solve your problems, get more resources, get clarification for you, and anything preventing you from getting the work you committed to for the Sprint, done by the end of the Sprint. That's it and that's all.
"Sprints Neglect Key Supporting Activities"
-- That's weird, because the team working on the Sprint is empowered to specify what supporting activities they want or don't want to include in a Sprint.
"There's no time is set aside for proper engineering prep work."
-- Scrum is about constantly delivering value to the client. If you need to figure out the best way to do something, and can't manage to produce any working code while you do that (doubtful) then you can at least say you'll provide the client with a Report on your findings, and why you're going to proceed with Route A over Route B. And as I said before, if there's no provision for that, make one! or do it in Sprint Planning. If you're part of the Sprint Team, you're in control of your process, and if it's not working, it's your fault, and your responsibility to help fix it. Maybe if someone normally does 20 points of work per Sprint, but they need to plan a lot this Sprint, then if the Sprint Team is ok with them delivering only 10 points of client-facing working code, but also 10 points of valuable research, then that's ok! You can also do a lot of this planning (at least at a basic level) during Discovery with the Client, even if the Client is internal.
"There’s always a Waterfall-like, big-bang deadline quietly lurking in the background"
-- You have been betrayed by all of the companies you've ever worked at who said they were doing Scrum, because they weren't. They were doing "sprint until you die", which isn't an actual process, but is how a lot of places work.
"The business side just can’t help itself"
-- Your Scrum Master needs to go to bat for you. Maybe the Business Side should only be told about features that have already been completed and will go live on this particular date and time. Don't pre-announce upcoming features except to say that "It's on our roadmap, but I can't tell you for when".
"With sprints, there are no breaks, little autonomy, and insufficient time to prepare."
-- A) True (but the pace is self-managed to be sustainable)
"Let developers control both their craft and their process. Treat them as respected peers, not replaceable cogs in a machine."
-- Your Scrum teams missed the memo about the people that comprise the team is a crucial aspect of the team? A Scrum team should be 100% self-contained, and be comprised of all the people it needs to be able to get the job done. This means from architecture, to UX/UI, to coding, and design." -- If you don't think the unique individuals on the team matter, you're dead wrong. When I was running Scrum teams, I brought the whole team into the interview whenever we were hiring someone to join their team. Who did I hire? The person the team wanted. This is part of how I view the self-management & autonomy of a Scrum Team.
"Achieving these conditions will likely require grassroots efforts"
-- yes, and that's how Scrum came about! It's literally solving what you're complaining about... except that companies have misused its name and implemented it so incorrectly that you now think it's the problem not the solution. How did this happen? Developers found out that Agile and Scrum were amazing. They were a much better way of working, that was sustainable, and fulfilling, and dare I say fun. They started quitting places that didn't do Agile or Scrum, and only applying to places that did. Shitty companies couldn't hire any good developers, so they started saying they "Do Agile". They started getting applications again. Only problem was, they already had a corporate infrastructure that didn't support Agile or Scrum, so you'd start noticing little things like "Hey, why is my Scrum Master asking me how many hours I've spent on a task instead of asking me what they can do to get barriers out of my way?" -- and this went on until the Agile and Scrum that companies professed to be practicing didn't resemble actual Scrum in the least. It was a bait and switch. So "scrum" sucks?
No, most companies aren't doing Scrum, because it's not easy. It takes discipline and trust. If I build a manual transmission car, and you insist on driving it like an automatic, it's not going to work for you, even though it's an amazing car. There are steps and processes that you must follow in order for the thing to work for you. If you don't, it won't. Simple as that. Put another way, if you enter the olympics for breakdancing, and then just flop your body around, you will not win the gold medal for breakdancing.
"Keep managers happy"
-- That isn't part of Scrum. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. There are also no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM.
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum.
Scrum is iterative, by design. It's supposed to evolve with the Client's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
**Scrum is just process for managing your process.**
Who should be involved? Just the people who follow the process (not their bosses, or PMs, or whatever)
What should they do? Keep making the process work better for themselves and the Client/Customer.
How should they do it? Repeat the same few meetings many times, planning your work, and getting feedback from the Client/Customer (Sprint Retro), and feedback from the team itself (Sprint Review) about how things should change for the next time through the loop, so that the results are better, and higher quality, and are done at a sustainable pace, etc.
Here's Scrum in a Nutshell:
Sprint Planning: Make sure everything in the Product Backlog has estimations attached. If not, estimate them now. Make sure you know your own personal velocity. Then each person answers: What work can each of us realistically commit to have done, for sure, by the end of this Sprint?
Daily Standup: (Each person answers) What did you finish since the last standup? What will you finish before the next one? Is there anything slowing you down?
Sprint Retrospective: (Present to Client) We finished all of the work for the Sprint. We will now demo it for you. [demo it] How do you like it? Any feedback? Do you like the list of tasks we have scheduled for the next Sprint, or would you like to reprioritize it? Thanks, see you at the next Sprint Retrospective meeting.
Sprint Review: (Team Meeting) What do you think went well? What do you think could have gone better? How do we want to change our process to reflect these?
You could even use Scrum at home if you wanted to.
Say your family is sitting around the table on Sunday night.
Your dad tells you that he's unhappy because you didn't take out the trash like you said you would (Sprint Retrospective).
You say that next time you'll set an alarm on your phone so you don't forget next time (Sprint Review).
Then everyone talks about what they are going to do in the upcoming week (Sprint Planning).
Throughout the week you hear bits and pieces over breakfast (Daily Standup).
While all of this sounds nice in theory - what it's like in practice? What percentage of companies actually do scrum the right way? I have most certainly never worked for one, and never met anyone who worked for one, so I'm guessing it's very low, like < 5%.
If the rules of scrum are so difficult to apply, or unlikely to be followed, what does this say about the whole concept? Maybe it's simply incompatible with capitalism, where companies always look for more profit?
I like your example with a household, because this is where scrum can actually be applied quite easily - because a household's ultimate goal isn't making money. It involves doing things that are good for the people you care about, instead of some random dude on a yacht who doesn't even know you exist.
To me, it feels more like an ideology - it might works in a perfect world, but breaks down when confronted with reality. And repeating "you're just doing it wrong" will not change that.
I think you're right that capitalism, at least how we are applying it, with only a few people at the top of an organization having ownership and true control, is probably getting in the way here. I think the only way to get rid of developer exploitation is to give developers a real place at the table, meaning real ownership in the company. Because, only then will we be able to pick our own processes.
I get what you're saying that the official definition of Scrum does not align with the process that the post describes. That said developers, QA, and others on the team are not usually experienced or trained project managers and don't how it's supposed to be done. They just know how things are done in practice, and in practice, the post does a pretty decent job covering our shared experiences.
Instead of saying "This post has Scrum all wrong", what you're really saying is that the industry is doing Scrum all wrong in a broad and pervasive way. But that only illustrates that this isn't right forum to address that.
I don't disagree (that analogy of "we're actually doing marathon at sprint pace" really hits home). But is this the fault of the process or the businesses that implement it?
In your first graph, there's no intrinsic reason for the scrum up/down wave to be as high as it is (other than the business wanting their features as fast as possible).
Curious your thoughts on Kanban. Any others?
If none of the above, what _is_ the solution to "corporate pressure makes processes suck for those working them"?
Yeah, I think you make a good point. It's kind of subjective where I put that Scrum curve, so others may experience it at a lower stress level, and that would make Scrum more attractive. Perhaps that would be the key to making a healthier Scrum implementation, pushing that line lower.
As for alternatives, I have been looking at some innovative strategies that depart from Scrum-like processes more dramatically. For example:
I know some of these aren't Software companies, but I think how they manage themselves is directly applicable (more essays to come on specific ways to use their ideas in software).
As a prospective engineer, I always ask during an interview if the team uses scrum (phrased more diplomatically as inquiring what they use). If they do, I do not continue. I guess there are enough engineers who carry a slave mentality and continue anyway, bringing everyone else down with them.
If you strictly avoiding companies that use scrum, your job options will be very limited. This is not about "slave mentality" but rather recognizing the practical realities of the job market.
I really wish I could put this as eloquently as Derek Martin has, but please read the scrum guide as you are describing what sounds to be a company culture issue.
All of your complaints are what scrum aims to solve. Scrum is a starting point and should be adapted on. If something doesn’t work for the team, drop it — *this is the advice of the actual scrum guide!*
As for opinions on kanban - if you’re not limiting your WIP in columns (a common issue), you’re not actually doing it.
An idea for a follow up post could be your opinions after actually reading what scrum is about.
"If something doesn’t work for the team, drop it — *this is the advice of the actual scrum guide!*"
That's not an advice, that's just one possible outcome. It's borderline realistic, if not entirely delusional.
1) It assumes that every person on the team thinks alike, works in the same way, and therefore has the same expectations of the development process.
2) It assumes that each team has infinite oversight of the development process and can change it as they please.
3) It assumes there are no external actors that might try to sway team's opinion on whether the change is even necessary.
In my other comment I wrote that this "correct" scrum feels to me like an ideology, and yeah, it shows. "Well, THE BOOK says so and so. Didn't work? Yeah buddy, that's definitely a company culture issue". Ok, so what now? Do I try again? Ask nicely? Get a new job?
Maybe the real issue is that scrum is a flawed concept, as it requires a level of cooperation and willingness to change that rarely happens in a company, while presenting itself as somewhat universal?
And that's jut one "advice". If the whole guide is like this then I'm not even remotely surprised it doesn't work in most cases.
The System (TM) tries to optimize and thereby extract maximum output. Turning the SW dev team into an Amazon Fulfillment center seems like a logical conclusion. Sprints are only the beginning.
Keystroke metrics, browsing behavior etc is the next wave, already made landfall.
The other thing is Agile itself is vastly imperfect and we really need to use a combination of Agile and Waterfall. Agile says that the written code is the primary measure of progress almost as though design documents and user stories are useless. Thats not true at all and doing a grave injustice to the craft and creativity that goes into technical design, documentation of design diagrams and the writing of user stories. Also Agile seems to say that face to face or video communication is better than emails. That should not be so also. Written communication in the form of documentation of email has a trail that people can refer to and share easily. Verbal communication often does not have a written trail. The only good feature of Agile appears to iterative development, everything else seems to be superfulous.
I have been a SCRUM magician for many years. In many companies and situations. The problem is the basic understanding of SCRUM. First and foremost, SCRUM is a democratic element for the company, the department. Unfortunately, this is often completely ignored. So the workload of a sprint must be determined by the members, by everyone themselves. A product manager (and higher up) or something like that can determine the direction, the next steps, but never whether the scope for the sprint is correct and matches the life balance. This is determined by the members who do the work in the team. In the team because as a team they develop a higher power and can ward off workloads that destroy life balance. It is a sacred principle where the power of defining what can and cannot be done in the next sprint lies. That lies solely with the team members who do the work.
If this is not handled correctly and does not work, the basic SCRUM idea collapses and it becomes a stress tool to put the individual team members under perfect pressure. The author seems to have experienced this.
The dynamics that SCRUM can trigger are also massively limited or destroyed.
On the other hand, if real SCRUM is maintained in its democratic functions in the company, it can lead to a good life balance among all team members and in the long term such teams are even significantly more productive. This is my experience over many years, without exception.
Another positive side-effect of introducing HIP Sprints into the regular cadence is relieving the teams from a constant marathon run. The HIP Sprint provides the team the ability to stop, rest, and work towards planning rather than delivering.
I love this idea. Inserting these non-product sprints would certainly help lighten that feeling of constant expectation. Nice work getting those adopted in your organization! How did you manage to convince stakeholders to let you do that? Given that pure Scrum calls for continuous product sprints?
The problem I see is people in the scrum/agile space are fucking fanatical about it.
they just cant get themselves out of the head space that their way is like "the enlightened" way and everyone else is wrong and if they would only open themseleves up to learn their way then we'd all get so much more done!
They also love the try and shoehorn it into BAU work flows that just . dont. work. like. that.
To top it off, management love it because it gives them nice easy canned reports they can push up the ladder to make their team look productive. Ignoring the fact it's just ruining the ability for these people to just get the work done.
I agree that the status quo/BAU isn't innovative and dynamic enough to handle the complexity of software. It's a totally unique beast that only empowered programmers can tame effectively. You need developers making real-time decisions, not waiting for less informed top-down direction and monitoring.
You have it all wrong. Scrum IS about self-management, as a team, and as an individual. I'll post a better comment about it. As for Kanban vs Scrum, they're for different purposes. Kanban is great for when you have a never-ending list of tasks, like working on SaaS app that is the primary thing your company sells. Scrum is more for when you want to keep scope and cost and timelines flexible, by having a repeating feedback loop. Both are sustainable when done right, but so so so many companies botch them to the point of unrecognizability and continue to call it Scrum or Kanban.
Hi Derek, there are two versions of scrum. The version you mention is textbook scrum. It rarely exists IRL. The version Adam discusses is real world scrum. This is a scrum where developers do not have autonomy and must follow the scrum process as dictated by there scrum master and management.
Ya, I’m just saying that second “version” isn’t Scrum AT ALL.
Companies saying they do Scrum doesn't mean they actually do Scrum.
Buyer: Is that a Ming vase?
Seller: Yes! It's virtually identical, except this angle is a little more dramatic, and those colours that weren't appropriate for the time, but yes it is.
Buyer: It's not a Ming vase.
Now replace Buyer with Potential Employee, and Seller with Employer. Ask HOW they implement Scrum before you accept the offer.
The view I have been taking is that Scrum is essentially how it is implemented. It's the result of what people take from the Scrum Guide and their certificate training and from tradition and blogs and all kinds of other things. Basically, I care about how Scrum is practiced -- because that results in how it is experienced. My feeling is that many (most?) people have a negative experience with it. I want to explore that in my writing and purpose solutions.
I agree that the Scrum Guide does not include all of what makes Scrum a bad experience (although some of it does come directly from canonical Scrum as it's explained in the Scrum Guide), and I'm working on some essays today tease apart the theoretical from the experienced. Hopefully you'll like those. I did a little bit of that here:
The funny thing is that an actual sprint (the kind with your feet/legs) has a break after the sprint. If there was no break, it'd be a marathon.
Most software projects are marathons and should be paced as much, even with frequent releases.
Its like piling the family into the minivan for a cross-country trip. Then going 85 down the highway until the first exit. Then everyone gets out, trades places, and you barrel down the highway at 85 until the next exit. Repeat a few times and then halfway to California you have to hitch up a trailer to the minivan and start going 120 between exits while also sending status updates at every mile marker.
PART ONE OF TWO
This post has Scrum all wrong.
What they're talking about is a process that someone is calling Scrum, but is nothing of the sort.
A real Scrum process can be modified at any time to make it more workable/manageable/realistic. The Sprint Review is FOR modifying the process.
If Sprints seem to be never-ending-stress, then you're self-selecting too much work for a Sprint. Yes, self-selecting. In real Scrum, everyone chooses what tasks they agree to get done in the next Sprint. You set your own pace, and it's meant to be sustainable and constant, unlike the pressure-buildup in Waterfall work.
Sprint was a bad choice of name. It shouldn't have been related to races at all. If anything, it should be more like walking. It's about figuring out what pace is sustainable for your particular team, and sticking to that pace. Not driving anyone too hard, but delivering value (i.e. working software features and updates) at regular intervals. If a feature is too big to deliver in a single increment of time (Sprint), then it should be broken down into multiple features that build upon one another to eventually become the whole thing.
"Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants"
-- Yes, and prescribed by whom? THE SPRINT TEAM! The people doing the work. You. The default times are just a starting point, and are limited to help prevent wasting time in meetings. You can modify anything about Scrum after you have used it for a bit and know what works for your team and what doesn't.
"Autonomy — the ability to direct one’s own work—plays a significant role in how work is experienced."
-- The post stated this as an argument for NOT using Scrum, but that's exactly what Scrum is meant to provide you with.
"In Scrum, programmers are like those mice subjected to involuntary effort, forced to run on treadmills of our bosses' making"
-- In Scrum, you don't have a boss. Your team has members, and everyone who's part of the team does real actual work in the Sprint. Yes, you have a Scrum Master, but they are part of the team, not a "supervisor". Their entire job isn't to track your hours, or force you to commit to something -- it's to run the Sprint meetings, solve your problems, get more resources, get clarification for you, and anything preventing you from getting the work you committed to for the Sprint, done by the end of the Sprint. That's it and that's all.
"Sprints Neglect Key Supporting Activities"
-- That's weird, because the team working on the Sprint is empowered to specify what supporting activities they want or don't want to include in a Sprint.
"There's no time is set aside for proper engineering prep work."
-- Scrum is about constantly delivering value to the client. If you need to figure out the best way to do something, and can't manage to produce any working code while you do that (doubtful) then you can at least say you'll provide the client with a Report on your findings, and why you're going to proceed with Route A over Route B. And as I said before, if there's no provision for that, make one! or do it in Sprint Planning. If you're part of the Sprint Team, you're in control of your process, and if it's not working, it's your fault, and your responsibility to help fix it. Maybe if someone normally does 20 points of work per Sprint, but they need to plan a lot this Sprint, then if the Sprint Team is ok with them delivering only 10 points of client-facing working code, but also 10 points of valuable research, then that's ok! You can also do a lot of this planning (at least at a basic level) during Discovery with the Client, even if the Client is internal.
"There’s always a Waterfall-like, big-bang deadline quietly lurking in the background"
-- You have been betrayed by all of the companies you've ever worked at who said they were doing Scrum, because they weren't. They were doing "sprint until you die", which isn't an actual process, but is how a lot of places work.
"The business side just can’t help itself"
-- Your Scrum Master needs to go to bat for you. Maybe the Business Side should only be told about features that have already been completed and will go live on this particular date and time. Don't pre-announce upcoming features except to say that "It's on our roadmap, but I can't tell you for when".
"With sprints, there are no breaks, little autonomy, and insufficient time to prepare."
-- A) True (but the pace is self-managed to be sustainable)
-- B) False (Scrum is all about autonomy)
-- C) False, as stated above.
PART TWO OF TWO
"Let developers control both their craft and their process. Treat them as respected peers, not replaceable cogs in a machine."
-- Your Scrum teams missed the memo about the people that comprise the team is a crucial aspect of the team? A Scrum team should be 100% self-contained, and be comprised of all the people it needs to be able to get the job done. This means from architecture, to UX/UI, to coding, and design." -- If you don't think the unique individuals on the team matter, you're dead wrong. When I was running Scrum teams, I brought the whole team into the interview whenever we were hiring someone to join their team. Who did I hire? The person the team wanted. This is part of how I view the self-management & autonomy of a Scrum Team.
"Achieving these conditions will likely require grassroots efforts"
-- yes, and that's how Scrum came about! It's literally solving what you're complaining about... except that companies have misused its name and implemented it so incorrectly that you now think it's the problem not the solution. How did this happen? Developers found out that Agile and Scrum were amazing. They were a much better way of working, that was sustainable, and fulfilling, and dare I say fun. They started quitting places that didn't do Agile or Scrum, and only applying to places that did. Shitty companies couldn't hire any good developers, so they started saying they "Do Agile". They started getting applications again. Only problem was, they already had a corporate infrastructure that didn't support Agile or Scrum, so you'd start noticing little things like "Hey, why is my Scrum Master asking me how many hours I've spent on a task instead of asking me what they can do to get barriers out of my way?" -- and this went on until the Agile and Scrum that companies professed to be practicing didn't resemble actual Scrum in the least. It was a bait and switch. So "scrum" sucks?
No, most companies aren't doing Scrum, because it's not easy. It takes discipline and trust. If I build a manual transmission car, and you insist on driving it like an automatic, it's not going to work for you, even though it's an amazing car. There are steps and processes that you must follow in order for the thing to work for you. If you don't, it won't. Simple as that. Put another way, if you enter the olympics for breakdancing, and then just flop your body around, you will not win the gold medal for breakdancing.
"Keep managers happy"
-- That isn't part of Scrum. If you read any of the Scrum books by the creators of Scrum, you'll find that the way 95% of companies implement Scrum is nothing like what Scrum was intended to be. There are also no PMs in actual Scrum. Scrum Teams are self-managing, so there's no need for a PM.
There's a direct relationship between the Client and the Scrum Team. Where most companies screw up is in their business model. You can't charge a flat fee for fixed project description and call it Scrum.
Scrum is iterative, by design. It's supposed to evolve with the Client's needs and desires. They want to be able to change the scope, the price, and the timeline on a whim. If you aren't billing per-Sprint, then you're going to have a constant "charge the Client for a change request" mentality, which makes them feel like they're being Nickel and Dime. It's much better to say "We welcome your changes at any time for any reason. It may not fit in the next Sprint, but we can always put them in the one after that."
In Sprint-based projects the Client has to be free to terminate the agreement at any time, if they feel they're not getting enough value in exchange for their money. This is why constantly delivering value to the Client is key.
When they charge a flat fee, they feel they need a PM to make sure they don't lose money. And how can you know if you're losing money? You force people to track their hours back. It all gets toxic.
When the Client pays per Sprint, as long as each Sprint is profitable and delivering value, it can be a huge profit center that has no end date. Often times, Clients will just keep adding features forever instead of stopping at the flat fee end date.
**Scrum is just process for managing your process.**
Who should be involved? Just the people who follow the process (not their bosses, or PMs, or whatever)
What should they do? Keep making the process work better for themselves and the Client/Customer.
How should they do it? Repeat the same few meetings many times, planning your work, and getting feedback from the Client/Customer (Sprint Retro), and feedback from the team itself (Sprint Review) about how things should change for the next time through the loop, so that the results are better, and higher quality, and are done at a sustainable pace, etc.
Here's Scrum in a Nutshell:
Sprint Planning: Make sure everything in the Product Backlog has estimations attached. If not, estimate them now. Make sure you know your own personal velocity. Then each person answers: What work can each of us realistically commit to have done, for sure, by the end of this Sprint?
Daily Standup: (Each person answers) What did you finish since the last standup? What will you finish before the next one? Is there anything slowing you down?
Sprint Retrospective: (Present to Client) We finished all of the work for the Sprint. We will now demo it for you. [demo it] How do you like it? Any feedback? Do you like the list of tasks we have scheduled for the next Sprint, or would you like to reprioritize it? Thanks, see you at the next Sprint Retrospective meeting.
Sprint Review: (Team Meeting) What do you think went well? What do you think could have gone better? How do we want to change our process to reflect these?
You could even use Scrum at home if you wanted to.
Say your family is sitting around the table on Sunday night.
Your dad tells you that he's unhappy because you didn't take out the trash like you said you would (Sprint Retrospective).
You say that next time you'll set an alarm on your phone so you don't forget next time (Sprint Review).
Then everyone talks about what they are going to do in the upcoming week (Sprint Planning).
Throughout the week you hear bits and pieces over breakfast (Daily Standup).
Everyone is in the loop.
Expectations have been stated.
The process has been modified.
Commitments have been made.
Simple as that.
While all of this sounds nice in theory - what it's like in practice? What percentage of companies actually do scrum the right way? I have most certainly never worked for one, and never met anyone who worked for one, so I'm guessing it's very low, like < 5%.
If the rules of scrum are so difficult to apply, or unlikely to be followed, what does this say about the whole concept? Maybe it's simply incompatible with capitalism, where companies always look for more profit?
I like your example with a household, because this is where scrum can actually be applied quite easily - because a household's ultimate goal isn't making money. It involves doing things that are good for the people you care about, instead of some random dude on a yacht who doesn't even know you exist.
To me, it feels more like an ideology - it might works in a perfect world, but breaks down when confronted with reality. And repeating "you're just doing it wrong" will not change that.
I think you're right that capitalism, at least how we are applying it, with only a few people at the top of an organization having ownership and true control, is probably getting in the way here. I think the only way to get rid of developer exploitation is to give developers a real place at the table, meaning real ownership in the company. Because, only then will we be able to pick our own processes.
I get what you're saying that the official definition of Scrum does not align with the process that the post describes. That said developers, QA, and others on the team are not usually experienced or trained project managers and don't how it's supposed to be done. They just know how things are done in practice, and in practice, the post does a pretty decent job covering our shared experiences.
Instead of saying "This post has Scrum all wrong", what you're really saying is that the industry is doing Scrum all wrong in a broad and pervasive way. But that only illustrates that this isn't right forum to address that.
I don't disagree (that analogy of "we're actually doing marathon at sprint pace" really hits home). But is this the fault of the process or the businesses that implement it?
In your first graph, there's no intrinsic reason for the scrum up/down wave to be as high as it is (other than the business wanting their features as fast as possible).
Curious your thoughts on Kanban. Any others?
If none of the above, what _is_ the solution to "corporate pressure makes processes suck for those working them"?
Yeah, I think you make a good point. It's kind of subjective where I put that Scrum curve, so others may experience it at a lower stress level, and that would make Scrum more attractive. Perhaps that would be the key to making a healthier Scrum implementation, pushing that line lower.
As for alternatives, I have been looking at some innovative strategies that depart from Scrum-like processes more dramatically. For example:
https://substack.com/@rethinkingsoftware/note/c-69162795?r=gjvfp
https://substack.com/@rethinkingsoftware/note/c-69130210?r=gjvfp
https://substack.com/@rethinkingsoftware/note/c-66613526?r=gjvfp
https://substack.com/@rethinkingsoftware/note/c-66345327?r=gjvfp
I know some of these aren't Software companies, but I think how they manage themselves is directly applicable (more essays to come on specific ways to use their ideas in software).
As a prospective engineer, I always ask during an interview if the team uses scrum (phrased more diplomatically as inquiring what they use). If they do, I do not continue. I guess there are enough engineers who carry a slave mentality and continue anyway, bringing everyone else down with them.
If you strictly avoiding companies that use scrum, your job options will be very limited. This is not about "slave mentality" but rather recognizing the practical realities of the job market.
This valid criticism of Scrum was long overdue and needed to be written.
I really wish I could put this as eloquently as Derek Martin has, but please read the scrum guide as you are describing what sounds to be a company culture issue.
All of your complaints are what scrum aims to solve. Scrum is a starting point and should be adapted on. If something doesn’t work for the team, drop it — *this is the advice of the actual scrum guide!*
As for opinions on kanban - if you’re not limiting your WIP in columns (a common issue), you’re not actually doing it.
An idea for a follow up post could be your opinions after actually reading what scrum is about.
I'm working on a few essays that try to look at theoretical vs. applied Scrum. Here is one:
https://open.substack.com/pub/rethinkingsoftware/p/revisiting-why-scrum-is-the-wrong?utm_source=share&utm_medium=android&r=gjvfp
But I want to do a few more. I'll be interested in getting your take on how I do.
"If something doesn’t work for the team, drop it — *this is the advice of the actual scrum guide!*"
That's not an advice, that's just one possible outcome. It's borderline realistic, if not entirely delusional.
1) It assumes that every person on the team thinks alike, works in the same way, and therefore has the same expectations of the development process.
2) It assumes that each team has infinite oversight of the development process and can change it as they please.
3) It assumes there are no external actors that might try to sway team's opinion on whether the change is even necessary.
In my other comment I wrote that this "correct" scrum feels to me like an ideology, and yeah, it shows. "Well, THE BOOK says so and so. Didn't work? Yeah buddy, that's definitely a company culture issue". Ok, so what now? Do I try again? Ask nicely? Get a new job?
Maybe the real issue is that scrum is a flawed concept, as it requires a level of cooperation and willingness to change that rarely happens in a company, while presenting itself as somewhat universal?
And that's jut one "advice". If the whole guide is like this then I'm not even remotely surprised it doesn't work in most cases.
Stress levels are up.
The System (TM) tries to optimize and thereby extract maximum output. Turning the SW dev team into an Amazon Fulfillment center seems like a logical conclusion. Sprints are only the beginning.
Keystroke metrics, browsing behavior etc is the next wave, already made landfall.
Totally: https://substack.com/@rethinkingsoftware/note/c-69034012?r=gjvfp
Lost of meeting consumes the development time and that is not measured in Scrum estimations.
The other thing is Agile itself is vastly imperfect and we really need to use a combination of Agile and Waterfall. Agile says that the written code is the primary measure of progress almost as though design documents and user stories are useless. Thats not true at all and doing a grave injustice to the craft and creativity that goes into technical design, documentation of design diagrams and the writing of user stories. Also Agile seems to say that face to face or video communication is better than emails. That should not be so also. Written communication in the form of documentation of email has a trail that people can refer to and share easily. Verbal communication often does not have a written trail. The only good feature of Agile appears to iterative development, everything else seems to be superfulous.
Anyone that critizises Agile, doesn't speak of an alternative or another way of doing things better...
Shape Up. That's what you are unknowingly suggesting as a solution to the problem you detailed at length.
But ShapeUp is not suitable for a vast majority of industries and environments.
I have been a SCRUM magician for many years. In many companies and situations. The problem is the basic understanding of SCRUM. First and foremost, SCRUM is a democratic element for the company, the department. Unfortunately, this is often completely ignored. So the workload of a sprint must be determined by the members, by everyone themselves. A product manager (and higher up) or something like that can determine the direction, the next steps, but never whether the scope for the sprint is correct and matches the life balance. This is determined by the members who do the work in the team. In the team because as a team they develop a higher power and can ward off workloads that destroy life balance. It is a sacred principle where the power of defining what can and cannot be done in the next sprint lies. That lies solely with the team members who do the work.
If this is not handled correctly and does not work, the basic SCRUM idea collapses and it becomes a stress tool to put the individual team members under perfect pressure. The author seems to have experienced this.
The dynamics that SCRUM can trigger are also massively limited or destroyed.
On the other hand, if real SCRUM is maintained in its democratic functions in the company, it can lead to a good life balance among all team members and in the long term such teams are even significantly more productive. This is my experience over many years, without exception.
https://medium.com/@dallasclark/how-to-reduce-your-technical-debt-footprint-a99f89e81dec
Another positive side-effect of introducing HIP Sprints into the regular cadence is relieving the teams from a constant marathon run. The HIP Sprint provides the team the ability to stop, rest, and work towards planning rather than delivering.
I love this idea. Inserting these non-product sprints would certainly help lighten that feeling of constant expectation. Nice work getting those adopted in your organization! How did you manage to convince stakeholders to let you do that? Given that pure Scrum calls for continuous product sprints?
The problem I see is people in the scrum/agile space are fucking fanatical about it.
they just cant get themselves out of the head space that their way is like "the enlightened" way and everyone else is wrong and if they would only open themseleves up to learn their way then we'd all get so much more done!
They also love the try and shoehorn it into BAU work flows that just . dont. work. like. that.
To top it off, management love it because it gives them nice easy canned reports they can push up the ladder to make their team look productive. Ignoring the fact it's just ruining the ability for these people to just get the work done.
I agree that the status quo/BAU isn't innovative and dynamic enough to handle the complexity of software. It's a totally unique beast that only empowered programmers can tame effectively. You need developers making real-time decisions, not waiting for less informed top-down direction and monitoring.
Nice write-up. It would be interesting to hear your thoughts about Kanban!
Kanban is lot better than Scrum. Although, I really think it's time for engineering companies to start using self-management. Some good examples are Morning Star (https://substack.com/@rethinkingsoftware/note/c-69162795) and Haier (https://substack.com/@rethinkingsoftware/note/c-69130210) and Valve (https://substack.com/@rethinkingsoftware/note/c-66613526).
You have it all wrong. Scrum IS about self-management, as a team, and as an individual. I'll post a better comment about it. As for Kanban vs Scrum, they're for different purposes. Kanban is great for when you have a never-ending list of tasks, like working on SaaS app that is the primary thing your company sells. Scrum is more for when you want to keep scope and cost and timelines flexible, by having a repeating feedback loop. Both are sustainable when done right, but so so so many companies botch them to the point of unrecognizability and continue to call it Scrum or Kanban.
Hi Derek, there are two versions of scrum. The version you mention is textbook scrum. It rarely exists IRL. The version Adam discusses is real world scrum. This is a scrum where developers do not have autonomy and must follow the scrum process as dictated by there scrum master and management.
Ya, I’m just saying that second “version” isn’t Scrum AT ALL.
Companies saying they do Scrum doesn't mean they actually do Scrum.
Buyer: Is that a Ming vase?
Seller: Yes! It's virtually identical, except this angle is a little more dramatic, and those colours that weren't appropriate for the time, but yes it is.
Buyer: It's not a Ming vase.
Now replace Buyer with Potential Employee, and Seller with Employer. Ask HOW they implement Scrum before you accept the offer.
The view I have been taking is that Scrum is essentially how it is implemented. It's the result of what people take from the Scrum Guide and their certificate training and from tradition and blogs and all kinds of other things. Basically, I care about how Scrum is practiced -- because that results in how it is experienced. My feeling is that many (most?) people have a negative experience with it. I want to explore that in my writing and purpose solutions.
I agree that the Scrum Guide does not include all of what makes Scrum a bad experience (although some of it does come directly from canonical Scrum as it's explained in the Scrum Guide), and I'm working on some essays today tease apart the theoretical from the experienced. Hopefully you'll like those. I did a little bit of that here:
https://open.substack.com/pub/rethinkingsoftware/p/revisiting-why-scrum-is-the-wrong
but I want to dive a lot deeper. Thanks for taking time to engage with the content! I look forward to your future comments!