- 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.14 An Agile Organizational Process Asset Structure
The subject of organizational process asset structure has received a great deal of attention. I have heard the following myth expressed by Agile proponents:
"Superstructure" means multiple types and tiers of process assets. This myth continues to exist not because of anything the CMMI requires, but because of the way in which many large organizations have chosen to implement their process assets in the past.
As an example, it is not uncommon in many large high-tech companies to see four levels (or tiers) of process assets such as policies, processes/practices, work instructions/procedures, and enablers/templates. Policies identify the organization's expectations for establishing and maintaining the process. Processes or practices are often high-level process descriptions whereas work instructions/procedures provide more detailed steps related to the process. Enablers and templates can be any kind of process aid that helps carry out the process and can include tool guides, or templates to help build related documentation.
While the choice for a process asset structure is up to each organization, most Agile organizations I have helped have found that two tiers is sufficient. This is accomplished by consolidating a policy statement with the associated process description that encapsulates "what must be done" in carrying out the process. The second tier contains "how to" guidelines in carrying out the process and tailoring it. This level can be viewed as aids for tailoring the process, and usually includes supporting templates. I have found that in most Agile organizations, step-by-step procedures are replaced by tool guides and training/mentoring. It is worth noting here that a template, such as a Project Management Plan template, can serve as a process with the required process activities implied within the template.10 This is a common technique I have observed for developing effective Agile process descriptions. See Figure 4-1 for a comparison of a traditional11 and Agile organizational process asset structure.
)
Figure 4-1 Traditional (Sometimes) and Agile Organizational Process Asset Structure
Key Recommendation for Agile Organizations in Support of Tailoring
While decisions on process asset structure are up to each organization, there is one key related recommendation I make to Agile organizations. This recommendation was used successfully at BOND. I will state it in the form of a lesson:
The reason for this recommendation relates to a major concern that management and independent appraisers often hold—the fear that an Agile approach will lead to loss of project control. This ties to a popular myth:
It has been my experience that organizations that understand and implement Agile practices appropriately tend to be more disciplined12 in their development and management practices than many traditional development organizations. This is because they believe in their practices and therefore gravitate to them in times of crisis rather than abandoning them, as many more traditional organizations who don't really embrace their practices tend to do. The evidence of this often surfaces with the fervor that can be sensed during the interview process when conducting a gap analysis or a more formal appraisal inside an Agile organization. In organizations in which compliance is achieved more through a "policing" approach, I have often found this same fervor and belief in the process missing.
Regardless of this observation, Agile organizations must still deal with the common perception that they don't follow sound practices, and to be honest, many organizations that claim to be Agile are in fact using the term as a smoke screen to not comply and thus add to this perception.13
Following the recommendation in Lesson 3 prepares the organization to deal objectively with this perception by simplifying the tailoring process and making the "must dos" clear and visible to all. A fundamental implication of Lesson 3 is that no one tailors the "must do" practices. Everyone follows them. Hopefully, the reader is starting to appreciate the importance of establishing such rules early before the TWGs develop the processes. If you follow this recommended lesson, the TWGs must carefully consider what they agree to place in the process "must do" packages because this must make sense for all projects regardless of size or scale. Refer to Figure 4-2.
)
Figure 4-2 Tailoring and Process Asset Structure
When you take this approach, which works well for organizations with Agile cultures, tailoring the process is integrated with project planning. Tailoring guidelines are used during project planning to make "how to" project specific decisions, such as decisions related to the use of certain tools. Since these guidelines are packaged separately from the process "must dos," the process becomes very clear on what you are allowed to tailor and what must never be tailored.
By following this guidance, the visibility of compliance to the process becomes more evident in an Agile organization, not less. Fuzzy tailoring guidelines are now removed. It is for this reason I often make the claim that if you follow my guidance in the tailoring area when moving an organization with an Agile culture forward toward increased CMMI process maturity, you will find you have an increase in control rather than the loss of control that many falsely believe occurs in Agile organizations.