Re: Release management in Scrum
- Hi, my 5 pence:
1) why are there so many bugs that keep the senior dev occupied fixing? Talk about this in the retrospective. And why is it the senior who fixes things, and not the whole team? It was the team as a whole who let slip in the bugs, no?
2) if you need to explore/analyse what has to be done for the next sprint: don't start to do this until the whole team is available; them do some design spikes until you know enough to plan the next sprint.
It might hurt to say, "we cannot start to plan the next release, we have to fix the bugs in the last release first", but the whole team is responsible for what is released.
If the releases are frequently bugged, make it visible that quality is the problem right now, and take care of that first.
If you don't know enough to start the next sprint, make it clear that you need some time to explore the possible technical solutions. Working prototypes will almost certainly convince PO and clients.
THEN, when bugs are fixed and you know your options, you kick off the first sprint for the next release.
--- In email@example.com, Ron Jeffries <ronjeffries@...> wrote:
> Hello, Sharmila. On Monday, May 16, 2011, at 10:42:10 PM, you
> > Since there is back to back release, we come to a dead lock
> > situation wherein we have spillovers and support for earlier release.
> > The senior developer is always working on support and
> > consultation for spill-overs. And when we start with the next
> > release, release plan for the new work is always postponed as
> > analysis is not done and release cannot be planned. So release
> > planning for new release happens only mid-way after completing spillovers.
> > How do we solve this deadlock .
> You have a few options right now. Some are:
> Proceed to estimate without the senior dev. Your other people
> probably know enough to estimate fairly well. They might even be a
> bit more conservative. Since you have "spillovers", it sounds like
> a little conservatism might be useful.
> Stop the support and get the senior dev involved. It shouldn't
> take more than a day to estimate the new release, so the world is
> not likely to end.
> Wait and get the estimates later. One good way to do that in Scrum
> style is just pick your delivery date and learn as you go along
> what to fit into that date.
> However, your situation suggests to me that there may be a few
> things left to learn in your execution of Scrum:
> Backlog grooming, every Sprint, should involve everyone and
> certainly the senior developer. In the final Sprints, you can
> shift the grooming to talking about features for the next release.
> The overhead doesn't change and you get information you need.
> Your definition of done may not be as robust as it could be,
> depending whether "spillovers" means defects.
> Your management of features to get the best possible product by
> the delivery date may need improvement, depending whether
> "spillovers" means features we absolutely need but that somehow we
> didn't put in before the date.
> Your situation can be handled now in only a few different ways. The
> fact that you are in the situation suggests that the team has some
> learning to do, and some improvement to gain in execution.
> Ron Jeffries
> Prediction is very difficult, especially if it's about the future. -- Niels Bohr