A team where the Engineering Lead(or any kind of manager) thinks that you don't need retros because there are no problems is exactly the kind of team that needs retros.
You may have missed the part where the author says that problems should be addressed as they come up and not just once at the end of the week. A retro obligates people to find and/or bring up issues. In my opinion an open door policy would push people to bring up things that actually matter.
You don’t need standups
111–120 of 341 posts
Re: You don’t need standups
#112I think a lot of the themes in this article I can agree with, but I come away with the overall impression that the author hasn't necessarily worked in a healthy agile environment before. Basically, I agree with many of the conclusions (or solutions) but disagree with a lot of how the author came to them. Standups aren't inherently bad. Also it sounds like he moved his team to more of a kanban style workflow -- which…
Re: You don’t need standups
#113Re: You don’t need standups
#114Earlier quoted context omitted.
"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with. "I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Sta…
What if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing? The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now. It forces developer…
>What if I just want to focus on building, not explaining and sharing?
>it makes them share if they are thinking incorrectly about something
>it makes them easily replaceable
I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you aren't able to explain what you're doing and share your thought process. Writing buggy code and refusing to work with your team is a primo way to get canned. Owning the fact that there's time constraints and imperfect code and minimizing the risks taken and assumptions made by understanding the architecture is valuable.
Stand ups might not be the way to do it, but if even the prospect of sharing your thought process and explaining what you did strikes you as being 'micro managed', well.......
Re: You don’t need standups
#115The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to m…
Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?
Re: You don’t need standups
#116Want to talk about something? Knowing you can put it on the agenda for the next standup is great. If the standup isn't the right forum for the topic, then it's still probably the right forum to decide what the right forum is, and let's you include people who are unexpectedly interested.
Talking about incoming tasks and bugs is also helpful, and is an important part of developing a collective understanding of priority and approach.
And of course when there's some specific pressure or deadline, then you'll need to talk status and cover details. The standup is going to change based on needs. It's good to have a well-socialized team that regularly talks and both makes collective decisions and learns how to interpret those decisions when doing their personal work. Daily practice is worth it, and pays off double when something goes wrong.
Re: You don’t need standups
#117Earlier quoted context omitted.
Exactly. This could work well in teams where the engineers are all competent and really just need the PM to stay out of their way. In weak teams, this could easily see an end-of-quarter with unmet deliverables and other management messes. A lot of people would take advantage of the hands-off approach as much as they could. Either way, Agile is ridiculous so I agree with the author about that.
> In weak teams, Agile is largely about managing weaker teams.
Re: You don’t need standups
#118FTA: Say you’re in a relationship and it’s going amazing. You should totally start going to couples therapy once a week, right? Me: Actually yes - that way it stays amazing...
We've found that it ultimately reduces the amount of time we spend on talking about that stuff. Sit down, take care of business, see what's on Netflix. Without it, we could easily spend the same amount of time per week just figuring out when to talk about XXX thing, let alone actually talking about it.
Re: You don’t need standups
#119Re: You don’t need standups
#120The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to m…
>The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. That's because sprints weren't designed for us. They're designed for management. Product managers and VPs need to be able to think of their "resources" in manageable, discrete chunks. Vagarie…