4 ms·
I find it funny that whenever theres an article lambasting capital-A Agile (which, is usually scrum), people are quick to say “you’re doing it wrong”. Its the b
by dijit 2y ago
I find it funny that whenever theres an article lambasting capital-A Agile (which, is usually scrum), people are quick to say “you’re doing it wrong”. Its the best no true scotsman fallacy I’ve ever seen.
Yet, here I am, to say we are all doing it wrong.
The daily standup should have no managers at all in it, its for the team, and its for understanding blockers and progress.
Another issue that pervades is that of organisation: One of the hardest parts of leadership for me has been trying to understand the distinction between team and task/project, because projects require more collaboration than single discipline teams do: but we conduct capital-A Agile across single discipline team boundaries. I’m too shy to break everyones mental model of how they should work because…
It’s always this way in every company I ever worked, as it is with managers/leads in standups.
I have no idea why, we prescribe scrum instead of using our brains, and we don’t listen to the core instructions given even then- of course it doesn’t work.
- lcnPylGDnU4H9OF 2y agoOn the No True Scrummaster point, it's fair to say that this comment actually suggests a fundamentally different alternative. The No True Scrummaster arguments I see typically zoom in to specific details instead of zooming out to examine the whole process.
- bravetraveler 2y agoMust put the crabs in the bucket for the clawing to begin
- johncessna 2y agoIt's really important to know the history of agile and why it came about. I don't think it's the problem. The root problem, which is true for any other methodology is business's unwillingness to accept uncertainty and change. Standups were co-opted from a people-working-the-sprint touch point to discuss A 24 hour window and address problem, and turned into a status meeting, a jira hygiene meeting, or an number of unrelated things. The answer to management's question, 'when will you be done' is, "at the end of the sprint." Don't ask me to report a daily, or god forbid, hourly status.
- Folcon 2y agoI would love for you to expand a bit on what you think is missing beyond: - It's for cross discipline teams to be able to unblock each other, communicate and feedback progress and updates. Do you see the teams as temporary? Or longer term? How large or small a team size are you thinking? For example would your approach be: - Build a team to tackle a feature or solve a specific area Just curious to get a bit more understanding about what your envisioning =)...
- dijit 2y agoExactly, construct a team to tackle a large enough problem, disband the team once the challenge is met. Hopefully the challenge statement concludes that sufficient documentation of the outcome is created. But, I really don’t have all the answers, I just think cutting across disciplines is fruitless when you put 10 devs in a room and they work on 10 completely different things, which is how Agile is practiced where I have worked.
- cassianoleal 2y agoThat can work in some environments, depending on expected support model. A lot of organisations are doing product (vs project) development though, and personally I find it superior. Teams that are responsible for running and operating the product they built are generally more incentivised to produce quality software. Nobody likes to be interrupted in the middle of a technical session or, even worse, in the middle of the night, because their application crashed - so they learn to build resilience in. They start optimising for operability, maintainability and extensibility - since they will be the ones operating, maintaining and extending. The above is not the solution to all software delivery issues, and is not something that works everywhere, every time. Where it does, it produces better outcomes.