I personally strongly dislike a lot of aspects in SCRUM (individual commitments stick out especially, together with the entire role of Scrum Master), but am not sure I see an alternative for some form of agile (without the TM), that is adjusted to the individual team's needs, for the vast majority of teams. Whenever I read these criticisms, a lot of it rings true, but I fail to understand what the alternatives looks like besides Waterfall or chaos. Whoever does these write-ups always complains about some Agile™ thing, but takes the alternative for granted. What activities and meetings would be dropped or replaces and by what? It's not very meaningful to criticize something when comparing it to nothing.
> but I fail to understand what the alternatives looks like besides Waterfall or chaos.
What I've seen pretty much my entire career (early 80's) for projects is just a straightforward process of up some front planning, phased design+dev, management of tasks through a regular (weekly or twice weekly) low overhead process (what's ready for next step, where are challenges), etc.
The key is having an experienced technical leader to guide the process. Typically, PM's don't have enough detailed technical experience to really understand how to make this stuff work.
My biggest pet peeves are (a) when mature software or mature organizations pretend they are a three person startup and refuse to document anything and have meetings all day (b) when product owners say f the existing architecture or tech debt and literally tell you to rip out everything and install a new tech stack because it is agile.
These morons know nothing and bark out orders based on their agile bonafides which is nothing more than snake oil. A magical cure all irrespective of the problem you are trying to solve.
Which is another flavor of Agile which is what everyone is always complaining about. I'd take some form of Kanban any day over doing rigid Scrum by the book. Kanban needs a lot very similar meetings though. You still need to fill the backlog, discuss the tickets. If you were to do Kanban by the book as described by the Agile Alliance, you'd still do standups, retro under a different name etc.
In my experience people complain about strict processes that books or consultants say must be followed. I've rarely heard someone complain about the content of the agile manifesto. So start with what you've got, and iteratively keep what works and chuck what doesn't, until you have a process that works.
I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
> I'll add that kanban means much less time filling a backlog, to the point that an individual can own that, and you're eliminating that meeting.
I've only ever been on projects where the backlog was filled by a PM and or lead engineer and then reviewed collectively and maybe some amount of re-shuffling would take place. Are you saying you've been in meetings where the backlog started empty and it was populate with the entire team in the room?
I've never seen an empty backlog, but I've been in meetings the purpose of which is for an entire team to rubberstamp the order of the backlog. This is "grooming" or more recently "backlog refinement". You don't need to do this in kanban.
Don't you need to go over newly added tickets and ensure the tickets are clear, order makes sense, etc? Whenever we've skipped this some issues would emerge when tickets get picked up later. Depending on the project domain and if a PM or engineering lead wrote the tickets the issues would be either more about technical issues or misunderstanding of business requirements.
> I've never seen an empty backlog
How about a backlog with stuff near the top that's no longer relevant or has drastically dropped in importance?
Tickets are often written imperfectly but that doesn't necessitate a standing meeting for the whole team imo. Make your pm and em hash them out, make the most informed engineer write the ticket, but don't make everybody watch.
If the top of your backlog is uselessly stale, you're spending too much time writing tickets in the distant past and not enough recently (or maybe congrats on your velocity?). A ticket that's so old it needs to be overhauled to be worked on was written prematurely. This is one of the things kanban is good at.
Edit to add: a team that's heavily reliant on a PM might not be a great fit for kanban? It's not for all teams, and is a natural fit for some
What you are describing is entirely reasonable, but again still a lightweight Agile process. The thing that I don't understand is what the people want who keep complaining about all Agile, not just (rigid) Scrum in particular. I've worked with XP, Scrum, Kanban and versions of those adjusted to particular teams and companies. If someone doesn't want any Agile and doesn't want Waterfall, wtf do they want?
How do you refine features? How do you discuss team improvement measures? How does prioritization happen if you're working on a product?
The answer might be simple for small teams, but a lot more complex for larger teams, where the result might look eerily close to Scrum. One difference would be that meetings will take place infrequently and only "as needed", where I wouldn't trust most teams to recognize their needs.
I'm really curious about this question, are you thinking that not having Scrum makes it's harder to refine features?
I'm trying to understand what assumptions you are making, because I've never worked in a Scrum environment, but have always refined features as part of the natural flow.
> have always refined features as part of the natural flow.
"natural" as in "law of nature"? Or is it just a process which crystallized in the course of your career as something which makes sense to do?
Scrum, and other methodologies are mostly a collection of such processes which proved to be useful, are somewhat standardized for learning and communication.
One can reinvent many of the Scrum processes independently, but I kinda don't see the point. Just like I'd rather use a finished library / framework rather than try to hack together my own.
No, but I believe that whatever you're doing resembles what is done in scrum. Gather information, discuss with your colleagues, create a plan. Scrum enforces that colleagues talk to each other, which I learned is not always the case.
