Having been a manager, PM, and lead engineer this article really resonated with me. Scrum has a brief window of utility if a team isn’t delivering at all, and has lost management trust. It also has a large window of dis-utility where everyone haggles over points, shows velocity as results, and leaves customers and businesses wondering what their engineers are doing. Trust your engineers to do the right thing on their own and they might just surprise you.
I agree 100%.
Thankfully I don’t do agile any more, but I’m close to several teams that do. My fondest memories are:
No over-arching design (Implement feature after feature however the hell anyone likes) Once said features are implemented, taking the time to “refactor” (read: completely rewrite because the code was so bad) becomes a really hard sell.
Thus, new features get progressively harder to implement, as you touch a deeper cross-section of the code to try and fix stuff semi-covertly, without a formal refactor.
“Tech Debt” was done in sprint scheduled after phase of dev sprints. After, say, a year of development, lets fix all the problems in 3 weeks… When you’re dealing with procedural php masquerading as OO, MVC with business logic everywhere it shouldnt be, and abuse of inheritance such that you cant throw an error in a command line because you’re not a logged in browser user, who’s had their language queried from a database, and doesnt fall back to default when the db isnt there… 3 weeks isnt gonna cut it!
Introducing peer review was supposed to sort that, but bad or inexperienced devs didnt know they were doing shoddy work (it met the criteria after all..), and good devs became impediments because so many stories needed redoing. Demoralising.
We were probably “doing agile wrong”. But it’s like a religion: open to interpretation. In my experience it’s a tool used to extract maximum customer benefit at the expense of the developer’s soul, under the pretence of “self managing team” – ie. “You brought it on yourself”.
I’ve found that “certificated scrum masters”, “certificated project managers” and their ilk are the problem. Anyone who says we must follow a specific process because that is how agile development is done is missing the point.
The actual agile manifesto makes a lot of sense IMO.
The Agile movement was all about dropping the process hoop jumping and focusing on solving problems efficiently, that’s why it was considered extreme. Too extreme, as the one true implementation to rule them all is worse than what the agile movement was revolting against. This is how the game is played, over and over and over again; any movement that threatens the narrative is embraced, corrupted and ultimately used as a weapon against its core values.
I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is “Individuals and interactions over processes and tools” and these days practicing agile, at least in a big-house corporate environment feels like anything but.
The Agile Manifesto suffers from “the curse of knowledge”: The signatories are all very experienced, and deeply understand all of the differences between projects and people and when to be flexible and when to be rigid, and they know that it’s important to not specify a method for every situation. But there are many, many people entering the software industry who don’t have their years of experience, and who need very clear, basic instructions as a starting point, and hence Scrum steps in to fill the gap. What’s unfortunate is that scrum isn’t a program for developing software managers from rigid, by-the-book managers into experienced, agile managers: Instead it encourages newbie practices for everyone, forever.
My team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team together and discuss it. When we see that there needs to be architectual discussions and high level planning, we do it immediately when we recognize the need for it. The idea that you can try and commit to or even forecast how much can be completed for a period of time is pretty absurd. Just identify the minimum requirements of what needs to be done and do it. Retrospective is still productive. But sprint planning is a waste of time IMO.
Everyone thinks Agile means fast, the word fast does not appear in the Agile manifesto!
Now here you all are, you’re probably on a Scrum team, you’ve been doing this a million times and you don’t know what you’re doing! Because you’re getting information from this booth upstairs, they’re selling Scrum. These conferences are doing unfathomable damage. Because there’s no authoritativeness behind the talks, no-one going back to the source, no explanation of why stuff works, just recipes, and it’s infected the entire industry and driven both Agile and Object Orientation into the ground.
What percentage of its Sprints should a great Scrum team fail? The answer is 50%. It’s pure math, if you understand how velocity works and you understand variance you had better be failing 50% of your sprints. If you’re failing more you suck, if you fail less you’re hiding something, you’re cheating, you’re lying, you’re cooking the books. This is simple math!