321–329 of 329 posts
Earlier quoted context omitted.
By breaking it down into smaller stories?
That would be ideal, but we are devs, we don’t get to touch the stories other than to mark them as done...
Earlier quoted context omitted.
Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process. Scrum simply can't be implemented as a purely developer process. The backlog exists as a rolling contract between dev and product owners and sponsors. The most common failure I see is when project leadership agrees to a fixed scope and timeline then tries to execute in…
Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybr…
Earlier quoted context omitted.
If you do this often enough. People will assume you are busy if you don’t show up at all.
Don't forget to always roll up your sleeves and carry around some papers.
He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…
IMHO, the idea is that over time the organization will adopt new Agile practices and not depend on Scrum anymore. In practice, however, many organizations think they are Agile after they introduced Scrum, which is a simple fallacy. After all, becoming Agile is about a culture change and not about the introduction of a new process framework.
I've worked on more than 10 different Scrum teams, and have seen it done well exactly once. When it was good, it was very good. But we spent one entire workday (7 hours) on each sprint follow-up meeting, and then another entire workday planning the next sprint. That is what it took to write the stories, break them down into one-point pieces, prioritize with the PO, pass the stories out to the devs, etc. Most places j…
Earlier quoted context omitted.
That would be ideal, but we are devs, we don’t get to touch the stories other than to mark them as done...
If you can't touch the stories, you can ask whoever does to break it down. If they don't then you shouldn't ever pick it up into your sprint. If they insist and it doesn't work out then you should call out the incident in your retrospective and hopefully get everyone to agree to do things differently in the future.
Then they ask us why there isn’t any progress.
Earlier quoted context omitted.
That would be ideal, but we are devs, we don’t get to touch the stories other than to mark them as done...
You're not doing Scrum then. One of the few meetings that Scrum dictates is "backlog refinement" where the dev team works with the PO to get the stories into a workable state.
I've worked on more than 10 different Scrum teams, and have seen it done well exactly once. When it was good, it was very good. But we spent one entire workday (7 hours) on each sprint follow-up meeting, and then another entire workday planning the next sprint. That is what it took to write the stories, break them down into one-point pieces, prioritize with the PO, pass the stories out to the devs, etc. Most places j…
I'm on a team that started doing Scrum a few months ago, and we're still figuring it out. To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?
I would say the top, most useful, make-or-break practice that I would say is most essential to Scrum succeeding is a combination of:
* 1 point ≈ 1 hour of work
and
* no task above 3 points, try to only have 1-point tasks
Coincidentally, this process is what took the longest in our planning meetings, because the coders sat down and planned out the tasks, kind of the way you would in an algorithms course.
The payoff is that our estimates, after the first couple of sprints, were dead on, and there was very little "discovered work" mid-sprint. No midnight oil. And no corner-cutting.
Earlier quoted context omitted.
Nope, never. I have seen more success in cases where teams estimate for 90% percent confidence instead of 50% confidence. By that I mean "it should almost never take longer than that" vs. "it will probably take that long." Unfortunately, to do that, you need enlightened business management that appreciates the difference between an estimate and a promise, as opposed to business management that pays lip service to the…
> "it should almost never take longer than that" vs. "it will probably take that long." This sounds like a much better way to estimate. Do you have any links to content discussing this?