> they decided to openly and freely share their work.
I LOVE this story. Thank you for sharing it. It's stuff like this that makes me crave the Web 1.0 (and early 2.0) days. This makes me want to support Mastodon, and Vivaldi, and other federated and open systems. I'm as guilty as anyone, allowing social apps like twitter & Facebook to take me away from writing on my hand-rolled blog. I need to get that puppy back up and running. I need to share more. Be the change I want to see in the Internet & Web.
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 move your body around in a floppy way, you will not win the gold medal.
There are 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.
I could have been more clear there, "PM" has many different meanings these days.
I've never been on a team using scrum that didn't have a project manager or product manager as part of scrum (or both). Most often they have been my scrum leader.
Scrum is supposed to be self-guided, but I have never seen it implemented on a team of any scale.
I also wouldn't expect a team without PMs, whether that's project managers or product managers, to be very effective. Someone needs to be focused on keeping the project moving, and often the skills needed for a scrum leader/master overlap greatly with project managers. Someone also needs to be focused on the product and how the team's efforts fit into the longer term product goals. If that isn't anyone with a PM title it will be someone else playing that role with everything but the title.
"Keep managers happy" isn't part of Scrum, either. 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. They mess it up, essentially in the name of marketing, and not wanting to truly change their ways.
The Scrum Master is supposed to be part of the team, constantly helping with the Sprint, whether that's getting clarification for you, or pushing back on unrealistic expectations, or getting more resources, or whatever. Sprint was a bad choice of terms. 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 be the whole thing.
Yes, sure, all of that. But also, my boss's boss and my boss's boss's boss are looking at velocity and continually asking for more. They've got dashboards for it. Managers have to answer for why their team's velocity is different from another manager's team. Et cetera.
You can say "don't do that that's not how it works" until you're blue in the face, and it will still happen.
That's the critical failure of Scrum: it's one giant managerial dark pattern that's full of enticements to abuse it. Those enticements are constant. The exhortations to not do it that way are buried in the fine print somewhere, and the only reminders about them are coming from disgruntled individual contributors, probably from lower-performing teams, whose opinion is therefore suspect. The managerial opinion is probably that they should stop whining and make the deadline already.
I keep wishing we could instead have an agile framework that works with human nature instead of fighting against it.
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 pace in Waterfall work.
"Every aspect of a sprint is prescribed: its duration, its meetings, its tasks, and even the roles of its participants" -- yes, and prescribed by who? THE SPRINT TEAM! The people doing the work. You.
"Autonomy—the ability to direct one’s own work—plays a significant role in how work is experienced." -- the article 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 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, 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" - Really? That's weird, because the team working in the Sprint can specify what needs to be part of every task in the 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. The Business Side should only be told about features that have been completed, or are about to be completed, not about 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." -- True (but the pace is self-managed to be sustainable), False (Scrum is all about autonomy), & False, as stated above.
"Let developers control both their craft and their process. Treat them as respected peers, not replaceable cogs in a machine." -- Did your Scrum team miss 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.
"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.
Scrum is a process designed to help you continuously improve your own process, while always delivering value to the Customer along the way. That's it. Dead simple.
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?
I LOVE this story. Thank you for sharing it. It's stuff like this that makes me crave the Web 1.0 (and early 2.0) days. This makes me want to support Mastodon, and Vivaldi, and other federated and open systems. I'm as guilty as anyone, allowing social apps like twitter & Facebook to take me away from writing on my hand-rolled blog. I need to get that puppy back up and running. I need to share more. Be the change I want to see in the Internet & Web.
Information wants to be free. Hack the planet!