- You Know You're in the Endgame When . . .
- Focus of the Book: It's Mostly About Defects
- Triage Workflow
- Repair Triage and Change Control Workflows
- Flow of the Book
This chapter is from the book
This chapter is from the book
This chapter is from the book
Repair Triage and Change Control Workflows
Let’s review the overall workflow of each phase. This will set a context or map for the topics we will cover. From the perspective of this workflow, we will be looking throughout this text at patterns, examples, and lessons. In the section after this, I offer a detailed commentary on this book’s contents.
Phase 1: Initial Defect Analysis (Low-Level Triage)
Upon initial detection, each defect goes through two steps for gathering initial information and details. The originator of the defect report fills in the complete details from his or her test or usage perspective. He or she then assigns the defect to the development lead or to a specific point resource for handling the initial triage.
The development resource reviews the defect report for reproducibility, completeness, duplication of previous reports, and overall validity. If the description information isn’t complete, it is returned to the originator for more complete information. Chapters 7 and 11 cover the basics of this early defect analysis and management.
Phase 2: High-Level Triage and Change Control Decision-Making
Once we have solid information on the defect, the cross-functional teams need to hold a decision meeting to consider the defect against the current set of defects being worked, the current release criteria, the current release plans, and the impact analysis.
Usually, basic triage and decision-making take the form of a meeting. There is a more formal version of this type of meeting, commonly referred to as a Change Control Board or CCB. The CCB meeting usually has a predefined set of attendees, which gives it a decision-making structure and a scope of change approval that encompasses defects and all substantive changes to the product (requirements, software, hardware, environment, marketing, documentation, manufacturing, and so on). CCB meetings are typically formal in structure, heavy in process weight, and sometimes slow in yielding decisions.
There are much lighter-weight equivalents of CCB meetings, where team members get together to decide what defects get repaired and what enhancements are allowed for a particular project. Such meetings are usually cross-functional but much less formal. Usually, the project manager or one of the team managers leads the decision-making effort and documents the change decisions. In doing so, he or she also focuses only on product defects and enhancements in the endgame, while the formal CCB structures can overlay the entire product life cycle.
No matter what environment or “weight” of methodology you work under, though, every endgame has a project-change decision-making team and mechanism (see Chapter 2 for more details). The team should consider the following points:
- impact on the release criteria and project focus (Chapter 3)
- all factors influencing the defect priority
- all options for resolving the defect
- workflow, packaging, and schedule timing
Once the change has been approved, the development lead will make some preliminary schedule estimates and will decide who should repair the defect. The lead will also manage work assignments through a work queue, as illustrated in Chapter 10.
Phase 3: Communication
Communicating decisions is an important part of endgame activity, especially since there are so many decisions being made in real-time, every day. This phase is strongly linked to the change control process, so it is an ongoing and constant activity. After any change control decision meeting, the following communication actions need to be taken:
- update the defect data with all relevant changes from the change control meeting
- alert the team to read the defect database for status changes. Keep all data in the database! Try not to rely on marked-up printouts, spreadsheets, or any other decentralized tracking methods.
- post the current status, schedule, progress to date, defect trends, and so on in the war room (see Chapters 13 and 14)
- publish the change control meeting minutes (see Chapter 2)
- update the Endgame Release Framework and other plans (see Chapter 4)
- issue condensed reports to upper management and outer management
Phase 4: Package Analysis
Beyond the individual defect level, your triage and change control team needs to consider the packaging of individual repairs into a release that can be tested, as I discuss in Chapter 10. Usually, this frequency target or cycle time is identified in the Endgame Release Framework (as discussed in Chapter 4) and is a part of the overall release planning for the endgame. However, it is usually only a guideline, requiring frequent adjustments as progress and discoveries are made.
Another factor that comes into play in package determination is the overall productivity of the team. How much can the development team repair and how much can the test team test to make significant progress in stabilizing the release in support of the release criteria? There is a series of balancing acts that need to be achieved in the team’s workflow (see Chapters 10 and 11 for more details).
Phase 5: Repair Scheduling
The next phase, after high-level packaging, is detailed, defect-by-defect assignment, estimation, and repair. This is the real “meat and potatoes” of the endgame activities. Your planning must precede the physical scheduling, which is performed first at the organizational or team level, then at a release framework and package level. Since you will be making repairs at one rate and finding defects at another, this is a very dynamic and iterative process. All of the following steps must be taken:
- decide on team dynamics—focused individuals or teams, multitasking teams, and level of parallel development
- develop a release framework or view and plan “packages” (see Chapters 4 and 10)
- make repair estimates, employing a consistent estimation technique (see Chapter 12)
- use work queues for defect-repair loading (see Chapter 10)
- apply consistent strategies for reducing the rate of change (see Chapter 5)
Phase 6: Construction (Repairs)
Simply put, in this phase, the software development team is frenetically making repairs. As an experienced endgame manager, I share many recommendations for repair selection and estimation because I think these are important parts of a properly orchestrated endgame (see Chapters 10, 11, and 12). The insights that may be derived from understanding the scope and complexity of individual repairs is extremely important to endgame decision-making.
Phase 7: Release and Verification
Final assembly and verification serve as closure or “loop back” for the triage and change-control defect-handling phases. The release and verification phase consists of the following activities:
- builds: frequent check-ins, frequent builds, smoke testing (see Chapter 6)
- release of the software for testing
- testing and repair verification