I don’t think it does unless you take a dim view of it and perpetuate the simplistic scrum-agile bad meme.
An easy way to throw an effective team into disarray in tech is to waylay it with back channel requests and unplanned work. If you’re too busy fighting fires and working personal errands for disruptive managers and executives then you’re not delivering what your team is supposed to deliver.
The ‘proper channel’ isn’t a bureaucracy as described in the SSFM, it’s simply an ordered list of priorities with a gatekeeper.
Edit: as far as dogmatically adhering to this process goes, then any effective agile/scrum process will have a baked in allowance to handle the unexpected or adapt to change, rather than stubbornly stay the course.
> I don’t think it does unless you take a dim view of it and perpetuate the simplistic scrum-agile bad meme.
Look, the thing is, if you've worked in a load of different organisations, and lots of different teams, with other smart people and have never really seen Scrum done well, and have in some cases actively seen it inhibit the delivery of quality software, I think it's legitimate to start questioning the process. People - smart people - struggle to make it work effectively. Plus, 50% of software developers (UX, product management, QA, SRE, stakeholders, etc.) are worse than average: a process that top quartile people struggle to make work well, sometimes even under the most favourable of circumstances, is less valuable when broadly applied across the delivery professions as a whole, and over different industry sectors.
On the flip side, with any process being introduced, I think it's fair to spend some time, maybe 6 months (but it will vary, depending on the process), implementing that process fairly strictly. It does need time to bed in, and there will be areas of friction simply due to creating new habits or resistance to change rather than due to problems with the process during that time. You need time for those issues to shake out so that you can see how much value the process itself really delivers and where it can be improved. At the 6 month point you can review the process, implement improvements, and move forward. You can keep doing the same review/evolve process on whatever cycle you choose, and that way your processes are more in step with changes in the wider organisation (hopefully growth).
Your processes need to fit your organisation, your business model, your culture. So, by all means, you can start with a process like Scrum, but to be really successful with it you need to treat it as just that: a starting point. You need to evolve it to fit your business. We all like to mock cargo-culting and yet, somehow, Scrum and agile often seem to blag a free pass. I don't understand why, because they shouldn't get that free pass. Your processes need to work for your business, and they are always a means for delivering value and never an end in themselves.
Scrum as a concept doesn't matter. Agile as a thing doesn't matter. Team structure doesn't matter.
All that matters is who has authority and the business both enforcing that authority and also making sure that authority is being used to accomplish business efficiently and not causing greater risk in the process. The rest just falls in to place. Or doesn't, and the business dies.
Yeah that’s a totally fair point, and one I took as given because it’s hard to discuss something like this if you need a disclaimer on facilitating organisational change every time the topic comes up. After explaining for years that no, doing agile doesn’t mean daily status reports and endless meetings, you start to consider that maybe these arguments are offered in poor faith and you want to focus on the good faith nuance.
Ironically, you can sabotage any attempt to apply some useful agile (or scrum) principles in earnest simply by trotting out a few strawman arguments against it.
I would also add that, in my experience, anyone who is involved with and doesn't buy into the process (any process, not just Scrum) will be indistinguishable from a purposeful sabateur.
On the cargo culting point. I just want to add. You can actually get pretty far by apeing what you've seen before even if you don't totally understand. You should definitely try and understand and figure out why it works but you can still get by without it sometimes.
This is all true. No one should dogmatically follow Scrum or any other framework. But the trouble is there's two kinds of people who deviate from it. Those who actually know what they're doing and can move beyond it, and those who are scared of or threatened by a new normal and want to kneecap it.
If an aspect of Scrum is inhibiting flow . . . junk it. But also first make sure that it actually IS inhibiting you, and it's not just highlighting a weakness or cultural flaw in your organization that you'd rather not deal with and pretend doesn't exist. Step 1 in moving beyond Scrum is to acknowledge the elephants in the room, feed them a peanut, and decide how to efficiently house them somewhere else.
An easy way to throw an effective team into disarray in tech is to waylay it with back channel requests and unplanned work. If you’re too busy fighting fires and working personal errands for disruptive managers and executives then you’re not delivering what your team is supposed to deliver.
The ‘proper channel’ isn’t a bureaucracy as described in the SSFM, it’s simply an ordered list of priorities with a gatekeeper.
Edit: as far as dogmatically adhering to this process goes, then any effective agile/scrum process will have a baked in allowance to handle the unexpected or adapt to change, rather than stubbornly stay the course.