What are we going to talk about today. The Implementation of an Agile project management process into an enterprise entrenched in legacy processes. (Introduce this as an overarching theme for the day). We are going to talk about life cycles (Traditional Project Management, Agile PM and System Development). Then we are create The Great Life Cycle Divide. Talk about Process Maturity. Martin: Whenever I go into a company and am asked to implement an agile project management approach I get asked the same questions. How can this help us? How will it change our culture? How can we make sure we maintain our maturity certifications?
Summarize the bullet points on the slide. Talk about the team in the photo: They appear confused, When does that happen? What is that?, How did we miss that? What is going to fall on us next. Challenges: No clearly defined workflow Team members can not clearly see tasks other team members were completing. Team members have no understanding of the dependencies of tasks. Team members have no clear direction on process requirements and maturity artifacts.
There are several life cycles we are discussing so let’s break them apart. Traditional project management is known as waterfall approach. Agile project management has been tagged as kind of a cowboy approach. System development can be software development, architecture, database, etc..
The Project Management Life Cycle should address specific project related activities such as Project Initiation (defining scope), Planning (what processes need to be involved), Scheduling (where are the dependencies and how long will this take, Risk/Issue/Change Management, Customer Expectations, etc … This life cycle can be applied to several disparate project goals whether building an application or a house. This same principle and disciplines apply.
The agile approach to project management is more iterative, however you can wrap the legacy life cycle phases around an agile approach. Talk about how the traditional phases match up to steps within an agile approach. There are pitfalls to this: If you maintain the same level of documentation as a legacy approach, you will be overwhelmed with document and drag the process down with overhead. This does not institutionalize the processes as the legacy culture around the approach will continue to go back to old practices (those are institutionalized). And, Maturity Models such as CMMI require institutionalization at higher levels.
Speak to each of the phases and some deliverables from those phases. Speak to the traceability and how that grows throughout the life cycle.
Here is the process diagram that demonstrates everything that should happen in a project. Now we divide this into distinct separate processes for Project Management and System Development. The clear delineation of these life cycles becomes critical when an organization is thinking about maturity certifications such as CMMI. When considering maturity certification the organization is focusing on repeatability and continuous improvement in order to improve quality. Providing the Project Management professionals within an enterprise the chance to focus on project activities, artifacts and project process improvement, you afford them the opportunity to develop processes and procedures that best provide the results for the project. Alternatively, providing the engineering professionals within the enterprise the ability to focus on product development activities affords them the ability to refine engineering aspects for the product so they produce processes that support repeatability, process improvements and a higher quality product. The separation of the PMLC and SDLC brings intrinsic value when defining activity sequencing, accountability and maturity. Additionally, this separation of duties provides increased ability for education, mentorship and personal growth. In turn, resources can focus their talents, passions and ultimately their career on the path they desire to travel. This leads to an increase in specialty and productivity the project team and enterprise will benefit from.
Lets take this one step further. Lets look at the separate life cycle side by side. Now we can see that touch points that are critical to a coordinated project effort. The decision gates can be seen here and the PM and Engineers can both tell what tasks need to be accomplished prior to each gate. For an Agile project approach we can see here the recurring sprints and how the decision gates demonstrate those tasks that happen over and over for each sprint. It is an inspiring moment when a PM walks through this type of a diagram with the team. As they speak to each of the phases, touch points, decision gates and deliverables. You can see the eyes light up and watch the team gain an better understanding of the overall process and their role in that process. WoW Moment!
Talk about the models (There are 3) Acquisitions Development Services Talk about the goals and practices (there are 2) Specific – Specific goals are goals that are specific to a process area Generic – Generic goals are goals that apply to all process areas (common behaviors) Talk about the process areas (there are 22) Measurements and Analysis (MA) Integrated Project Management (IPM) Process and Product Quality Assurance (PPQA) Risk Management (RSKM) Etc. Talk about the artifacts required for process maturity This slide will talk about the CMMI aspect of the separation of the life cycles and some best practices. Talk about the artifacts.
One of the key artifacts when talking about maturity is the project schedule. Many goals and practices (both specific and generic) can be satisfied with this artifact. This can prove that you defined the project life cycle (PP SP1.3), Plan for project resources (PP SP2.4), establish work products and task attributes (PP SP 1.2) and many others. For Agile projects the product backlog satisfies these same goals and practices as well. In the schedule you assign resources, same as the product backlog, the product backlog defines dependencies as well as establishes the scope of the project and provides a mechanism for monitoring stakeholder involvement and managing budget and schedule. Additionally, the product and sprint backlogs along with the Velocity Charts track estimated effort vs. actual effort very clearly and provides easy mechanisms for status reporting and stakeholder involvement. Earned Value: For traditional project management, Earned Value is beneficial if the organization is mature enough to use the data throughout the PMLC and across the enterprise for project progress monitoring. Many organizations calculate Earned Value, It’s how that data is used that is critical. For Agile project management, Each organization needs to define if there is any additional benefit above and beyond the standard reporting mechanisms that agile already provides. So, How the Earned Value Data is going to be used by the enterprise becomes and critical decision point.
Lets take this one step further. Lets look at the separate life cycle side by side. Now we can see that touch points that are critical to a coordinated project effort. The decision gates can be seen here and the PM and Engineers can both tell what tasks need to be accomplished prior to each gate. For an Agile project approach we can see here the recurring sprints and how the decision gates demonstrate those tasks that happen over and over for each sprint. It is an inspiring moment when a PM walks through this type of a diagram with the team. As they speak to each of the phases, touch points, decision gates and deliverables. You can see the eyes light up and watch the team gain an better understanding of the overall process and their role in that process. WoW Moment!
The agile approach to project management is more iterative, however you can wrap the legacy life cycle phases around an agile approach. Talk about how the traditional phases match up to steps within an agile approach. There are pitfalls to this: If you maintain the same level of documentation as a legacy approach, you will be overwhelmed with document and drag the process down with overhead. This does not institutionalize the processes as the legacy culture around the approach will continue to go back to old practices (those are institutionalized). And, Maturity Models such as CMMI require institutionalization at higher levels.
![Overview ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)