Agile Scrum is composed of many assumptions and rituals that don't apply to most software developers or their teams. Scrum has become the standard process for organizing development mostly because it makes great promises. However, only certain situations will actually deliver on those promises.

Agile Scrum Promises simplified:

The business decision makers are promised:

• Planning and schedule predictability
• Increased output and visibility from developers

The developer is promised:

• A continuous sustainable pace (ie. good work life balance)
• More innovation, learning opportunities and rapid change
• Increased morale

Does Agile Scrum deliver on these promises?

Rarely, in my experience and observations. I was fully sold on Agile Scrum in 2013 when an external company came and trained most of my company over a 3 day period. Since then I have been a part of and witnessed team after team falling into the productivity decline of "Storming, Forming, Norming" that Scrum adopters are warned about but have not witnessed any team come out the other side of "performing" with great productivity.

Why has Agile Scrum failed?

Assumptions. Agile Scrum makes many assumptions of a team's shape and composition that have rarely been correct. These assumptions are not posted anywhere to my knowledge but seem to be in between the lines.

Assumptions:

• All team members are equally capable of doing and estimating all team work
  • Developers can become experts about everything technical
  • Developers have some authority in technology and commitments

Agile Scrum asks each and every developer to weigh in on task complexity for estimation purposes even though most developers gravitate towards a certain domain area or technical stack area and others are clueless about it. Ideally it would be nice if each developer could contribute well in each area but in my experience that just doesn't happen.

• Development and business have equal priority decision authority
  • Development team must have a large quantity of reserved capacity for non feature tasks

Normally, business feature requests consume the entire development team workload. A business area wants a massive workload of epic tasks done in a quarter that they trim that down to about 10% of the tasks to ask the development team. Likewise, the development team should have their own massive workload of automating things and technical debt that is then trimmed down to the most important 10%. Well, what happens next? The business team explains that their 10% tasks are business critical and the development team complains that they would be stretched to do half of the request work. The development team's requested workload is forgotten, technical debt is layered with more technical debt and team productivity and morale is broken.

• A team shares authority and responsibility equally

An individual developer is no longer responsible for almost anything in Scrum, everything is the team's responsibility. In theory it sounds like a great new union has formed but in practice I have often seen that leads to developers' motives changing to hit their story (imaginary) point numbers instead of delivering value to the customer. The developers who are highly invested in their product and customer are often viewed the same as everyone else on the team.

When scrum gets ugly

At its worst I have seen scrum practices used for non productive intentions. I have seen Scrum be used as a means of micromanagement so a leader can be in everybody's business and determine how they work and should think. I have seen multi-day sprint ritual meetings that ignore immediate customers' needs. I have seen Agile Scrum be subverted for someone to take leadership authority in order to get control of projects and their technical decisions. Instead of a technical lead working with interested parties a scrum master will step in to talk about MVP (minimum viable product) and tell everyone to prioritize creating technical debt. Of course these aren't always the case but I have seen this and more multiple times in the past 8 years.

The Rituals

Lastly, Agile Scrum preaches a lot of meetings. Daily Standup, Backlog Grooming, Sprint Planning, Sprint Review, and Retrospective. Most of the meetings are about planning work and staying in sync with the rest of the team. This sounds really good on the surface but for most developers it really doesn't matter what a different group of developers are doing and it is more time wasted in meetings.

If not Agile Scrum then what?

I don't know. Personally I liked Kanban's simplicity, prioritizing tasks and getting them done. There are trade offs with each option but Agile Scrum seems to be on a Corporate Bible. Hopefully more businesses can start thinking of better options.

Conclusion

I don't actually hate scrum, in fact I am part of it every day and my team does a good job making it as lean and quick as possible. I do hate that scrum is the only choice in corporate software environments these days. I personally value the freedom of development choices and ownership of responsibility over the ritualistic meetings and all developers are equal mentality that Agile Scrum promotes. I have yet to see an Agile Scrum team leave their "Storming, Forming, Norming" productivity dip in 8 years and I hope we can find better solutions in the future.

All my posts are based off my personal experience and I would like to hear if you have had a different experience or comments

Thank you for reading! My blog: corpcoder.dev