6 Practices Agile Teams Should NOT Follow for Fixing Bugs

You have developed and delivered a complex piece of software for a customer. The customer implementation team have made additional customer specific development on top of that. Now it’s time for production deployment. There are data migration, customer acceptance tests and training for customer… a lot of exciting stuffs.

But there are a lot of bugs, somehow getting unearth only now. Why could not dev testing, QA, Integration, pre-prod, regression, load testing – everything else catch these? That’s another story. For now, let’s say, that’s the nature of the business!

You have set a multi-disciplinary team of developers and testers from different modules of the whole software to deal with these important issues. These guys are a commando team who have been handpicked to do the job fast and flawlessly.

Before discussing how you should organize the sprint with this scrum team in this situation, lets discuss what you should NOT do and why:

1.????In daily stand up, start with asking what’s not done and why:

This is going to demotivate the people as they are anyway toiling to fix as many issues as possible

2.????Plan the day for each developer and tell them the order of doing things:

This is not going to help as the dynamics for each issue is known only by the individual working on this and he/she should be capable of solving his/her own problem in most cases. Also they will reach out for help to the peer group naturally if they get stuck

3.????Prioritize work for each individual and constantly shuffle tasks, priorities, and individuals:

The productivity is the best when an individual is left to do one thing. Too many changes and handovers from one developer to another will result in low productivity and ultimately low quality solution

4.????Long tracking meeting with discussion on technical solution in thread bare in the same meeting:

Meetings that are not focused and that do not involve/require all participants are biggest time wasters and productivity killers

5.????Constantly asking for status (in different form and formats) and watch over the shoulders:

This is also called “war room” in some organizations. This creates unnecessary pressure on doers. These are time wasters for many others who could have used the time on more productive stuffs

6.????Not making constant and frequent releases:

By bulking up many fixes in one weekly or even twice a week release, one will spend more time on testing, deployment and also increases the risk of regression.

I am not claiming that these are not going to work at all in the situation I described. But this will surely create stress, tension, friction and unhappiness among the doers. This builds enormous pressure and stress on the manager and PO as they need to take full control and responsibility for the organization of tasks and outcomes. Depending on individual brilliance of some managers, some exceptional doers and some amazing chemistry in the team, you might succeed in wading through this mess. But I am almost certain that the journey is not going to be fun.

?

If you have read thus far, you will demand what you should then do under this situation and if there are some silver bullet in agile/ scrum to solve this.

Let me attempt – by going into some basics of agile and scrum and examine how we can have some simple tweaks to the regular scrum process:

1.????Organization of the Scrum team: Select a Scrummaster who has the good equation with the cross functional teams, the customer implementation team/customer and is well respected in larger software group. Select a Product Owner who has a good overall product knowledge and have ideally worked with some customer program. The SM should be able to pick some core team members and the rest of the team should be picked by this team – taking into consideration the complementarity in the team. The leadership should support these self selection as much as possible within the limitation of other priorities in the organization. ?

2.????Sprint planning: We cannot and need not have user stories as sprint goals. You can still have a weekly or say 3 days sprint and decide you will tackle - say "all stability issues in module <>" in this week. As part of the sprint planning, decide what’s the meeting practice, tracking mechanism, report format/ frequency, release interval and trigger for release (criticality, time, number of fixes in the queue etc.). This is important as we do not want to waste time debating and changing these during the sprint.

3.????Daily Stand up: You may need more than stipulated 15 mins for this, but certainly not more than half an hour. A typical agenda can be the following:

a.????Each individual talks about what he/she has progressed yesterday, what he/she has picked up from the “New” pipeline and why, If there is any impediments and who all are required to help (and agree set up a separate meeting for that).?This is not very different from a standard Scrum stand up. Isn’t it?

b.????Look at the overall dashboard – what’s moving, what’s not, do we need more reinforcement somewhere, move some people etc.

c.????Look at the “New” items and make sure they are prioritized/ assigned in consultation of the whole team – if not self assigned by individuals. It would be great if someone from the customer program team be there in the meeting and help in prioritization

d.????Release and deployment decision based on agreed principle/process during sprint planning.

The meeting environment should be very positive, you should get exactly the same sense of satisfaction and achievement when you terminate bed bugs/ kill mosquitos one by one (or de-weed your garden – for the less violent folks). There should be celebration in every release milestone!

4.????Sprint Review and Demo: You must arrange a small review and demo at the end of the sprint?- even it is 2 times a week. You should take total inventory of bugs that you moved, show demo of interesting ones. You can discuss the impacts of the fixes – especially in future production set up and how to positively influence that.

?5.????Retrospective: This can be clubbed with sprint review, but should be covered nevertheless. You should use the time to discuss and deliberate on the causes of the issues we had, if there is any pattern, what you should continue doing and what you can change to improve – both in the software and also in the process. You should also discuss if there are any future action (clean up, new feature) in the product and software.

In nutshell, we need to apply some simple agile principles to improve effectiveness, efficiency and above all having a fun ride – even when we are going through a tough and busy situation. These principles are:

-??????Choose a good team, empower and allow them to do their best

-??????Collective responsibility and accountability?- rather than a single or few manager orchestrating the whole thing

-??????Teamwork and close collaboration – also with the external stakeholders/ customers

-??????Self adjusting processes and iterative improvement

-??????Fun and happy environment

There are other agile processes – like Kanban may suit this situation better. But that’s a new learning curve and one can always explore that later!