Bugs first, even before new Features?

orZero Defect

1

What is “Bugs first”?

Alternative one: Fix bugs immediately

“Fix all bugs before starting next user story.”

Sprint: “User story can be closed only when all bugs have been fixed.”

Kanban: “Work in progress (WIP) can only be closed when all bugs have been fixed.”

Alternative two: Fix bugs in sprint

“No bugs at end of sprint.”

“No bugs as done-done criteria.”

2Oliver Schreck

Potentially shippable product

3Oliver Schreck

Why?

Bug-free, stable software makes a tremendous impression, especially when

you demonstrate intermediate versions.

Closer to full product quality in each sprint

Higher Product quality

4Oliver Schreck

Why?

Each unsolved bug is a piece of work that need to be done “later”

Reducing bugs leads to less “later work”

The need of stabilization sprints after “end of development” decrease

Velocity measurements become more true

In sum: Release planning becomes much more reliable!

Higher predictability

5Oliver Schreck

Finding Bugs early

6Oliver Schreck

Finding Bugs early

7Oliver Schreck

Zero Defect

Maintain the software at highest quality during the development

Improving quality actually reduces development time

Programmer writes between eight and twenty lines of code a day;

the rest of the day is usually spent on debugging

Studies done at e.g. NASA, IBM, have shown that better QA leads to shorter schedules.

An IBM study concluded that software projects that make quality a top priority typically have the shortest schedules, the highest productivity, and even the best sales.

8Oliver Schreck

9Oliver Schreck

10Oliver Schreck

11Oliver Schreck

12Oliver Schreck

13Oliver Schreck

14Oliver Schreck

15Oliver Schreck

16Oliver Schreck

Ten basic rules – (1-5) Test your product every day as you develop it, and fix defects as soon as you find them.

Gated checkin, 20 minute build, Daily Build

Once you find a defect, fixing it becomes your number one priority, and you avoid writing any new code until the defect is 100% eliminated.

Review your code regularly.

Code inspections are far more effective than testing

Code reading detected almost twice as many defects per hour as testing

Rewrite poor-quality modules.

Typically you find that 20% of your routines are responsible for 80% of your errors

Assume full responsibility for every bug.

95% of all software defects are caused by the programmer. Only 1% of defects are hardware errors, and the remaining 4% are caused by the compiler, the OS, or other software

Never dismiss a potential bug; find out the exact cause of any anomaly, especially if irregular

Handle change effectively.

Carefully consider how each change will impact your pre-existing code. Poor integration of unanticipated features is a major cause of defects

17Oliver Schreck

Ten basic rules – (6-10) Rewrite all prototyping code from scratch.

Rapidly prototyped features that slip into the final product are a major source of bugs because they are not subject to the samequality standards as the rest of the code.

Set QA objectives at the beginning of every project.

Set QA goals, e.g. performance, quality standards, coding guidelines

Don't rush debugging work.

50% of all bug fixes are done incorrectly the first time, often introducing new bugs in the process.

Take the time to understand the source of the bug.

Write UT first to verify your correction.

Treat the quality of your code at the same level of importance as the quality of your product.

Rate your code on a scale of one to ten for overall quality.

Are you sure that it is above 8, if not rewrite it.

Learn from every bug; each one represents a mistake that you made.

Learn why you made each mistake

Adopt simple coding conventions to avoid common bugs, e.g. initialize each variable, release memory, try/catch, comment your code

18Oliver Schreck

Accumulation of “Undone”

19Oliver Schreck

preparation development

Undone UndoneUndone

Stabilization Iterations

Planned Release

Actual Release

Undone

Unknown amount of undone work !

(Ken Schwaber)

Open Bugs Compared Waterfall compared to “Bugs First”

20Oliver Schreck

Why? - Faster Learning

Fast feedback enables fast learning

Improve coding practices

Improve system knowledge

Improve domain knowledge

Additional bugs can be avoided

21Oliver Schreck

Why? - Less total effort

The earlier a bug is fixed, the less is the administrative cost

Fix bugs as long as the code is still fresh in mind – is faster

Fix bugs before the code has developed further – is easier

A lot of time can be saved in system integration and test – expensive test environments

can be better used

Each sprint provides a stable platform for the next one

22Oliver Schreck

If you see a problem fix it!

23Oliver Schreck

Questions?

If (unclear == true) then askme();

Oliver Schreck