In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management. These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.
The previous posts have covered the “Initiate”, “Plan”, “Iterate”, and “Control” process group of an agile project. Now I am focusing on the “Close” process group. I first want to define what I mean by that term of “process group”. Why do I use this instead of the word “phase”? Phase implies a sequence that goes more or less from one set of processes to another. In reality, after the initiate and plan process groups, an agile project actually shuttles back and forth between the “iterate” and “control” process groups. However, although a traditional or waterfall project always ends with the “Close” process group, the “close” control group in agile also refers to those activities which are done at the close of an iteration and not just of the product itself–such as the process 7.7 Process tailoring.
This process is the last of the 87 processes that John Stenbeck describes in his book. Having learned all of the agile processes, it is now time to go beyond them–meaning to incorporate processes from waterfall or traditional project management if it is warranted.
The last post will discuss hybrid projects in general, i.e., those that incorporate elements of both agile and other methodologies. This second post will cover process tailoring in order to meet the needs of the organization, and the third post will cover process tailoring in order for the organization to meet external standards.
Process tailoring, the process of tailoring an agile framework like Scrum and tailoring it to the organization’s environment, should be done, like an agile process, in iterations.
- Research existing frameworks that look like they might be a good match for the organization, based on what industry your organization is and what type of projects your organization does on a regular basis.
- Choose a framework by verifying that it has already been successfully applied in similar project environments.
- Identify which roles in the process will need to be tailored, and who will most likely take on those roles. Document these in a RACI table or other type of responsibility matrix.
- Decide how process results will be document: automated tools, traditional documents, or online documents (a wiki approach).
- Meet with stakeholders to show how the documented approach will meet their needs for communication.
- Create training program for those potential team members who will be adopting the agile framework.
This is the way to smooth the pathway for an organization with a traditional PM background to adopt agile methods.
The next post will cover how process tailoring deals with EXTERNAL, and not internal organizational standards.
Filed under: Uncategorized |
Leave a Reply