251–260 of 292 posts
Issue implies something is already wrong with what is being built.
How can we be wrong when we haven't even started yet? It's utter madness
One change I'd suggest: drop the use of the term "sprint". Prefer "iteration" instead. Talking about "sprints" is a bad metaphor, and the metaphors we use do shape the way we think and act to some extent. IMHO, along with the "gap week" between iterations (which I vehemently agree with), this is part of avoiding the conditions that lead to burnout... if you're sprinting, sprinting, sprinting, all the time, bad things…
This really doesn't have to be that hard. You talk to people. You figure out what's important. Then you do that stuff. Then you talk to more people again.
Earlier quoted context omitted.
The point of standups is to help teams to learn to communicate and to steer the team to a habit of working on the most important things. Once that's a behavior, standups can be less frequent or dropped all together. This is especially useful for new teams or when the team changes.
No, the point of standups is to go around in a circle and make sure that everyone has everything they need to keep working (that there are no “blockers” in the parlance of agile). That’s why they’re called stand ups - you’re supposed to stand so that everyone gets annoyed if it takes more than a handful of minutes. If you’re discussing what you did yesterday, what you’re going to do today, when you think x is going t…
Earlier quoted context omitted.
>Don't do overtime. Don't make estimates. Said another way, estimates are not promises. Don't crunch to meet them. I think it should be phrased as "no deadlines". The whole sprint structure is so you're constantly adjusting your plans and estimations at some predictable time. Without a sprint you can end up with randomization.
I've noticed some managers and project managers love to emphasize the that sprint plans are "commitments". "OK, is this what we're committing to for this sprint? Is everyone comfortable committing to this?". LOL. OK. Maybe that guilts the young bloods into doing free overtime or something. But no. It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-a…
Earlier quoted context omitted.
I've noticed some managers and project managers love to emphasize the that sprint plans are "commitments". "OK, is this what we're committing to for this sprint? Is everyone comfortable committing to this?". LOL. OK. Maybe that guilts the young bloods into doing free overtime or something. But no. It's like when car salesmen try to get you to name a number you'd definitely buy the car for and sign it on some not-at-a…
You work on a team with members that make you feel like you're buying a car..?
"Do you feel comfortable committing to these stories?" Always a question.
Committing. If you don't make it for any reason not obviously caused by "outside blockers" you're morally responsible—and maybe even then. What are you, some kind of liar? Quite a step from an estimate. Kind of harsher than a deadline, even, which are oh-so-rarely as "deadly" as the name implies. But people close enough to Scrumish processes to get in the meetings but far enough away not to be writing code or testing things or putting out designs sure seem to like that word. Commit.
Earlier quoted context omitted.
> It's the experienced developers that try to gold plate to avoid the issues that they had in the last project Literally learning from the past and applying it to the present is “gold plating”? I’m stunned.
I don't think the parent poster was saying that the learning itself was bad. I think the gold plating they're referring to is a form of over-correcting. The learning itself is good, and correcting prior issues is good. But over-correcting and over-learning can be problematic and can lead to gold plating. I don't think there's any easy indication of the line between the right-amount of correction and over-correction,…
Earlier quoted context omitted.
Telling your developers to bugger off for 1 week every month will never work out. They still need to be at the office, but they can pursue learning, help with planning (this is critical), or focus on other development tasks they actually want to make.
Ah, when the linked article suggested developers go "surfing" I thought it meant in the sea, not the web.
Earlier quoted context omitted.
50% off is understandable ? Where can I find such forgiving clients? My clients lawyers would eat me alive if I would start to bill them in such manner. They dont want to hear about uncertainty - they are buying professionals and this kind of estimations looks to them like we dont know what we are doing.
Maybe if you're building the n th monitoring dashboard or something. The work I find interesting is inherently uncertain, though.
How non technical person can tell the difference between task inherent uncertainty and Your incopetence? They cant that's why they will buy Your competition that will claim there is no uncertainty.
How do you deal with a sudden bug in released version then? Or even bugs in the curent dev branch? All developers time is allocated to new features, there are no openings – so all the bugs are moved to the next spring automatically and we release with criticals? Edit: everyeone's answering with very good advice on how to handle it, but my intention was not to ask for advice for any situation I encountered personally,…