Home > Articles > Process Improvement

📄 Contents

  1. 4.1 What You Will Learn in This Chapter
  2. 4.2 BOND Case Study Background
  3. 4.3 What Is a Gap Analysis and Why Is It Crucial for Agile Organizations?
  4. 4.4 Keys to Conducting a Gap Analysis for an Agile Organization
  5. 4.5 Example of "Potential Weakness" Against CMMI in an Agile Organization
  6. 4.6 Running Process Improvement like a Project
  7. 4.7 TWG Approach for Agile Organizations
  8. 4.8 Revisiting the Goal and Challenges on the Process Improvement Project
  9. 4.9 Alternative Practices and Tailored Agile TWG
  10. 4.10 Returning to the Peer Review Example
  11. 4.11 Tailored TWG Techniques and Lessons at BOND
  12. 4.12 Preparation Work for Running Agile TWGs
  13. 4.13 Packaging of Processes
  14. 4.14 An Agile Organizational Process Asset Structure
  15. 4.15 Process Asset Guidelines Used at BOND
  16. 4.16 Different Organizations with Different Process Asset Structures
  17. 4.17 Agile TWG Roles and Responsibilities
  18. 4.18 Effective Techniques to Run an Agile TWG
  19. 4.19 Separating the TWG Work from the Lead Offline Work
  20. 4.20 What Do You Do When You Find a Gap?
  21. 4.21 Answers to Common Questions When Running an Agile TWG
  22. 4.22 Do I Need a DAR Process?
  23. 4.23 Do I Need to Verify Everything I Develop?
  24. 4.24 Do I Need to Make Sure the Steps in My Processes Are in the Right Order?
  25. 4.25 Do I Need to Make Sure Process Descriptions Are Not Redundant?
  26. 4.26 Can Requirements Be Captured in an Email or PowerPoint Slides?
  27. 4.27 Do Requirements Need to Be Captured in Single "Shall Statements"?
  28. 4.28 Formalizing Informality
  29. 4.29 Summary
  30. 4.30 Summary: How Agile Helps CMMI
  • Print
  • + Share This
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


Organizational Process Definition


Organizational Training


Consolidated Management Process


Supplier Agreement Process


Consolidated Requirements Management/Development Process


Design Process


Implementation Process


Integration, Test, and Validation Process


Configuration Management Process


Quality Assurance Process


  • + Share This
  • 🔖 Save To Your Account