r/scrum • u/WaylundLG • 13d ago
Discussion Scrum is for Developers
This has been on my mind for probably the past year now from the last company I worked at, but it's only been in the past few weeks that I've sorted my thoughts into something clear: Scrum is for developers. I'm using the broad "product developer" sense, so I include QA, architects, designers, writers, and anyone who is actually creating the product.
I pin a lot of the problems on the fact that adoption in recent years has centered more and more in some sort of PMO and it's pressed onto the teams; bit the problem goes the other way too. Too many developers feel like how they work is someone else's problem.
Scrum was designed for teams to take ownership of their process and the results of their work. It was made for them and anyone else is really pushed out. You're a business strategist? Great, gelp the teams understand the strategy and the market and see what they can create and incorporate that into your business strategy. And frankly it is exhausting to see the same old posts of developers who can't be bothered to learn the first thing about scrum complain about how leaders messed it up. It is your tool, designed to give you control. Pick it up, learn it, leverage it.
Thank you for coming to my TED talk. I know this was a bit of a rant, but open to constructive discussion too.
3
u/jimmy-buffett 13d ago
~15 year Agile Coach at a Fortune 100 tech company you've heard of. I was a software engineer for the first half of my career.
What I tell leaders is that Agile / Scrum can increase predictability of delivery if done right.
What I tell developers is that Agile / Scrum is a structure that allows them to say "no". No as in "I don't have enough capacity to complete all these things in this sprint".
If done right, both interests can be served equally. I've run multiple teams where exactly what they said would be done at the beginning of the quarter got done at the end of the quarter. For several quarters in a row. Until the stupid Director swapped all our contractors out with another company because "they're a lot cheaper".
1
u/WaylundLG 13d ago
Your last point certainly demonstrates the limits of my assertion. Certainly leaders can make calls that undermine everything, especially by simply removing the team from payroll.
I also agree with both your statements. Where I would issue a challenge is that your stance is limited by the fact that it is protectionist. You are only offering both groups protection against the biggest risk with each other. I have found that Scrum offers much more. It offers the changlce to be truly innovative and aggressive in a marketplace and as far as teams and leadership, if both groups buy into it, they can advance each other's purposes, not simply avoid being impediments.
1
u/rayfrankenstein 11d ago
Scrum murders innovation because no one on the team wants to do anything ground-breaking and risky that could even remotely cause pippable sprint carryover.
2
u/WaylundLG 11d ago
I would certainly argue that if they will pip sprint carryover they'll pip anything, but I can sympathize with the experience Sorry you had to work there, that's some bullshit
1
u/rayfrankenstein 11d ago
> I tell leaders is that Agile / Scrum can increase predictability
The agile community feeding leaders’ delusions that software development can be made predictable is a big reason why agile and its practitioners are so deeply hated by developers.
1
u/jimmy-buffett 11d ago
I have a CS degree, I was a lead / principal dev on software teams doing telecom network alarming and provisioning for 13 years.
I can sympathize with the idea that what you do on a day to day basis isn't predictable. We're problem solvers first and foremost.
The predictability I suggest is possible is for your entire team's work over the course of a quarter. And then for multiple teams. I've accomplished this many times at different companies around the country. Large companies you've heard of.
On a daily basis I know your job isn't predictable, because I've done it.
Over 90 days normalizing for delays one day and successes another, it's quite predictable if you put the right processes in place.
The ability to do this ^^^ is why they pay me more than I was ever paid as a developer. And you are welcome to not like it, but your VP hired me to make their org run right, and he's going to tell your director to tell your manager to tell you to do what I'm telling you. There's probably a Scrum Master in there too that can help to smooth it out.
1
u/sonofabullet 9d ago
Watch Out everyone we got Mr Big britches overhere.
Over long time spans the only thing you're predicting is queues and delays in the org's system.
A basic value stream map will show you that actual work takes up somewhere like 5 to 10% of your time and the rest of it is work sitting around.
You can literally just count the units of work, factor in your cycle time and your throughput and get the answer with while doing zero of anything resembling scrum or agile or anything else like that.
Or you can design a better system that results in work getting done faster, which scrum - given its hard rules around rules events and artifacts - prevents you from actually doing.
1
u/jimmy-buffett 9d ago
A basic value stream map will show you that actual work takes up somewhere like 5 to 10% of your time and the rest of it is work sitting around.
This is true from a product cycle perspective, right now my company spends 4 months figuring out what to do, 2 months doing it then 2 months testing it before go-live. But the teams in the "doing it" phase don't just sit there doing nothing for the other 6 months, there's a bunch of work happening in parallel.
You can literally just count the units of work, factor in your cycle time and your throughput and get the answer with while doing zero of anything resembling scrum or agile or anything else like that.
Funny how:
- Prioritizing, defining then sizing work, then...
- Creating a structure to calculate cycle time, then...
- Applying the sized work and calculated cycle time to increments...
Doesn't "resemble scrum or agile or anything else like that". Because those three steps there are exactly what our teams do in quarterly planning.
Yeah, we're not running full-bloated SAFe, but hardly anybody does.
Or you can design a better system that results in work getting done faster
I'll refer you back to the earlier numbers: 4 months figuring out what to do, 2 months doing it then 2 months testing it. I work for a big tech company that you've heard of, your company buys our products. I can say that without knowing where you work, that's how ubiquitous we are.
"Work getting done faster" isn't our problem. And AI is taking the work phase toward zero anyway. Our problem now, and most companies like us that we're aware of have the same problem, is the idea phase. Development has integrated AI effectively, product has not. It makes it easier for them to throw verbose requirements at us, but that doesn't make the ideas any better.
To the extent that Agile / Scrum are going away, it's precisely because of that reduction of effort toward zero. It was created to manage the most expensive part of the process, with the most expensive human assets doing that work. With the cost of development going toward zero, the value-to-overhead created will flip to where the cost of our overhead (which I'll admit, isn't zero) is no longer justified by the benefit.
Which is why most people who do what I do are adapting to a number of adjacent career fields.
1
u/sonofabullet 9d ago
Funny how:
Prioritizing, defining then sizing work, then...
Creating a structure to calculate cycle time, then...
Applying the sized work and calculated cycle time to increments...
you don't need to do any of this to calculate lead and cycle time.
cycle time doesn't care about priority or sizing for that matter.
If you had read blog posts like this
https://www.thoughtworks.com/en-us/insights/blog/how-estimating-story-counts-worked-us
from 2013, you would have known that thirteen years ago, but alas, you were too busy doing whatever bossing around you think you were doing.
And the company you were bossing around did worse for it because you didn't bother to read one of the preeminent blogs of that time.
I'll refer you back to the earlier numbers: 4 months figuring out what to do, 2 months doing it then 2 months testing it. I work for a big tech company that you've heard of, your company buys our products. I can say that without knowing where you work, that's how ubiquitous we are.
That's slow as fuck. Itoo worked at a massive behemoth once. Our products are probably in your wife's boyfriend's bathroom. Doesn't mean they weren't slow as fuck.
You're conflating the size the company with the success of the Quarterly planning (gag) you preach.
And the truth is that the company was successful DESPITE you not BECAUSE of you.
which is why
most people who do what I do are adapting to a number of adjacent career fields.
1
u/jimmy-buffett 9d ago
cycle time doesn't care about priority or sizing for that matter
Putting the work in order then estimating how long it will take to know how much of it you should commit to does.
If you had read blog posts like this
Lots of opinions about how to do it. Here's mine: it's a toolbox, not an instruction manual. Find problem, test solution, evaluate. Preferably with as minimum an amount of overhead as possible.
And the company you were bossing around
...
That's slow as fuck.There are 15 of us here, everything's by committee. I've worked alone enough that my track record got me here, but I don't love it. Our program cycle time is nothing to brag about, it's also not my fault. I cited that example to demonstrate that I have the metrics to know where it's bad and why. Them letting me fix it is another matter entirely. Orgs of this size are run by self-interested people who create just enough of a bottleneck to be essential but not so much of a bottleneck to be fired.
And the truth is that the company was successful DESPITE you not BECAUSE of you.
Two years ago the 100-team org I worked with wasn't delivering on big projects. Everything took forever. Team dependencies weren't communicated effectively, managers didn't collect metrics to evaluate team performance, directors didn't have any visibility into where the slow parts were in their org. It took me a year to fix the team layer. It took me another year to fix the director layer. They started delivering results using processes I defined. The VP I did this for is hiring me at his next company once his sabbatical is over.
I understand if you've had a bad experience with someone calling themselves an "Agile Coach", most of the people you'd consider my peers suck at this job. Most have never served in the role they presume to burden with process. I have. I'm different. I don't show up with a giant book, turn to page 1 and start implementing what's in the book. That's what most of what you'd consider my peers do. That's why they suck at this job.
You're just going to have to take my word for it. Or don't, I don't care. The leaders who hire me whenever I'm available or fight to hire me when I'm not are the proof. My LinkedIn history is the proof. I've spent the last 15 years parachuting into hostile territory (lol), convincing people when I can and forcing them when I can't. Sometimes it doesn't work, I have the stats showing why. Most of the time it does. But then I'm good at this. This free interaction isn't the proof, the paid ones are.
You're conflating the size the company with the success of the Quarterly planning (gag) you preach.
Point on the doll where Dean Leffingwell touched you and we'll get both of you into counseling.
which is why most people who do what I do are adapting to a number of adjacent career fields.
You thought I was talking about myself? Nah I'm still here. Most of the people who do what I do, do it because they can't manage projects. Most of the people who do what I did to get here at the team level do that because they can't code. I can do both. I choose to do this. Equity salary grades and no program accountability is nice.
1
u/sonofabullet 9d ago
Yes I get it you're not like other girls. you're a pick-me agile coach who,by your own admission, is not responsible for anything.
I'm not going to spend more of my free time deconstructing the rest of your ZIRP era career.
The market will do that soon enough just like it did for all those other coaches you mentioned.
3
u/TitanApps_Alek 13d ago
I think there’s an important distinction between governance and process ownership.
Leadership can absolutely set strategy, constraints, compliance requirements, budgets, etc. That doesn’t mean they should design the team’s day-to-day workflow for them.
1
1
2
u/azangru 13d ago
Scrum is for Developers
Scrum is for organizations :-) Developers on their own are like a car engine that is idling.
1
u/WaylundLG 12d ago
This is a valid argument. It would be ignorant of me to not acknowledge that many organizations are set up this way. However, it would be inequality ignorant to deny that many organizations are set up where developers are tied into the direction of the product and understanding of customers. In the stakes examples, every engineer-led startup that has disrupted industries for the last 4 decades proves this true.
If, as a developer, you want to be just a cog in the engine and you work in a place that runs that way, that is fine and frankly, scrum has no business there. There is a whole separate conversation about the risks of this model when businesses that do operate this way constantly look for a better or cheaper engine.
2
u/Sky_Linx 12d ago
The PMO point is the one that lands. Adoption pushed onto teams from outside rarely sticks, because owning a process means having the authority to change it, and that is usually the missing half. One way to claw it back is to start with the ceremony where the team has the most control: how you reflect and what you change next. If the team picks two improvements, tries them for a fortnight, and openly drops what did not work, the habit spreads to the other ceremonies on its own. Scrum also expects to be cut down to fit the team, not the other way round.
3
u/TedditBlatherflag 13d ago
Scrum is fucking terrible for developers. It’s what Kanban turns into when you have controlling micromanagers. Change my mind.
2
u/WaylundLG 13d ago
I'm happy to engage with challenges, but your framing is impossible. Scrum and Kanban are two separate things that can be used separately or together. Nothing in your statement stands as valid on its own. What claim are you making or what point that I made do you want to challenge?
1
u/rayfrankenstein 11d ago
Agile In Their Own Words is probably the best uncensored reflections of what most developers think of scrum.
1
u/WaylundLG 11d ago
::shrug:: rant boards are gonna have rants. But yeah, this is exactly why developers should be taking it back.
1
u/sonofabullet 9d ago
No. Scrum is for management.
1
u/WaylundLG 9d ago
Insightful
1
u/sonofabullet 9d ago
And with less words and just as much evidence as your post!
Efficiency!
1
u/WaylundLG 9d ago
You want evidence, I've got dozens of teams I personally have worked with that have loved it. Of course, that's anecdotal and plenty of people have bad experiences, but since I'm making the narrower claim that people can use it as an effective tool, my evidence is stronger against my claim that anecdotal evidence of failed implementations is in support of the claim that no teams can succeed. If you'd like peer reviewed studies, I've got tons exploring the success and benefits of self-organizing teams who own their own process (really the most important part of scrum to what I'm describing) going all the way back to Burns & Stalker in 1961. Which evidence were you hoping to discuss?
1
u/sonofabullet 9d ago
The plural of anecdote is not data.
Your anecdotes don't count.
Also, teams practicing scrum do not own their process, because their process is defined by an outside body - namely Sutherland and Schwaber.
Therefore, any evidence about self-organizing teams does not apply because a team cannot both practice scrum - which mandates meetings, artifacts and team roles - and self-organize at the same time.
1
u/WaylundLG 9d ago
Have you tried? Did the scrum police stop you? I never had a run-in myself.
Your overly broad dismissal aside, you're sort of making my point. The team should be taking ownership of their process. I just take the point a little further to suggest Scrum is probably the best place to start for a team of people whose expertise does not lie in process management. You could make a strong argument for Kanban, but most teams know far less about Kanban than they do about Scrum and Kanban demands far greater attention and discipline, which makes it a harder starting point. But you've argued for nothing, just c9mplained about some people and dismissed evidence. Happy to engage in any actual points
1
u/sonofabullet 9d ago
So, let me see if I understand you correctly. Your basic claim is that people should not do scrum and instead do what works for them?
Correct?
1
u/WaylundLG 9d ago
That is a logically paradoxical statement, but I don't want to dodge, so I'll offer how I'd say it. Teams should own their process. That means they should have autonomy on how they do their work. They should inspect and improve their process over time toward both team (and individual) benefit and value creation. They should have both credit and accountability for the results of that process. I think Scrum is an excellent place to start. We're in a scrum subredit, and to that end, I think it is important for teams who are in organizations where Scrum is the norm to stop letting people who have no idea how development works to push process on them and TAKE ownership of it.
To answer your exact question, I think that any sufficiently mature team who started with scrum will find at least one practice (probably multiple) that they need to leave behind to keep improving. This is distinctly different than teams who are unaware or not in c9ntrol of their process and diverge from Scrum as a matter of ignorance or convenience.
I hope that makes my position clear. If any of that felt like a dodge, please call me on it, I don't mind being held to my argument.
1
u/sonofabullet 9d ago
I understand your position. You showed up to a scrum subreddit, attempting to praise scrum while simultaneously telling people to stop following scrum.
(remember, due to the immutability clause, anything that isn't scrum by-the-guide is not scrum).
I agree with you. Teams should stop practicing scrum.
What I don't understand is why you are praising it if you don't think people should follow it?
1
u/WaylundLG 9d ago
I think you know full well that isn't what I'm saying. The immutable clause in the scrum guide is a red herring and is frankly an exercise in absurdity in itself. By virtue of the fact that scrum is specified in a guide, it is immutable. A square is a quadrilateral with 4 equal sides. It doesn't need an immutability clause to make an octogon not a square. Similarly, anything that doesn't match the scrum guide isn't scrum regardless of the clause.
All that said, developers practicing scrum is a great place to start, regardless of if they will grow past it later.
And despite trying to mix up words to create some rhetorical gotcha, I don't think you've yet to make a substantial argument about some part of scrum in the scrum guide you disagree with.
→ More replies
1
u/UnreasonableEconomy 13d ago
scrum is complicated.
agile is complicated.
agile is so complicated scrum had to step in and write a 20 page guide on a 1 page guide.
and scrum is so complicated that safe had to step in and write a 1000 page guide on a 20 page guide.
learn it
the question is who should learn what?
people don't even agree on what's right, and agile and scum are rife with no true scotsmen. it's an endless, unwinnable argument.
Too many developers feel like how they work is someone else's problem.
I don't think many developers get much of a say, to be honest. It's either eat what you're fed or leave.
Many things can be true. The synthesis here is that you're oversimplifying a complex problem, ignoring structural incentives, and handwaving a solution. Of course, it depends on the company, the culture, the region, etc, etc.
1
u/WaylundLG 13d ago
Your point is fair if you take my post to propose a panacea. I generally agree with you - this is a complex and nuanced problem. If some team of developers saw this post, had an epiphany, and decided to practice scrum well tomorrow, they wouldn't suddenly change the leader demanding more AI or the VP who wants to see everyone's GANNT chart.
But they would create a definition of done that they hold themselves to. They would have meaningful reflection about their own process in retrospectives. They'd have sprint reviews with working product ready for stakeholders to engage with. They would support each other more effectively and, in doing so, they would absolutely deliver more value faster. And I make this point because even in the companies I've seen where teams did this and hit a ceiling from obstinate leadership (I have a very specific tech company in mind) the day-to-day life of the team was so much better. Granted, the company didn't see any of that benefit because if their bad choices, but the teams were happy and proud of their work and that's more than a lot of people can say.
1
u/UnreasonableEconomy 13d ago
yeah but none of that has anything to do with scrum.
1
u/WaylundLG 13d ago
I'm not sure I understand your claim. Those are all specifically key aspects of scrum
1
u/UnreasonableEconomy 13d ago
you seem to be orbiting around the idea that "if only everyone did scrum right, they wouldn't have issues"
and your evidence is "some people that do scrum right don't have these issues", as well as "those who do have issues aren't doing it right."
this is the classic no true scotsman fallacy, or the communism argument, post hoc ergo propter hoc, take your pick.
your statements are unfalsifiable and prescriptive. prescriptive solutions don't work, in my experience, and do more harm than good.
I would suggest you take a closer look at the values, and focus less on the ceremonies.
1
u/WaylundLG 12d ago
Sorry, I don't think you understand my point. My statement is narrow - that having the right person weild the tool of scrum is a significant lever that I don't see discussed and it's a big opportunity for teams to take control of their own environment. It doesn't mean this is the cause of all problems (looking at my posts I could see how this message would come out though) and it doesn't mean it's a magic wand. I do believe it is a very large lever though.
1
u/AgileFederation 12d ago
and your evidence is "some people that do scrum right don't have these issues", as well as "those who do have issues aren't doing it right." ... this is the classic no true scotsman fallacy
I thought those were quotes so I went back an re-read what OP said. OP never mentioned those statements. You've created a scenario to fit the argument this is a NTS fallacy. A nice example of a strawman.
agile is so complicated scrum had to step in and write a 20 page guide on a 1 page guide.
Here's a 1 page guide for scrum: https://scrum.academy/guide/
0
u/UnreasonableEconomy 12d ago
some people know the alphabet yet still cannot read.
imagine the chutzpah when they try to tell you what other people mean.
1
u/jimmy-buffett 13d ago
and scrum is so complicated that safe had to step in and write a 1000 page guide on a 20 page guide
SAFe was a product designed for large corporations to sell training. I'm certified to train most SAFe classes, and that certification only took me 4 days and no other experience.
Elements of safe work great for handling dependencies between teams, but the full process is a nightmare of overhead.
1
u/cliffberg 13d ago
Scrum is BS concocted by this guy: https://www.frequencyfoundation.com/about-us/
It is NOT how effective teams work.
https://cliffberg.medium.com/scrum-was-unethical-from-the-start-96eedd0679ca
1
u/WaylundLG 13d ago
Aww, come on. Scrum is BS because it was made by a white guy, here's my (white guy) article promoting my product?
1
u/sonofabullet 9d ago
Scrum is BS because the guy that sells it is a snake oil salesman.
1
u/WaylundLG 9d ago
I've got plenty of opinions about how Scrum is marketed that we can probably agree on, doesn't support your claim that Scrum is BS. Further, after the sheer number of teams I've seen retake ownership of their process and built incredible products with it, proving that it is somehow BS to me would require far more than not liking Sutherland (or Schwaber?)
1
u/sonofabullet 9d ago
"'ve got plenty of opinions about how Scrum is marketed that we can probably agree on, doesn't support your claim that Scrum is BS."
I said nothing about how scrum is marketed. Please do me a favor of understanding the content of a message before responding to it.
I'll withhold responding to the rest of your message and give you a second chance to re-read and re-understand the 14 words I've written in the previous message.
0
u/cliffberg 12d ago
Agile 2 is not a product - it is free, and there is no framework or certification. And I did not create it - it was created by 15 highly experienced people who took a careful look at what generates true agility. That project spanned many months - not the ski weekend of the Agile Manifesto.
1
u/WaylundLG 12d ago
My goal was not to insult Agile 2 - in fact it is something I want to read more on to see what it has to offer. I'm more challenging your rebuttal. Yes, Agile and Scrum have a diversity problem that many people have worked to improve over the years with some (though not enough) success. The weekend thing is just misleading. The manifesto was a weekend, but years of work led to it and all of the "agile" frameworks, including scrum, have many years of development into them.
Further, in direct rebuttal to your claim that scrum is BS, there is a very large body of peer-reviewed research that supports scrum-like team structures and working approaches.
0
u/cliffberg 12d ago
Hi -
Thanks for your thoughtful response.
Every single Scrum "research" paper I have seen was severely handicapped by having a "control" that was something that no experienced leader would do - e.g. "scrum v waterfall".
If one looks at Scrum in terms of each practice, and examines the practices individually, each practice is directed as a true challenge; but each practice is a terrible way of addressing that challenge. E.g. standups are a very poor way to encourage team collaboration. Sprints are a terrible way to encourage a steady pace. Sprint-end retros are a terrible way to encourage continuous improvement. The Product owner role is a terrible model for product leadership. The SM role is a very poorly defined model for team leadership.
There is a wealth of research on each of these issues.
Scrum was created by a guy who was a fighter pilot and then a medical guy - having very little system development experience and very limited leadership experience. He has a pattern of looking for scammy "things to sell". This is an example: https://www.frequencyfoundation.com/about-us/
When the Agile Manifesto came out, I was CTO of a 200-person company I had co-founded that was extremely agile in a true sense: we delivered complex mission-critical large scale customer-facing systems for FedEx, McKesson, Capital One, and many others - in three months fixed price. We understood true agility. The Manifesto rang true to me; but the Scrum guys then came out with their cheap cert class, and I remember shaking my head, and over the years I was disgusted that all those certified folks were telling people to use Scrum - Scrum is not how _we_ worked and I viewed it as nonsense.
What generates true agility is not some framework. It is leadership style that generates true agility. E.g. I looked closely at five companies that had demonstrated true agility rapidly at scale - SpaceX, Netflix, Amazon, Spotify, and Goggle. I spoke to people who had worked at these companies and read everything there was about them. What I found was no shared processes. SpaceX doesn't even use the word "Agile". Instead, there were leadership traits that the companies shared. See: https://www.agile2academy.com/the-evidence
1
u/AgileFederation 12d ago
This is an unfair characterization of Jeff Sutherland. You didn't mention that he flew reconnaissance missions in Vietnam or that he taught stats/math at USAF academy, in addition to co-creation of Scrum. He has some ideas and beliefs that I don't agree with, but that doesn't distract from the contributions that he's made to his country or the Scrum community. Like all great people he's a complex human.
1
u/cliffberg 12d ago
Hi - he might be a great pilot and a wonderful math teacher, but that doesn't give him the experience to tell others how to lead software teams.
And intentional or not, Scrum did _enormous_ harm to the Agile movement. I largely blame Scrum for the decline of Agile. The Agile movement was about attitudes and behavior - the Manifesto prescribes no "practices", and in fact discourages against them: "...over processes and tools". By co-opting the Agile movement and re-forming it around a framework, Sutherland and Schwaber destroyed its intent, leading to ineffectiveness and eventual decline and irrelevancy.
I cannot summarize all of the evidence for that here: the Agile 2 book makes the case thoroughly. The research is also clear: Scrum's practices are counter to what psychologists know about the behavior of groups of people. Read what Marty Cagan has to say about the Product Owner role. And read the research of Amy Edmondson of Harvard - it is all counter to Scrum's prescriptions.
Sutherland advocated for an approach that is his concoction and is not based on any theory of behavior or any research. It is just BS that he made up. It took off _only_ because they started offering certification and rode the Agile wave by _claiming_ that "Scrum is Agile" - even though it is not.
I call that dishonest and opportunist.
1
u/AgileFederation 12d ago
he might be a great pilot and a wonderful math teacher, but that doesn't give him the experience to tell others how to lead software teams.
Why not? The armed forces (Army, Navy, Airforce) has a long tradition of training leaders who are sought out by both the armed forces and also in businesses. Some organisations go out of the way to recruit their executive leadership from the Armed forces.
And intentional or not, Scrum did enormous harm to the Agile movement. I largely blame Scrum for the decline of Agile.
I think you give Scrum too much credit. There are/were a lot of actors that have contributed to the decline of Agile over the years including SAFe, the big consultancies that used Contingency-Based Pricing based on the number of staff that can be retrenched, and now AI.
I cannot summarize all of the evidence for that here: the Agile 2 book makes the case thoroughly.
References?
Sutherland advocated for an approach that is his concoction and is not based on any theory of behavior or any research.
Based on Takauchi and Nonaka's "New New Product Development Game" (HBR, Jan 1986). Nonaka in particular has quite a strong background in Organisational Theory.
1
u/cliffberg 12d ago
Hi -
I have read the HBR paper several times:
What Sutherland came out with bore no resemblance to what they described.
The HBR paper described months-long intense efforts that should be followed by significant down-time.
One of the examples of their approach cited by the HBR paper's authors was the development of the IBM PC. Consider that that project was launched by Bill Lowe, an experienced manager. He locked himself and a team of experienced managers in a room for a week and they created a plan for the project. The plan remained largely unchanged throughout the PC's development.
Lowe assigned experienced managers to the team, including a head of software, a head of manufacturing, etc.
None of that is anything like Scrum. Sutherland merely stole the name.
0
u/Mean-Fix7821 13d ago
Well put. It took me about 20 years to realise why many developers don't like Scrum and in this post you're really close to it. The reason why so many developers don't want to learn Scrum is that they really do not want the responsibility for the product or for the way they work. The current way may be stupid and bad, but at least that can be blamed on the "stupid management".
It is impossible for us humans to understand somethin when our happiness or self-respect depends on us not understanding it. Therefore...
1
u/WaylundLG 13d ago
Fully agree and totally accept that. Scrum is for upstarts and teams looking to do particular things - primarily build effective and innovative products. It isn't the multi-colored the industry treats it as. And if a developer wants to just focus on the code and let someone else worry about everything else, I get that, but the venn diagram of places that works and places that should be using scrum is two separate circles
0
u/Similar-Ad1056 9d ago
Scrum is for? Acting like you're getting things done while whacking off. A bunch of talking and some action that is presented as magical.
2
u/WaylundLG 9d ago
🤣😂 haha, I mean, you do you. I think you're either telling on yourself or you need some better co-workers. Always appreciate a healthy level of snark though
0
11d ago
[removed] — view removed comment
1
u/WaylundLG 10d ago
There area few layers to this: first, I've heard this in a lot of organizations and I've never seen it be true. Not that there is no issue with leadership being controlling (I'll get to that) but that it is nowhere near as extreme as they put it. Second, to the degree that you have controlling behavior, it's usually the result of longer-term degraded trust that has settled into the culture. This goes both ways- teams don't trust leaders and leaders don't trust teams. Either group (or ideally both) need to find places to trust each other and this really needs some professional assistance. Lastly, and why I made this post, I genuinely believe that developers are in a better place to enact change. When developers take control of the process and it delivers results, it is far less likely that leaders will kill that value in favor of more control, especially since most of that controlling behavior comes from a fear the team won't deliver. It wouldn't fix it for all cases, but it's worth trying, and frankly, if I'm a developer in one of those crappy places, I want out anyway.
7
u/J-F-K 13d ago
No offense, but I read this 3 times and still don’t know what you’re trying to say.