Agile defect management strategy

"We don't have any defects, so we don't need a defect management strategy".

If you are in that situation, you're fooling yourself. Good teams are not those who don't make any mistakes (that's an illusion!) - they catch their mistakes before any harm is done.

And for that, they have a defect management strategy in place. And that strategy must be continuously inspected and adapted.

The following is a high level outline for an initial agile defect management strategy:

Define: What is a defect?

There's nothing more cumbersome than the discussion whether something is a defect, "Works as designed" or a Change Request. And that discussion does not solve the problem at hand. It's a red herring. You do not want to decide this on a case-by-case basis.

  Align the team and all stakeholders on what you call a "defect" and how to define it. You are free to inspect+adapt the identification criteria frequently. But don't make ad-hoc decisions after getting enraged about individual reports.

How will you track defects?

It doesn't really matter whether you decide to use Post-It's, your Backlog tracking tool or a dedicated application lifecycle management suite. What matters is that you use appropriate means and everyone agrees on the approach.

Issues to consider are: Who needs the information, what will they do with it?

Separate: What is not a defect?

At least as important as the definition of defects is a clear definition of what will not be handled as a defect. This doesn't need to be very formal, specification by example does the job quite nicely.  Typically, issues that are not defects become stories in the Product Backlog and are at the whim of the Product Owner.    

 Some product owners will claim that "as long as it doesn't affect revenue, it's not a defect". We will not discuss here whether that is a good approach. It is merely one of many possible decisions in a project.

 Again, align the team and all stakeholders on what is not a defect and where the dividing line is.

Handle: How will you deal with defects?

It may be obvious to some, but it's not bad to have an open discussion. Depending on the formality and scope of the project, you may want to discuss topics such as severity, priority, SLA's etc. 

Furthermore, you should discuss how you will ensure that the issue is gone once and for all.

Improve: How will you deal with non-defects?

Just because it's a bug doesn't mean the software is doing great. Some "non-defects" are actually improvement suggestions. Others are distractions from the product vision. Yet others are simply a waste of time. While you will need to decide the next steps on a case-by-case basis, you should have a clear strategy on the next steps. After all, your purpose is not to clear the defect list, but to provide a great product that excites customers.

Flakiness: What if you don't know?

Bugs may also be flaky. You may need specific approaches for dealing with the "Bugfoot" (someone is adamant to have seen it, but there is no proof) or the "Heisenbug" (the nature of the bug changes by observing it). The worst thing you can do is sink near-infinite effort into analysis, but you also don't want to disappoint your customers. Claim the common ground.

Conclusion

Invest a bit of time to create a clear defect management strategy. Inspect and adapt your approach whenever necessary. Stay lean and pragmatic. Align.

This will make your agile project much more successful.

True Collaboration over Daily Standups

Daily Standups go a great length in synchronizing and building teams on a day-to-day basis. Often, they make the difference between a loosely coupled group of developers working on related topics and actually working towards common goals.

Yet, there are numerous problems habitually associated with them.

The nature of the Daily Standup

Following textbook definition, we would have all team members huddle in front of the Scrum Board, then each team member shares "What have I done yesterday, what will I do today, what impedits me?". The main purpose is to synchronize one another, but also to build mutual accountability.

Any stakeholder who is interested may participate in Daily Standups as a silent bystander to get a feeling of what is going on: "Status Meetings" and "Status Reports" are a thing of the past.

Of course, this is also part of their value. However, their biggest value is barely hinted: Finding opportunities for improving the collaboration.

What happens when you don't have Daily Standups

Without daily standups, there is a huge risk that team members run into different directions, providing code that does not turn into a maximum value solution at the end of the sprint. One worst-case scenario: people work in parallel on incompatible solutions to the same problem - and find out when the customer complains.
You can't be a team unless you share troubles, solutions, failures and success.

Dealing with Problems

It's natural to face challenges in the implementation of software. This-or-that framework doesn't behave as expected, here or there a configuration item is causing trouble, an infrastructure component is required - and whatever. Technical experts are keen on solving their own problems, because after all, that's what makes them experts.

Oftentimes, there is someone else on the team who has experienced the same type of problem before. Becoming aware of someone else's problem, they would gladly extend a helping hand. But how do they become aware unless someone is sharing their troubles?

Tangents

The Sprint defines a clear scope and time box. Sometimes, it is very interesting - or academically challenging - to not only work on the task at hand, but to derive a related task. For example - we need to do a site index. Because it's both related and my personal favourite, I also implement a fuzzy search. Cool, but it will cost me 5 days of the Sprint - and nobody asked for that.

The shared accountability in the Daily Standup encourages the team to focus on the common objectives and provides an opportunity for team members to say "That's good, but we need you to do something else."

Status Reports

Transparency makes agile implementations strong. Lack of transparency causes problems. Managament's first reaction when they don't know what is going on: Forced status reporting. The first stage is boring, hour-long status meetings that become a mixture of sleeping pill and justification rally. In the second stage, they become written, formal and tracked - merely to satisfy the internal need of being informed. Usually, both methods are implemented simultaneously, in cumulation burning a good 20 hours of productivity per week.

Not many developers like writing formal status reports, so daily standups actually increase morale.

Why having Daily Standups is bad

After the previously mentioned topics, who could argue that Daily standups are actually bad?

Let's look in detail what Daily Standups actually are. They are a predefined standard process executed in a rhythm. As such, they induce waste.

No meaningful update

"Yesterday, I was working on the search engine. Today, I will continue working on the search engine. Nothing impedits me." - great. Now, how much did that help my team? The good news: Like this, the standup only takes 5 minutes. The bad news: We're actually wasting 5 minutes of each team member each day.

Numerous approaches, such as "Improving the 3 questions", have been implemented in different organizations. None of these solve the fundamental problem, they merely try to expose the symptom.

If it's something that takes more than 1 day, why has it not been sliced further - why is nobody else involved, what has actually changed since yesterday - and is there a way for other team members to join me so that we can deliver faster, a better solution etc.?

I might bring up even more questions: If I've been working on it for a full day already and plan to work more - who has done the testing? Is anyone doing code reviews? I should be rallying support for my topic rather than just informing what I do. Or is my task not important enough for the team to contribute?

Hiding the Elephant in the Room

Have you ever seen how everyone focuses on their stories, their responsibilities in a Daily? Yes, everyone can align that on the Sprint Goal. But is that sufficient? There is probably a prioritization issue when 3 or more stories are Work in Progress, because nobody seems to ask the intrinsic question "Which one is really the most important of these?" - probably the team is more focused on delivering quantity than getting the top priority done!

Many teams justify this behaviour by stating: "But Tim is the only Database expert, so he's the only one who can do that story!". A measly excuse, really - because they have a bottleneck and aren't even working to resolve that. In fact, the team subconsciously knows they have a sustainability and quality issue: If Tim gets sick or goes on vacation, the team may be completely blocked. All the stress is on one shoulder!

So, the real question we should be asking is not: "Which is the next story for Tim?", but "How can we collaborate on this one, so that the next Database story doesn't rely solely on Tim?"

Value Delay

Why should I wait for the Daily Standup to rally collaborators? I should do it immediately. If I need to get some exploratory testing done - why should I wait until the next stand-up to find a team member who has some time? 

Again, this may come down to priorities. If I am doing is the most valuable thing the team can do at this time - why am I the only one? If I am not doing that - why am I not working on the most valuable thing? Why should I wait until the next Daily to deliver most value?

Restating the obvious

The worst stand-up I have ever participated in was actually in the most efficient team. We did something called "Mob Programming". The team was great, we were flying through the backlog at a rapid pace. Everyone was constantly and intensely involved. But our daily standups were terrible: "Yesterday, we completed the stories A,B,C. Today, we will work on the top priorities in the following order..." Only one person spoke, because - everyone already knew what we were doing, why we were doing it and how they would contribute! Everyone was highly focused. Nobody was doing anything outside the agenda.
The stand-up wasn't adding any value because everyone knew everything before we huddled!

Is this inherent to the Stand-Up?

All of the above can be solved by actually improving the nature of the stand-up. But many times, standups are not like that. Why? Because people are not looking for collaboration, they are merely fulfilling their responsibility. Let's be frank: If you aren't looking to collaborate, your Daily Standup is a farce!

Summary

Daily Standups are great. If people are working on different tasks, the Standup provides an opportunity to resynchronize, harness synergy and refocus.
You should improve your Daily Standup to the point where they become a magnet for collaboration and a catalyst for value creation. Once they fit that purpose, you should look for different places to improve.
Daily Standups are an artifact in themselves and provide no bottom line value. They assist in obtaining value - no more, no less. As the level of collaboration among teams improves, the amount of actually new and relevant information would decrease.  In an ideal team, collaboration would be an ongoing, permanent condition and the Daily Standup would only interrupt the ongoing collaboration to fulfil a non-value adding ceremony.
At that time, Daily Standups turn into waste. Few teams ever reach this state.

Improve your standup to be valuable, but remember that the vision is great collaboration, not great Standups!