Scrumptious

Bugs are pesky little things. They pop up everywhere, can be really annoying, and don't want to go away. Thank goodness we aren't in the Matrix where agents can hold us down while they implant metallic bugs into our body in order to locate us.

There are three main classification of bugs in my view: Genuine Coding Bugs, Non-Genuine Coding Bugs, and Human Bugs.

Genuine Coding Bugs
Most of us are familiar with coding bugs that appear throughout the project. These are genuine bugs that need to be addressed before they get more difficult and more expensive to fix. They can be mitigated through practices such as Test Driven Development and Continuous Integration. But the fact is there will always be bugs in every Scrum project. They should be listed in the Product Backlog as a bug, prioritized, and given the appropriate attention that maximizes value.

Non-Genuine Coding Bugs
There are also non-genuine bugs that slither their way into the Product Backlog. In other words: fake bugs. These are usually tasks disguised as bugs that get pushed into development. Stakeholders are the usual suspects, but Product Owners are also guilty of this practice. The Scrum Master should watch out for this problem, but they are not always technically competent to know the difference. The Development Team (in the absence of a credible Product Owner), or rather the developer who is asked to work on the "bug" as a matter of urgency, knows very well if the bug is really a bug. However, developers sometimes allow these "bugs" to be pushed through, perhaps because of a close relationship with the requester, or due to a passive personality.

Human Bugs
Human Bugs can be the most difficult to deal with if the Scrum Master and/or Product Owner are not on their game. Stakeholders are very welcome into the collocated work area, especially to view information radiators and clarify something with the Scrum Team. But their presence should be kept at a reasonable minimum, which basically means just enough to maximize value, not the reverse. This workspace is not, unfortunately, the only time stakeholders can morph into bugs.

Stakeholders may wander into the Daily Scrum, and through human nature, ask a question here and there. This cannot be permitted as it breaks the momentum of the Daily Scrum. Stakeholders at the Daily Scrum can attend if they must, but should never speak, only observe. I also believe that any line manager of a Development Team member in the Daily scrum should not attend at all. Remember the team must be allowed to work in a safe space, able to fail, make mistakes, and present issues with their progress or the team's progress. What if one of these issues is their line manager perhaps giving them little tasks here and there. Is the team member supposed to say: "What's stopping me from finishing this user story is my manager always giving me little tasks here and there." Should they say that in front of their manager? I don't think so.

Regarding the Retrospective, under no circumstances can a stakeholder or line manager attend this meeting. In fact, it is my view that even the Product Owner should only attend part of the meeting, but there are two camps on that one. The retrospective is a BUG FREE ZONE.

So, what happens when stakeholder bugs find their way into your Scrum project? That's easy. Take out the bug spray. Naturally this is not real insect spray, no matter how tempting the thought might be. It is something the Scrum Team member can say or do when the bugs come out. Here are just a few examples of using Bug Spray:

1. Stakeholder wants to add some "bugs" disguised as tasks. Developer: "Please speak to the Product Owner."

2. The Product Owner wants to add some "bugs" disguised as tasks. Developer: "This is a task, not a bug." Failing that: "Please speak to the Scrum Master."

3. Stakeholder wants to speak during the Daily Scrum. The Scrum Master needs to ensure that only the Development Team speak unless they have a question (usually to the Scrum Master or Product Owner). The Scrum Master should speak to the stakeholder privately and coach them on why it is not permitted to speak during the Daily Scrum.

4. Stakeholder wants to attend the Retrospective. The Scrum Master must make a stand and not permit the stakeholder (other than Scrum Team members) to attend the Retrospective under any circumstances. Remember, this is a BUG FREE ZONE.

                                                                * * *

The Development Team need to be focused on delivering the product, not struggling with impediments. The entire Scrum Team is responsible for minimizing bugs. Whether it be genuine, non-genuine, or human. Bugs are a necessary part of Scrum projects, but that doesn't mean we can't have the appropriate Bug Spray for it.
 

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!