3

We have a project that is reaching a deadline for the final production release. It's a fixed price project and up till now we've managed to work in 2 week iterations, doing regular releases to our "inner test environment" where BAs and people acting as POs from the client's side had a chance to have a look, give feedback etc.

We're now at the point where we have only 4 weeks to end this project and as we go to deploy the separate modules of this application to the client's environment, we've been struggling with a lot of bugs appearing.

We have some functionality to be done still but my question is - what is the best way to handle those bugs as they appear?

Since there's really a lot of them (due to project specifics, we didn't have the ability to test it on client's environment earlier) and it's impossible to estimate them up front + we have only 4 weeks till the end, does it make sense to keep Scrum or switch to Tech Lead dispatching work daily to the devs directly?

8

I would go to some kind of kanban mode in this case. This is how I would handle this:

  1. Create a backlog of bugs. Ask the PO to give them priorities, but do this together with the development team as they can indicate the impact a bug has. This will allow you to fix the most important issues first from a business point of view. (Of course you can help the PO to understand the consequences if a certain bug doesn't get fixed)

  2. Let the team decide who fixes which bug. Like this developers can commit to get bugs fixed. This also allows the team to sit together and discuss the bugs.

  3. Keep the bi-weekly demo. Show the bugs that are fixed. Let the team get the reward for the work they have done. Get feedback from the PO, because even the way bugs are fixed can be functionally not what is expected.

I cannot comment on the situation that you are in because I don't know all the specifics, but I strongly recommend you and your team to investigate how you can test earlier. I always try to get the complete cycle (from userstory to working code in production or at least a production like environment on the customers site) finished as soon as possible, even if the application we deliver says only 'hello world' at that time. It helps to limit the risk that you get in a situation where you end up in the situation that you are in now.

  • good stuff, I was actually thinking about Kanban as well. What I'm affraid with letting go of Scrum and by the book 2 week iterations now is the lack of control and responsibility from the team's side (which is almost always happening eventually in direct work dispatching by someone like a Team Leader etc.) but Kanban and making sure WIPs are met might be a good idea. Will try, thanks! – RRob May 26 '14 at 7:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.