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.25 Do I Need to Make Sure Process Descriptions Are Not Redundant?

Often I hear people in TWGs arguing over whether a certain activity should be included in some process document. For example, in the technical solution TWG there was considerable discussion related to whether the design process should refer to requirements development at the start of the process. I tell working groups that it is okay to include words about an activity that might be in another process if it adds to the understanding of this process. Many processes are closely connected, such as requirements and design. Because of the way most Agile teams work—iterating closely between requirement, design, implementation, and test—it makes sense to describe this process as it is executed in your organization. This is another reason why it is best not to get too hung up on order. The traditional order of requirements followed by design followed by implementation followed by test isn't the way Agile teams work. While at a high level this view still might make sense, the activities Agile teams follow during a given day might appear to jumble this order.

The bottom line is that we want to capture the activities and products produced that relate to our processes. If it helps to describe closely related activities that are also included in another process document, it doesn't hurt to say it again.

  • + Share This
  • 🔖 Save To Your Account