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.7 TWG Approach for Agile Organizations

The purpose of a TWG is to use key subject matter experts (SMEs) in the organization to help develop, document, and deploy processes and related process support assets across an organization. In observing TWGs in the past in multiple organizations, I have found common patterns I like to avoid when implementing this approach in an Agile organization. Those patterns have led to a tailoring of the TWG approach for Agile organizations, which are described in the following paragraphs.

One of the responsibilities of a TWG is addressing any potential weaknesses against the CMMI model that might have been identified. Another is to ensure the people in the organization who must use the process and supporting process assets are trained in those processes.

The primary goal is to help the organization become more successful, or maintain its current success. However, a secondary goal is to ensure that when the formal CMMI appraisal happens, the organization is prepared to demonstrate through both objective documented evidence and interviews that they have achieved the intent of the practices in the process area.

Training and process deployment are included under the responsibilities of a TWG because often in the past, these critical efforts have fallen through the cracks in many organizational process improvement efforts.

When a new process is first developed, those who were closest to its development are best equipped to provide the rationale for key decisions and share how the processes are intended to be used.

Some organizations operate as if the following myth is true:

You need to communicate the rationale for your processes. There is no one better equipped to explain why things were placed in a process than those who developed them. Too often, this critical knowledge is lost after a process development working group is disbanded. It is the rationale that leads to the needed buy-in, which is critical to ensure the organization achieves the intended value and the people are not just "going through the motions" to comply.

When you bring CMMI process maturity to an Agile organization by maintaining the Agile culture within their documented processes, you also need more—not less—training. The reason for this is that the Agile documented processes we develop will not address every possible scenario that is likely to arise in the use of the process. These processes must be supported by mentoring and on-the-job assistance especially during the period of initial deployment.

  • + Share This
  • 🔖 Save To Your Account