"Agile software development is about iteration not oscillation"
Jim Highsmith (paraphrased), Agile 2009

"Deliver frequent, tangible, working results"
Peter Coad

"Kanban is the science of not trying to do too much at once"
Stephen Palmer, 2012

"We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors that were made because we rushed through the design process"
Glenford Myers (via jJeff De Luca)

"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,

"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill

"chaos often results when a project's complexity is greater than its managers' ability to direct meaningful progress toward a goal."
Ken Schwaber, Agile Project Management with Scrum, 2004

"The complexity of software is an essential property, not an accidental one. ... Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size."
Frederick P. Brooks, The Mythical Man-Month, 1995

"Human brain capacity is more or less fixed, but software complexity grows at least as fast as the square of the size of the program."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"As the number of people increases, the ways they can interact tend to multiply faster than you can control them."
Gerald M. Weinberg, Quality Software Management: Volume 1 Systems Thinking, 1992

"When people are factored in, nothing is simple. The complexity of individuals and individuals working in teams raises the noise level for all projects."
Ken Schwaber, Mike Beedle, Agile Software Development with Scrum, 2002

"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can’t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum

"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain

"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin

"If you can't explain it simply, you don't understand it well enough."
Albert Einstein

"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley

"I guess that as you go along you try to fill your tool-box, so that when you face these circumstances you have more options to choose from"
Jonny Wilkinson, Tom Fordyce's Blog, 2009

"Speech is conveniently located midway between thought and action, where it often substitutes for both."
John Andrew Holmes

"Information Technology is 80% psychology and 20% technology "
Jeff De Luca, www.nebulon.com

"Perhaps the worst software technology of all time was the use of physical lines of code [for metrics]. Continued use of this approach, in the author’s opinion, should be considered professional malpractice."
Capers Jones, Applied Software Measurement

How to manage defect reports and address the fixing of bugs in Scrum

Eventually everyone who has done some basic Scrum training asks the question, "How do you handle the fixing of bugs? Where does this fit in the process?"

As usual the answer is, "It depends." It sometimes depends on the teams precise circumstances but more importantly it depends on the number and severity of the bugs.

One of the guiding ideas in Scrum is to concentrate on delivering items of the highest business value as early as possible. The product owner ranks items on the product backlog in terms of value to the business, highest value items at the top. The development team take items off the top of the list to work on next.

When a bug is reported, there are three basic responses depending on the value to the business of fixing the bug.

  1. A fix for the bug is of much more value to the business than the work being done in the current sprint.

    In other words, it is a serious bug that must be fixed as quickly as possible. In this case, the sprint must be aborted and the team released to work immediately on the bug. Once the bug has been fixed, a new sprint is planned and started in the usual way.

    This should be a rare occurrence. If every iteration has to be aborted for this reason, then more remedial action is required; a sprint dedicated to reviewing and improving the quality of the areas where the bugs are being found, for example.

  2. The value to the business of fixing the bug is less than the work being done in the current sprint.

    In this case, the bug is entered as an item on the product backlog and prioritised alongside all the other items by the product owner in terms of value to the business. If it's value is great enough it is committed to be fixed by the team as part of the next sprint, in just the same way as other high value items on the backlog.

  3. The value to the business of fixing the bug is enough that the business want the bug fixed by the end of the current sprint.

    This third option is really a compromise. Ideally, this level of bug should be handled as either case 1 or case 2 above. However, it often takes a level of maturity in doing Scrum to constrain the business to these two options. The compromise, is to dedicate a certain proportion of a team's capacity during each sprint to bug fixing. If a team can generally complete about 30 story points worth of work in a sprint, then the team can agree with the product owner to reduce that to 25 or 26 to free up 4 or 5 story points worth of capacity to fix these kinds of bugs as they arrive. The exact proportion will depend on the frequency of this level of bug. How exactly the 'bug fixing time' is allocated during the sprint is for the team to organise, balancing the cost of context switching, the effort needed to fix a bug, and avoiding compromising the sprint commitment.

    Obviously, if the number of bugs of this sort arriving during a sprint exceed the spare capacity, the product owner is faced again with either aborting the sprint or adding the bugs to the backlog for consideration during the next sprint planning session.

    In contrast, if fewer bugs of this severity are reported during the sprint, the team should be able to pick up some more work from the backlog.

    The amount of overhead and complication that this compromised way of addressing bugs introduces is significant. If this approach is adopted, one of the goals I would have as a team is to gradually eradicate the need for it by identifying the sources and causes of bugs of this severity, and looking to introduce and adapt working practises that eliminate or at least severely reduce them.

How does this compare with addressing bugs in other agile approaches?


In a Kanban based approach, there is less difficulty addressing bugs because there are no fixed length iterations, just limits to how much work can be in progress at any point in time. This means an important bug can be placed on the back log as the next item to work on, and it will be worked on as soon as an item currently in progress gets completed. For critically important bugs, the Kanban board would be largely frozen while the team addressed the critical bug as an exception to the usual process, again as in Scrum, assuming critical bugs are rare.

Feature-Driven Development

FDD runs multiple, variable length development iterations concurrently. Each iteration is led by a Chief Programmer . On an FDD project, I would typically maintain a separate prioritised list of bugs and assign them to Chief Programmers in the same way features are. It becomes the Chief Programmers responsibility to schedule the bug fixes into an iteration appropriately based on relative priorities to new features and other dependencies; the development manager raising the priority of bug fixes if too few are being addressed. Again, critical bugs are addressed immediately as an exceptional, out of process, activity.

It's only a bug if you see it twice
one of my old software managers, 1990

Feature-Driven Development

FDD combines key advantages of other agile approaches with model-centric techniques and fluid team organisation. This means that FDD easily scales to much larger teams and projects than generally recommended for other agile approaches. FDD is also characterised by an emphasis on quality throughout the process, and timely, accurate, meaningful status reporting and progress tracking for all levels of leadership.

Domain-Driven Design

Domain-Driven Design comes as a bit of a surprise to those who have been taught that agile software development and especially eXtreme Programming do away with the need for analysis and design techniques like object modeling and notations like the Unified Modeling Language (UML). It is actually very obvious that any software team working in a .Net language, Java, Objective-C, C++ or any of the object-oriented dynamic languages such as Python or Ruby has an object model at the heart of their software.

eXtreme Programming

The premise behind eXtreme Programming is that the cost of making changes to software does not need to grow exponentially more expensive throughout a project or product development life-cycle. That the cost of change does increase exponentially over-time is attributed to unnecessary complexity added early in the project product life-cycle; complexity that provides the flexibility to address all the changes that might be asked for in the future.

Follow me on Twitter...