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.24 Do I Need to Make Sure the Steps in My Processes Are in the Right Order?

I have observed numerous Technical Working Groups wasting valuable time arguing about the steps in a process and the order in which those steps occur. First, the CMMI defines processes as "activities that can be recognized as implementations of practices in a CMMI model." It doesn't say the order in which those activities occur must be specified.

It has been my experience that when first developing process documentation, any order dependencies should be one of the last items we worry about. I have found that TWGs can spend incredible amounts of time discussing sequence topics that turn out to be noncritical. I am not saying order is unimportant, just that often areas where we think we have order dependencies turn out to be "soft" order dependencies at best. Any "hard" order dependencies can always be added later.

A good example of order dependencies I refer to as "soft" is project planning. When I teach planning, I talk about the "what," "who," "when," "how," and "how much." There are certainly order dependencies here. I can't fully define the "who" (resources I need on the project) until I know the skills I need, which depends on the "what" I need to produce. I can't complete the "how much" it will cost until I have figured out all the other pieces to my plan because they all imply some level of cost. Nevertheless, I can provide a project plan template to be used as a great aid to help people plan without telling them which sections they must fill in before others. Such dependencies are best communicated through training, rather than captured through formal documented process descriptions.

  • + Share This
  • 🔖 Save To Your Account