Comments by "" (@defeqel6537) on "Agile Uncertified | Philosophy Over Rituals" video.

Sounds, sadly, quite familiar. Also, claims of doing Agile, but still micro-managing the teams WHILE pushing responsibilities to the team that are not the team's.
16
@SteinGauslaaStrindhaug Where the daily standups help in my experience is getting engagement from the less experienced or proficient members, and especially for reporting issues or blockers. I don't mind spending 5-15 minutes a day for just those benefits. It's also prime time (after everyone's had their turn) to bring up sudden requirements changes or similar. The "what people have done, and are going to do" part isn't that helpful, except in those cases where there is something sudden or unusual about a task (e.g. the build server is broken, who is going to work on getting it working again, so that not everyone will waste their time).
3
A very nice video, and I especially liked the last few sentences on evolving agile, although I sincerely hope we are able to combine the engineering approaches to improving agile with management requirements, as the latter tends to be the reason most of us are stuck with faux-Agile processes.
2
@SteinGauslaaStrindhaug Yeah, I guess it depends on the culture. Personally, I don't really put things in Slack / Teams, nor read it very often, and just make backlog items with the relevant information and inform the team the next day about it. I don't like to interrupt or be interrupted while focusing. I guess, the example of build server being broken would be an exception to that, as that should be fixed as soon as someone notices, so should be communicated ASAP, but other things can usually wait until the next morning (e.g. new alignment meetings with other teams, requirement changes, reporting a new bug, etc.)
2
Hmm... not sure on your assertion, but I won't dismiss it. What I would assert is that communication is key, and the more complex the system the more documentation is needed (and needs to be updated, and those updates communicated), but not all of it has to happen up-front. I do agree on the need for smart people and would add to the list of requirements for those smart people, intimate knowledge in, and previous experience on, the problem domain. Too often projects run into the same issues.
2
@thoroughsoft I think Kanban is pretty close to what you describe (edit: also, Scrum's Product Owner is pretty close to your BA description), but I also think that clarifying the requirements is an invevitable part of software development, and often the fewer layers of communication there are between the one to define the requirements and the one to implement them, the better, assuming both are competent communicators.
1
@ContinuousDelivery Yeah, and I think being both honest and assertive about the state of the project, and the requirements, helps here. That said, everyone always seems to be about limiting their own work as much as possible, even when we try to create metrics to show both our progress and technical debt, those are never followed by the business people, even if they have been the ones to request those metrics.
1
@ContinuousDelivery my biggest problem with Scrum is exactly that people who do not understand Agile abuse it, e.g. having the management fix both a timeline and goals, but then still push more work on the team in the name of being Agile. Basically forcing upon the team the worst parts of Waterfall and Agile, while limiting the benefits. I haven't actually tried Kanban, but I feel like it better reflects management needs while forcing them to prioritize requirements.
1