The great divide v2.0

  • 408 views
Uploaded on

 

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
408
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • 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.

Transcript

  • 1. The Great Life Cycle Divide Presenter: Martin L. Harbolt Session Number: 406
  • 2. Overview
    • Implementation of Agile Project Management
    • Life Cycles
      • Traditional Project Management
      • Agile Project Management
      • System Development
    • The Great Life Cycle Divide
    • Process Maturity
  • 3. The Blended Life Cycle
    • The Project
    • This diagram has all of the PMLC and SDLC Life Cycle phases represented.
    • You can not pull out what is project management vs. what is system development.
    • A challenge: Show this to your team and ask them, “Where do we do peer reviews?”. You will get different answers from different team members.
  • 4. Life Cycles
    • Life Cycles
      • Traditional Project Management
      • Agile Project Management
      • System Development
  • 5. Project Management Life Cycle Traditional(Waterfall)
    • Traditional Project Management
    • The top down approach best fits projects that have a clear definition of the end product, from the beginning of the project.
    • This approach also provides benefits for teams that are geographically disparate.
    • Many organizations that are not developing new software use this approach because they are in a sustainment or maintenance mode.
  • 6. Project Management Life Cycle Agile (SCRUM) Monitoring and Control Initiation
    • Agile Project Management
    • The agile approach best fits projects that do not have a clear definition of the end product, from the beginning of the project.
    • This approach best fits teams that are collocated and functionally diverse.
    • Legacy Project Management can be wrapped around this methodology.
    Planning Execution Close
  • 7. System Development Life Cycle
    • System Development
    • Define high level requirements and architecture
    • Elaboration on the requirements and architecture in order to obtain detailed requirements and begin building traceability.
    • Then the design activities are completed
    • Construction of the product begins and traceability to updated to include the design and construction.
    • The product is tested and defects are identified and corrected and traceability is updated with test cases .
    • The product is then implemented and a warranty period or maintenance begins.
    • Then the engineers look back on their work to define improvement opportunities for the product.
  • 8. The Great Divide
    • There are separated life cycles.
    • The Project Management on the left belongs to the project manager and his designees.
    • The System Development clearly is owned by the development team lead and his designees.
    • In all of this Monitoring and Control functions need to be applied to both sides.
      • Project Monitoring (Quality)
      • Product Monitoring (Quality)
  • 9. Side By Side
    • Initiation
    • Charter (High Level Scope)
    • Assumption/Constraints
    • High Level Requirements
    • Planning
    • Schedule (dependencies)
    • Processes to be planned
    • Execution
    • Monitoring
    • Status Reporting
    • Close
    • Lessons Learned
    • Archival
    • Estimates vs. Actual
    • Inception
    • High Level Requirement
    • Elaboration
    • Detailed Req.
    • Design
    • Detailed Design
    • Peer Reviews
    • Construction
    • Code
    • Executables
    • Peer Reviews
    • Testing
    • Test Cases
    • Req. Traceability
    • Implementation
    • Product
    • Post Imp.
    • Lessons Learned
  • 10. Process Maturity
    • Process Models (There are 3)
      • Acquisitions
      • Development
      • Services
    • Goals and Practices (there are 2)
      • Specific
      • Generic
    • 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.
  • 11. Maturity Artifacts
    • Key Artifacts
      • Project Schedule (Traditional)
      • Product and Sprint Backlog (Agile)
    • Work Breakdown Structure
      • WBS (Traditional)
      • Product Backlog (Agile)
    • Velocity / Burndown Charts
      • Easy Management Reporting
      • Measurements (Estimates vs. Actuals)
    • Earned Value
      • Traditional
        • Must be a mature organization to obtain value from Earned Value Management.
      • Agile
        • Does this bring value to the organization above and beyond what Agile reporting already provides.
  • 12. Maturity Artifacts
  • 13. Project Management Life Cycle Agile (SCRUM) Agile Project Management
  • 14. Overview of The Divide
    • Project Management —Enables the Project Manager to focus on the quality of the project.
      • Enabled the PM to focus on the management of the team and the project.
      • Enabled the PM to focus on verification of maturity artifacts.
      • Enabled the PM to focus on monitoring and control tasks.
      • Enabled the PM to focus on helping the team succeed by always understanding where the team was in the system development life cycle.
    • Engineering —Enable the project team to focus on the quality of the product.
      • Enables the BA to focus on requirements and traceability
      • Enables the engineers to focus on the design and construction aspects of the product.
      • Enables the testers to focus on building test plans and cases based on quality requirements.
      • Affords the engineers a clear view of their specific process and improvement opportunities.
  • 15. Life Cycle Division
    • Recommendations:
    • Let the team defines their process.
      • They do the work, let them.
      • Get their buy in.
    • Don’t short cut the processes.
      • Verify that the process are clearly defined as the division occurs and that no critical steps or deliverables are removed.
  • 16. Agile PM Implementation
    • Recommendations:
    • Pick a pilot project carefully.
      • Low Risk
      • Executive Sponsorship for change
    • Get Executive support (a champion).
      • This will assist when cultural issues arise.
      • Obtain training for all team members (as a team).
    • Don’t get into AgileFall.
      • Keep the processes separate so that all organizational entities can see, there IS different from traditional approaches.c
  • 17. Follow Me:
    • Ask The SCRUM Master:
    • http://askthescrummaster.blogspot.com/
    • Twitter:
    • ProfMartyScrum
  • 18. Code PaLOUsa 2011 Sponsors
  • 19. Code PaLOUsa 2011 Sponsors