21–30 of 121 posts
My problems with it start around the time when I'm being impeded from the actual work. Justifying the hurdles I've anticipated or bike-shedding on the cover sheets
When I first started coding professionally, I thought sprints were stupid. We've got a backlog that will easily take us a year to complete. Why bother with organizing them into 2-week sections? Why not just finish a ticket, take the next one off the pile, and start working? Over time, I learned that time-boxing your work creates short-term goals, a slight sense of urgency, and some accountability. Otherwise, it's eas…
> "It is a 2 point story, why have you taken three weeks to complete it?"
After over a decade of this, I'm convinced "agile" (scrum, really) was created to provide more jobs for product managers and create fluff roles like "agile coach." It may have more value for less experienced teams. More experienced developers will become frustrated by the ceremonial nonsense. I prefer the kanban style.
If a few adjacent roles get invented for a friend so be it, why spoil the party over a few implementation details?
That being said, my experience is that most teams start off being strict about sprint planning and boundaries, but over time back off more and more until sprints are a very abstract planning/check in every two weeks, which is fine.
Just personal experience, YMMV.
In a highly interrupted team, sprints don't work. Try lean/Kanban.
You've not mentioned retrospectives, which are an important part of improving your processes, without that how can you make improvements?
There's nothing in agile that talks about deadlines, it's about commitment.
I don’t think it’s useful to have a very rigorous planning process, or be persnickety about things finishing within the sprint vs. 2-3 days carryover. I particularly hate the rituals designed to reduce autonomy, like PMs managing backlog priority or story points poker exercises. On my team engineers are responsible for their projects and the sprints are just periodic check-ins where you say what you have been doing and what’s next.
Scrum is a fine default for any software engineering team working on app/website-style engineering projects. But if their process never veers away from default Scrum, they're probably not a very good team. I've discovered that good teams are fearless about retros. They take suggestions seriously If they're unwilling to try new things, they're always going to underperform teams that experiment with process, and keep the good and reject the bad.
Scrum (and similar processes) makes every engineering team move at roughly the same speed. This is good news if you have a poor-to-medium quality team and is frustrating if your team would be speedy without the process. Teams that don't adapt the process to themselves and their companies are always gonna feel like they're stuck in the mud.
Breaking up work in manageable chunks absolutely makes sense. It makes it easier to monitor progress as a manager, and gives a sense of achievement for a developer. However, the rest of Agile deserves a special circle in hell.
But this isn't unique to agile. it's basically how all objectives since the 50's have been organised.
These methodologies are designed to be a "good enough" default way for non-technical managers to organize and manage projects in a domain they don't really understand.
Imagine how confusing going to the mechanic is when you don't really understand cars. You're constantly left wondering if he's bull-shitting you about the cost and effort involved in a repair and if any progress is being made and work is actually being performed. So I get why this needs to exist, but I understand that it's not about benefiting the developer.
By far the most productive teams I've worked with have been on six week iterations, with an at least approximate idea of what they're supposed to achieve in the next 90 days. One week out of that six is basically given over to demo, retro, and working out what the next one should achieve, but there is enough slack in there to accommodate the inevitable ups and downs, which two week Agile/Scrum pretends is not a thing. The lead developer is almost entirely focused on integrating the work of the others, and building strategy for the next iteration with product/marketing and the other team leads.
The other incredible tendency of highly productive teams is a lack of communication . . . because they don't need it. It may be more accurate to class this as a lack of noise, and clarity over what needs delivering. (i.e. product and the leads have done their job). I used to have to visit different teams in many locations, and you could tell how productive they were just by how quiet it was, interrupted only with the occasional "Dave, you broke the build!"