This module will cover Agile tools to understand different problems faced during the software development cycle.

Software Development Methodologies

This module is an easy-to-read guide to modern Agile practices. Whether we are a C-level executive, vice president, director, manager, technical leader, or coach, this module seamlessly threads together traditional and early Agile approaches with modern Agile approaches as well as the principles and context that underlie them all. Together, these create an invaluable resource for us, our teams, and our organization.
In this module, we will learn how to respond to different challenges in software development and make a more effective team structure and culture. We'll also learn about the scrum approach and how to deal with projects in terms of quality and testing. In the end, we'll learn about organizational culture and methods of increasing productivity.

More Effective Agile: A Roadmap for Software Leaders

A clear Definition of Done (DoD) supports minimizing the gap between defect insertion and detection by ensuring that QA work on an item is performed close to all other work. 

A good DoD will include completion criteria for design, code, test, documentation, and all other work related to implementation of a requirement. Completion criteria are ideally stated in terms that are unambiguously true or false. Here is an example DoD:

Teams need to define their own Definition of Done with factors that are relevant to their circumstances. In addition to the factors shown in the example above, a Definition of Done could include:

- Product Owner accepts the item 

- Conforms to UI style guide 

- Passes acceptance tests 

- Passes performance tests 

- Passes selected regression tests 

- Code checked in 

- Requirements documentation updated

- Automated vulnerability scan passes

# Multiple Definitions of Done

Teams will need more than one Definition of Done in the following two general circumstances.

## Multiple types of DoD 

It is useful or necessary to have different DoDs for different kinds of work. For example, a DoD for code might include full regression testing, whereas a DoD for user documentation would not. Each DoD needs to define the exit criteria to the next activity and embody the principle that no more rework will be needed on an item that has met the Definition of Done.

## Multiple levels of DoD

The second circumstance that calls for multiple DoDs is when it is not possible to fully complete work in one sprint. In a combined hardware/software environment, for example, the first level Definition of Done might include passing all tests in a simulation environment but not necessarily passing on the target hardware if it is not yet available. The second-level DoD would include passing all tests on the actual target hardware. 

Similarly, if your software depends on another team’s or a contractor’s software, you might have a first-level DoD that states that all your tests pass with mock objects if the other team hasn’t yet delivered the components you depend on. The second-level DoD would then state that your tests pass with the delivered components. 

Although practical reasons exist to allow multiple-level DoDs, doing so creates a risk that “Done” doesn’t truly mean “Done” and that poor quality and additional work will accumulate in the cracks between the different definitions. It’s best to avoid this if possible.

# Evolving Definition of Done

A common issue in legacy environments is that large legacy code bases cannot instantly be transformed to meet a rigorous Definition of Done. Thus, the DoD in a legacy environment might need to initially set a lower bar than it would in a greenfield environment. As the quality level of legacy code improves, you can evolve the DoD to set an increasingly high bar.

# Common issues with Definition of Done

As your teams define and implement Definitions of Done, be aware of these common issues: 

- _DoD defines a standard that is too far from releasable_: Details can vary, but the spirit of the DoD should be that when an item is declared “done,” it can be released without any further work. 

- _DoD is too large_: A DoD checklist that’s 50 entries long will be too unwieldy to be followed by your teams, and it won’t be followed. 

- _DoD is too ambitious for legacy systems_: Avoid creating a DoD that is not possible to follow on legacy systems or that implies an amount of work greater than what has been authorized for the project. 

- _DoD describes activities rather than evidence_: A criterion like “Code has been reviewed” describes an activity. A criterion like “Code passes its code review” is evidence. 

- _Multiple-level DoDs are too relaxed_: First, beware of using multiple-level DoDs at all. If you do use them, be sure that the criteria for each level accurately capture “done” for that level.
 

 

Learn how a clear Definition of Done minimizes the gap between defect insertion and detection.

Key Principle: Create and Use a Definition of Done