- 4.1 What You Will Learn in This Chapter
- 4.2 BOND Case Study Background
- 4.3 What Is a Gap Analysis and Why Is It Crucial for Agile Organizations?
- 4.4 Keys to Conducting a Gap Analysis for an Agile Organization
- 4.5 Example of "Potential Weakness" Against CMMI in an Agile Organization
- 4.6 Running Process Improvement like a Project
- 4.7 TWG Approach for Agile Organizations
- 4.8 Revisiting the Goal and Challenges on the Process Improvement Project
- 4.9 Alternative Practices and Tailored Agile TWG
- 4.10 Returning to the Peer Review Example
- 4.11 Tailored TWG Techniques and Lessons at BOND
- 4.12 Preparation Work for Running Agile TWGs
- 4.13 Packaging of Processes
- 4.14 An Agile Organizational Process Asset Structure
- 4.15 Process Asset Guidelines Used at BOND
- 4.16 Different Organizations with Different Process Asset Structures
- 4.17 Agile TWG Roles and Responsibilities
- 4.18 Effective Techniques to Run an Agile TWG
- 4.19 Separating the TWG Work from the Lead Offline Work
- 4.20 What Do You Do When You Find a Gap?
- 4.21 Answers to Common Questions When Running an Agile TWG
- 4.22 Do I Need a DAR Process?
- 4.23 Do I Need to Verify Everything I Develop?
- 4.24 Do I Need to Make Sure the Steps in My Processes Are in the Right Order?
- 4.25 Do I Need to Make Sure Process Descriptions Are Not Redundant?
- 4.26 Can Requirements Be Captured in an Email or PowerPoint Slides?
- 4.27 Do Requirements Need to Be Captured in Single "Shall Statements"?
- 4.28 Formalizing Informality
- 4.29 Summary
- 4.30 Summary: How Agile Helps CMMI
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.13 Packaging of Processes
Processes do not need to align one for one with CMMI PAs. Many organizations do this, but it is not necessary. This decision is best made based on how you do real work in your organization. You don't need to make the final decision for process packaging at the start of your process improvement effort. In fact, the brainstorming within TWGs may lead to the identification of processes that should be broken out separately, and processes that should be consolidated.
At BOND, the Technical Solution (TS) TWG broke out two distinct processes referred to as Design and Implementation. Verification and Validation were consolidated into one process, which is common in Agile organizations because the practices Agile organizations use for Verification and Validation tend to have significant overlap. This is because a common Agile technique is to develop complete slices of functionality in short increments, often leading to product demonstrations to the customer. As a result, Verification and Validation techniques tend to blend in such environments.
There was significant discussion over Project Planning (PP) and Project Monitor and Control (PMC) at BOND. The TWG ended up keeping these processes separate, although in other Agile organizations I have seen these consolidated. The factors to consider when making the decision to keep PP and PMC separate versus consolidating include the maturity of your organization's planning and project management activities.
In organizations where the project planning, monitoring, and control activities are sound and institutionalized, it can be more efficient to consolidate and train these processes together. This is because the expected practices under PMC align closely with those under PP and therefore can naturally be packaged and trained together. PMC expected practices revolve around monitoring and taking appropriate action associated with each of the items in your project plan. However, if your organization is just learning how to develop a project plan, it might be more effective to maintain distinct processes so each gets its proper focus.
Risk Management (RSKM) is usually broken out into its own process area, although in implementation in most Agile organizations it is frequently integrated with project planning, monitoring, and control. For example, most Agile organizations do not have distinct risk management review boards. The risk management reporting is usually integrated with project monitor, control, and reporting to Senior Management. Refer to Table 4-2 for an example of an Agile organization's eleven process descriptions and how they could provide coverage for all eighteen CMMI level 2 and 3 process areas.
Table 4-2. Example Agile Organization Processes and CMMI Process Area Coverage
|
Sample Agile Organizational Processes |
CMMI Level 2 and 3 Process Area Coverage |
|
Organizational Process Focus |
OPF |
|
Organizational Process Definition |
OPD |
|
Organizational Training |
OT |
|
Consolidated Management Process |
PP, PMC, RSKM, IPM, DAR, MA |
|
Supplier Agreement Process |
SAM |
|
Consolidated Requirements Management/Development Process |
REQM, RD |
|
Design Process |
TS, DAR |
|
Implementation Process |
TS |
|
Integration, Test, and Validation Process |
VER, VAL, PI |
|
Configuration Management Process |
CM |
|
Quality Assurance Process |
QA |