211–220 of 341 posts
The whole concept of standups and scrum was started to bring highly dysfunctional team back on track. Since then now we have been applying methodology that is required to make highly dysfunctional teams work to all teams.
Some aspects of Agile/XP/Scrum etc. obviously have some benefits particularly for larger organizations/teams. On the other hand I've seen smaller companies that are trying to emulate this success really struggle to get real work done, because there are so many standups, retros, kanban and "user stories" etc. In between morning tea and lunchtime, not much breakfix or clearing out tech debt actually gets done, before they are required to pour another bucket of features on top.
I've worked at a company like this that held retros on Friday afternoons and by Monday morning standups, they couldn't remember the things that had been discussed in Friday's retro. It all felt so mindlessly pointless, and playing into the hands of those who make good money selling books about Agile, or talking at conferences about Agile.
IMHO I think the sweet spot is probably somewhere in between.
I've been beating this drum as it's one of the more frequently cargoculted items about agile. A standup has 3 questions to report on: 1. What did you make progress on yesterday? 2. What are you planning on making progress on today? 3. Do you have any blockers? Taking this pulse once every 24 hours is artificially constraining. Relevant stakeholders (product people, other engineers, project managers, etc.) should have…
When most aspects of something have strong cargo cult features, then maybe the whole thing is a fantasy.
I understand many writers are desperate for views, but I'm looking forward to this nasty spreading imperative title infection to die out (which it will, but not soon enough). "What you need to know about ..." ( you have no idea what my knowledge requirements are ) "You don't need ..." ( you won't know what I need until you find out something about me, dolt ). "Why you should ..." ( until you've at a minimum skimmed '…
But I don't ask about ticket status. We just ask about what they did yesterday, and what they're up to today. And I mostly ask that if they aren't doing something already captured in a ticket, make another one, so we have a record of issues taking up our time. You want to do some tech debt reduction? OK, but keep it unambiguous - "tech debt" is too generic.
The standup typically exposes important issues, like how team members are siloing off from each other. And then we can easily sit down and notice "hey we need to sync up". A lot of ad hoc conversations appear right after standups, that wouldn't have just happened, because people don't often spend their time reading through the comment section on open tickets.
It's really a gut check that yes, the team is indeed working together. If your team's standup is just some regular robotic process of repeating status already captured in tickets... WTF; I'd say you've got serious leadership problems.
I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how. According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour. That may be true, but…
That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument? Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer: "What did I do yesterday that helped the development team meet the…
Yes, of course?
But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams require different things in their process.
But ultimately, since it is about values, if those values are not shared by a company (or at least your division) and management it's going to turn into process for process sake. You're screwed, but it's not agile that screwed you.
Standups always felt to me that they had a core negative message to developers. It's not about communication at all. Its about control, its about saying: We don't trust you. We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance. Its also about putting constant psychological pressure on developers, to make sure they complete the…
Bull-fucking-shit; you know why Spotify's engineering team does well? Stripe's? Netflix's? Because they have money , they have money so they can buy the best engineers. You ever see a small business development team compete on their level that isn't a bespoke design firm? In my world, my team isn't an olympic-performing high-end software engineering pack. They don't lead in particular subfields in FOSS in their spare…
One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing t…
> there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback. I find that people are overly optimistic about their chances…
In my experience what happens is one of three things:
(a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of building
(b) You track it as a lot of tasks (~30-50), and whoever is working on it spends half their day fielding questions like "Can I pick up that task for you?" or "why are all the highest priority tasks assigned to the same person?"
(c) You track it as one or a small number of tasks (~2-5), and whoever is working on it has the problem GP mentioned with stand-ups, where they don't have anything granular enough to report and end up looking like an incompetent tool.
I've experienced all 3 and they all suck. I'm not convinced that option (c) isn't the furthest down the right track. Option (a) can be a horror show and probably one of the quickest ways to lose a good dev, option (b) can work but it's dependent on a manager that understands the work and isn't going to lambast the dev for blocking up the backlog with self-assigned tasks. Option (c) just relies on adjusting or removing stand-ups to not focus so heavy on day-to-day progress.