61–70 of 462 posts
nobody has ever done "waterfall", it's a strawman created to explain why traditional project management doesn't work in software development. The fact that the article starts with "in the good old days of waterfall" takes away every expectation that I'll read anything intelligent in the article, I believe this post doesn't deserve your time and definitely doesn't deserve mine.
I've learned to hate software process. If you have team sizes set sanely and empower devs to do what they need to do in order to accomplish the goal, they'll be fine without the management overhead of arbitrarily imposed productivity flow. Agile et al, along with 99% of the features in ticketing systems, exist to make managers feel like they are justifying their paycheck. If you are a manager and this makes you angry…
But what does it mean to "empower devs". Do you give them requirements and say I'll check in on deadline day in 6 months? Presumably you would still use iterations to track progress, Epics/Features to break down requirements, some kind of estimation to track if you're ahead/behind schedule? I certainly wouldn't go back to Waterfall days, but I suspect many current devs never experienced that.
- Issue tracking as a common place to describe what needs to be done and thoughts / details on how it is solved. Something lightweight like Trello is ideal
- A Kanban board so people have an organised way to pick up new issues when low on work
- A weekly showoff meeting where there are few 5 minute presentations and a 30 minute "I did something really cool or learned something really cool"
- 6 month task split into 1 month ish deliverables, with a flexible deadline for each. Presentation of finished work each deliverable.
The secret purpose of Scrum is to get rid of managers and empower the engineering team. Most "scrum" is simply taught wrong because it was sold to companies as a way to squeeze workers.
Team: "We are having trouble with Bob." Manager: "Ok I'll talk to him."
Team:"We are having trouble with Bob." Manager: "Don't come to me, you guys need to deal with that in your retro."
Team: "We voted Bob off the island." Manager: 'Ok, I'll forward to HR."
Autonomous teams get more done because they have eliminated management as a wait state and will proactively scale with other autonomous teams to maximize the amount of work not done. 21st century managers need to re-focus on flow efficiencies (as business engineers), and not people. 20th century managers won't have a job in 5 years.
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this…
In the agile teams I've been on it's been to produce success. Getting good and useful software fast.
Of course, just like there are hundreds of wildly different Christian sub-religions, there are now any number of "agile" interpretations. In the end belief systems can be pushed to do most anything you want.
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this…
If people are judgemental around what stories are left uncompleted or points / week then the situation can become stressful for no benefit to anyone.
You're supposed to have autonomous teams who put up their own tasks they want to complete in the sprint, and the sprint length can be more than 2 weeks if the team wants. And if it's tight to get the scrum's tasks done, that's supposed to be feedback to you and the team. You have autonomy in setting sprint goals, you can put less stuff on a sprint so you have the slack you're supposed to between sprints. Or spend more effort refining so you don't get surprises so often. (Or otherwise change things up in how you work)
If you don't have the autonomy and the continuous improvement in your work culture, it's not agile. Scrum is for agile and it doesn't work otherwise. If you do have autonomy you can switch to something else from scrum if you want.
Same goes for the "scrumfall" part of course but that's admitted in the text already.
(I do think scrum is overengineered for agile ideals, has failure modes like in the post, and in 95% of cases you should do something lighter than scrum)
Earlier quoted context omitted.
Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. Sprints themselves which promise that a certain amount of work will always get done, without any free time being wasted. A lot of the ceremonies in general are mostly helpful to the EM/PM. How many things that you're doing are actually improving how you get work done? Especially when you consider how much time is spent…
> Daily stand-ups, the main benefit of which is that managers (EMs/PMs) get daily updates on status. The scrum guide fairly explicitly states that managers should not attend or be part of stand-ups unless they're actively involved in the work as part of the development team.
I’ve been building software applications for 40 years. No matter how you slice up the work, we all have to demonstrate progress and goal achievement. Agile, Scrum, Kanban, Method 1, or whatever are all meant to measure success. In a lot of cases there is a client or a customer that requires regular progress reports. Management uses reports to measure team performance. I’m not sure what planet the OP is from, but this…
Maybe having "easy" sprints would work?
There are benefits too, just that constant grind aspect is why I believe it's mostly a temporary endeavor. After 6-12 months most teams seem to just do something else then come back to it once a new manager joins.