How big tech runs tech projects and the curious absence of Scrum

SAFe is beautiful in that it is the ultimate expression of Enterprise Agile Cargoculting: all pretenses of agility are lost, there are ten different levels of decision making, and all responsibility is diffused in a confused mess of worker bees running around under an all-powerful and all-seeing LPM

> Individual teams can use whatever they want to manage themselves (Kanban, Lean, Scrum, etc…up to the team)

Except that they can't, because they will need to align on PI dates based on sprint durations, publish their burndown statistics and various other measures, and there's no way the poor soul who is reponsible for collating that will go into several different tools

> Estimations planning and commitments for each quarter are done by developers exclusively, including coordinating across teams

No they're not, they're done by the product owners, the system architects, the release train engineers (shhh... don't call them project managers), the product managers etc

> Releases can happen at any point

In my experience, releases can only happen at the end of a program increment, or maybe at the end of each sprint because until then nobody has integrated everything together

> A strong and continuously improving CI/CD pipeline is an expectation.

Fair enough, until the "innovation sprint" becomes the "bugfix spring" and all those good resolutions fly out of the window

> I really wish more people knew about SAFe.

So do I, just like I wish more people knew about colorectal cancer

> It’s constantly improving and refining the experience and from what I have seen, if there is a better way to do things SAFe will become it.

SAFe is constantly evolving, because that's the easiest way to keep the money coming in. It's as if PADI had found a way to change diving equipment every 2 years and ask everyone to recertify

Sorry for the tone, but I still have PTSD

I worked at a big tech for many years and my team never managed to get Scrum working properly. Every year my team commits a delivering certain product/features at a very specific date (some sort of launch event), so we have to know very early in the year what's all the work required and report periodically whether project is on track. The deadlines are also always on the tighter end. The flexibility of Scrum becomes an issue in that case, because not everyone can deliver the same tasks at the same speed and without careful planning you can easily miss important deadlines.

I suspect the prescriptivism and detail have one end goal and that is for someone that has no idea how software is done to follow the procedures. It also turns the process into an "almost predictable process" for the higher-ups to see turned into a graph in some ppt. You also have to deal with people who needs to be told which shoe to put in first before they think the process is "confusing".

Same reason for PMP, it's to turn the procedure into "paint by numbers". Of course it rarely works that easily.

But of course you can't justify the multiple middle-managers and why can't the people at the bottom just "turn the wheel faster" without it so there's a bit of purpose in that.

I think the core observation that teams are best allowed to adapt to their own situation is a good one. One thing I want to take on though is this:

> “Kitchen sink teams” which have everything thrown at them, typically find that managing stakeholders with a heavyweight process like Scrum is a win. Stakeholders are educated to understand that an ongoing sprint cannot be interrupted and that new feature requests need to be groomed.

I have repeatedly see teams that run like this fail. They're happy in their own right, they've got their process, they get what is in front of them done, but the process makes them entirely unable (actually more often just unwilling) to respond to urgent issues or adapt to a changing environment.

It's absolutely great for a team that has a large number of external stakeholders with diverse needs to be able to point at some process and say "Oh well here's the process we follow, here's what you need to do". But in reality what they're saying is "We're entirely unable to respond to the actual requirements of our stakeholders, so instead we've decided there are only a subset of requirements we're going to fulfill" and anything outside those requirements you just have to work around the team. It very often also works to provide barriers between the stakeholder and the engineer, so by the time they tackle they're either doing the wrong thing, or it's no longer needed or they fail to actually deliver it to the stakeholder. It's a great system to build a well functioning team that entirely fails to deliver what the larger organisation needs. /rant over I guess

Scrum is like a global variable or a goto statement. If used carefully it could provide benefit but is often thought negatively. Used by untrained or junior team members and projects spiral. Senior members shy away because of experience.