On May 4, 2009, at 7:42 AM, "Brent Walker"
<brent.walker@ halliburton. com> wrote:
> I would like to see some discussions around various best practices
> for managing defects especially around multi-product teams (i.e.
> inter-related products from different teams)?
> 1) Do you reduce your capacity for your team members and set that
> time aside for working defects
> a) These defects are preventing other teams from completing their
> sprint (a blocker of sort)
It sounds like you should consider looking at your definition of "done." Make sure that your teams strive to create defect free code. Look to add unit testing and even consider having teams create mock objects until their components are certified by other teams.
> 2) Do you plan your sprint to include a set amount of defects for
> the iteration
If they're are defects, one way to deal is to say that the previous story is not done. Again, look at your definition of done. One of the concepts agile tries accomplish is smaller units of work where the work is done. With waterfall you rush to done then spend more time on QA/bug fixing. So, if you are pushing stories through full of defects, are you doing scrum or scrumfall?
> 3) What level of flexibility does your team plan for in managing
Defects can be done as stories and let the product owner decide if the last stories that are not fully completed are more important than the new stories.
> I work with infrastructure teams and struggle to find a balance
> between the sprint contract and the flexibility needed to fix
> blocking defects requried by the consumers of the infrastructure.
> Here is an example:
> Application Team "A" has identified several defects that my
> infrastructure team needs to provide fixes for but are not currently
> preventing any stories in their current iteration. They just want
> them fixed prior to their "hardening" phase of their release.
> Application Team "B" has a story in their current iteration that is
> unable to be completed due to a defect the infrastructure team needs
> to fix.
Inversion of control and mock objects can help here while you wait. This is an impediment which your scrumaster or product owner should own. There is no point stressing out over a task which can not be completed because of a 3rd party you can not control. You can try to work around it or take on other tasks until your impediment is resolved. I
> Iteration Planning for Infrastructure Team: Planned to fix a few of
> Team "A's" defects but did not plan for the one defect from Team
> "B". Based on the planning contract/comittment we push the defect
> from Team "B" into the backlog and say sorry? We will add it to our
> next iteration?
You will have to.
> Again, looking for best practices from the perspective of an
> infrastructure team.
Try to come up with best practices that work for you in your environment, then retrospect and continue to improve until you find the perfect, best practice for you.