141–150 of 341 posts
If a project ends 6 months early it's entirely possible to not get paid as much.
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…
I don't think this post will age well.
The team I am on is currently swinging back towards more traditional agile after going too lax on planning, retro, estimation, etc for a while. These "rituals" are effective ways to ensure a good base level of inefficiency. If you're feeling like the agile rituals are becoming a waste of time, I would try out doing longer sprints before dropping them entirely.
Cutting process relies on good habits from the developers/whoever on the team, and habits can degrade over time. Devs can cut corners without formal process, because creating meetings and facilitating process that doesn't formally exist can feel like just another burden/task switch they have to take on.
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…
- Many engineers prefer to solve issues themselves rather than ask others for help. Often newer engineers don't know when to ask others for help. Standups help to foster this communication.
- Reading code is generally harder than writing code, especially when written using a framework that the engineer is unfamiliar with. This leads to a tendency to declare existing code tech debt and want to re-write it, especially by less experienced engineers. Sometimes this is warranted but often it is not. Standups help guard against this by allowing more senior engineers or managers to catch this early-on.
- There can be valid business reasons to get an unscalable feature out in ~2 weeks rather than scalable feature in ~2 months. Standups provide a quick way to explain the underlying business reasons to the team.
- Business and contracts do require dates & deadlines. Even though it is not perfect, there needs to be some attempt at predicting when a certain feature can be delivered. Jira, and ticket tracking is important for this.
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. 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…
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…
I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.
If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental.
With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best.
> due to the business people who are really in charge not wanting to change.
Stand-ups should be only for the team and SM. Sometimes a domain expert/PO can be added to the mix, if issues need clarification. But never should managers or stake holders bother the team during internal coordination of the work (as others said, standups are no status-report).
Standups are (in my experience) usually a symptom of a low-trust environment, where there's an underlying belief that engineers will do less work or let things slip without the fear of being behind at the next standup. In some companies, this is actually true - so in some cases, standups are certainly effective - but I can't think of any argument for why they'd be necessary at all companies.
Our team is distributed and has been going ~eight months without standups or work hours, and I'm extremely happy with the quality and pace of our engineering. This requires a high-trust environment where every person is given large feature areas that they are able (and incentivized) to drive autonomously, but I think this ends up being better both for productivity and for quality-of-life.
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. 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…
Earlier quoted context omitted.
Are stand up meetings the correct venue for brainstorming?
Maybe not, but if your peer said "hey can someone help me with this task" in a standup, wouldn't you want to help them once the meeting is over?
Is there any reason to believe that a process that interrupts an entire team every day to make everyone listen to non-critical updates would be necessary? Standups are (in my experience) usually a symptom of a low-trust environment, where there's an underlying belief that engineers will do less work or let things slip without the fear of being behind at the next standup. In some companies, this is actually true - so…
and or a high volatility process and or poor information flow. All of these things occur at different times throughout any company. Standups mitigate these issues and are not supposed to be these hour marathons that I see everywhere.