[AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment
Upcoming SlideShare
Loading in...5
×
 

[AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment

on

  • 6,452 views

The Capability Maturity Model Integration (CMMI) has been broadly used for assessing organizational maturity and process capability throughout the world. Although most of the customers give priority ...

The Capability Maturity Model Integration (CMMI) has been broadly used for assessing organizational maturity and process capability throughout the world. Although most of the customers give priority to CMMI certified organizations over others for guaranteeing the quality, the nature of their rapid market change can no longer accept heavyweight plans, requirements specification, change requests, contract negotiation, and other documentation. Moreover, the rapid change in information technology has caused increasing the frustration more, especially that there are new competitors started using lightweight processes that invite to customer collaboration over contract negotiation and working software over comprehensive documentation that is called “Agile” methodologies that have been adopted to tackle this challenge. Agile development methods and CMMI are often perceived to be at odds with each other. In fact, it’s possible to embrace both to dramatically improve business performance. This paper focuses on the verification of implementing CMMI Project Management process areas in agile organizations based on a real and practical experience in Agile and CMMI successful projects.
The authors are going to share their practical experiences in interpreting the CMMI model's project management practices in an Agile environment to address the model intent and not compromising on the credibility or value of the practices.

From http://www.ndia.org/meetings/0110

and http://www.agilecmmi.blogspot.com

Statistics

Views

Total Views
6,452
Views on SlideShare
6,431
Embed Views
21

Actions

Likes
6
Downloads
498
Comments
2

1 Embed 21

https://twitter.com 21

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • This practival experience is quite familiar to my, since we've also been implementing CMMI in agile environment - really challenging task.
    Are you sure you want to
    Your message goes here
    Processing…
  • thank you
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

[AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment [AgileCMMI] Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment Document Transcript

  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 Practical Experience Report: Application of Project Management areas from CMMI model in an Agile development environment Author: Ahmed Mahdy Senior Software Quality Engineer, Agile Coach Raya Corporation, Egypt aamahdys@gmail.com ahmed_mahdy@rayacorp.com Reviewer: Sree Yellayi SCAMPI Lead Appraiser, SEI Authorized CMMI® Instructor, Certified Scrum Master Siemens, Greater New York City Area sree.yellayi@siemens.com sreeramamurthy@yahoo.com Abstract The Capability Maturity Model Integration (CMMI) has been broadly used for assessing organizational maturity and process capability throughout the world. Although most of the customers give priority to CMMI certified organizations over others for guaranteeing the quality, the nature of their rapid market change can no longer accept heavyweight plans, requirements specification, change requests, contract negotiation, and other documentation. Moreover, the rapid change in information technology has caused increasing the frustration more, especially that there are new competitors started using lightweight processes that invite to customer collaboration over contract negotiation and working software over comprehensive documentation that is called “Agile” methodologies that have been adopted to tackle this challenge. Agile development methods and CMMI are often perceived to be at odds with each other. In fact, it’s possible to embrace both to dramatically improve business performance. This paper focuses on the verification of implementing CMMI Project Management process areas in agile organizations based on a real and practical experience in Agile and CMMI successful projects. The authors are going to share their practical experiences in interpreting the CMMI model's project management practices in an Agile environment to address the model intent and not compromising on the credibility or value of the practices. 1
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 Agile CMMI Why Agile CMMI? Most of the promising objectives of any software development method or process are delivering working software on time, quality and budget. Software Engineering Institute (SEI) has paid a lot of efforts to mostly satisfy these objectives in its process improvement models, and version 1.3 of CMMI Development will be released soon. Nevertheless, the world becomes convinced with adding another objective, which was somehow neglected more than highly considered, which is delivering a business value to the customer. [1] Agile Scrum methodology I assume that the readers know what CMMI is, or/and has experience in its implementation. Scrum is a software development methodology that teams can adopt quickly to plan and manage their daily work. Every Scrum activity has enough detail to plan, design, build and test output, while tracking team progress. There are multiple planning levels and its strength is that it is straightforward and easy to use. The risk is that some scrum implementers may focus on generating components regardless of the complete integrated system, and this risk is managed. The paper will not go through explaining what scrum or CMMI is in detail and how to implement it, online materials are more than enough for that. Let us jump to explain how we could embrace both. CMMI Project Management process areas: Project Management process areas cover the project management activities related to planning, monitoring, and controlling the project. The Project Management process areas of CMMI are as follows: • Project Planning • Project Monitoring and Control • Integrated Project Management • Risk Management The Basic Project Management process areas address the activities related to establishing and maintaining the project plan, establishing and maintaining commitments, monitoring progress against the plan, taking corrective action, and managing supplier agreements. Project Planning The purpose of Project Planning (PP) is to establish and maintain plans that define project activities. SP CMMI Practice Agile Practice 1.1 Establish a top-level work breakdown structure (WBS) to High level user stories (i.e. the estimate the scope of the project. parent of user stories) 1.2 Establish and maintain estimates of the attributes of the Story points, used to estimate the 2
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 work products and tasks. difficulty/complexity (or relative size) of a Story (feature). 1.3 Define the project life-cycle phases upon which to scope The Scrum process. the planning effort. 1.4 Estimate the project effort and cost for the work products Scrum Ideal Time estimate (similar and tasks based on estimation rationale. to billable hours or Full-time Equivalents). 2.1 Establish and maintain the project’s budget and Scrum estimates (in Ideal Time). schedule. Estimates of what work will be in each release. Iteration Backlog. Project Task board. 2.2 Identify and analyze project risks. Iteration Retrospective 2.3 Plan for the management of project data. Project Internal Chartering 2.4 Plan for necessary resources to perform the project. Scrum estimates in Ideal Time Release plan, Iteration Backlog and assignments. 2.5 Plan for knowledge and skills needed to perform the Project Internal Chartering project. Release Planning (synchronized with the internal chartering) 2.6 Plan the involvement of identified stakeholders. Scrum process roles External and Internal Chartering 2.7 Establish and maintain the overall project plan content. Scrum release plan. Iteration Backlog. Project Taskboard. [Note: The term “plan” in CMMI refers to additional plan components (such as risks and data management) that are not called out specifically in Scrum.] 3.1 Review all plans that affect the project to understand Iteration planning meeting. project commitments. Daily Scrum meeting. 3.2 Reconcile the project plan to reflect available and Iteration planning meeting. estimated resources. Daily Scrum meeting. 3.3 Obtain commitment from relevant stakeholders Iteration planning meeting. responsible for performing and supporting plan Daily Scrum meeting. execution. [Note: The stakeholders listed in Scrum might not be the complete list 3 View slide
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 of stakeholders for the project.] The column of “Agile Practice” means either a previously defined practice in agile community or a new proposed practice that does contradict with agile principles. Project Monitoring and Control The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. SP CMMI Specific Practice Agile Practice SP1.1 Monitor the actual values of the project planning Iteration burndown chart that tracks effort parameters against the project plan. remaining. Release burndown chart that tracks completed story points. This shows how much of the product functionality is left to complete. Project Task Board used to track stories (requirements) that are done, in progress, or ones that need verification. Monitor commitments against those identified in the project plan. SP Monitor commitments against those Discussions on team commitments at the: identified in the project plan. − Daily Scrum meeting. − Iteration review meeting. • Iteration burndown chart that tracks effort remaining. • Release burndown chart that tracks story points that have been completed. This shows how much of the product functionality is left to complete. SP Monitor stakeholder involvement against the Discussions at the: project plan. − Daily Scrum meeting. − Iteration review meeting. • [Note: The stakeholders listed in Scrum might not be the complete list of stakeholders for the project, e.g., customers, other impacted teams.] Periodically review the project's progress, Daily Scrum meeting. performance, and issues. Iteration review meeting. Retrospectives. Review the accomplishments and results of the Iteration review meeting. 4 View slide
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 project at selected project milestones. Collect and analyze the issues and determine the Notes from the: corrective actions necessary to address the − Daily Scrum meeting. issues. − Iteration review meeting. [Note: Some teams track their outstanding actions on the Product Backlog. It doesn’t matter where or how the items are tracked, as long as they are.] Take corrective action on identified issues. Actions from the: − Daily Scrum meeting. − Iteration review meeting. Manage corrective actions to closure. Tracking of actions from: − Daily Scrum meeting. − Iteration review meeting. • [Note: This assumes that teams will track (and not lose) actions.] Integrated Project Management The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes. Assumption: There is an established Guidelines and Strategy of Agile Standards (GSAS) for agile projects: - Data Management Strategy - Lifecycle roadmap strategy (Agile roadmap or workflow with the connection dependencies, conditions, input/output) - People Management Plan: - Agile People Roles, Skills and Responsibilities - Any constraints SP CMMI Practice Agile Practice 1.1 Establish and maintain the project's defined process from OPF and OPD is a reference for this project startup through the life of the project. practice Project process can be stated from the internal/external chartering meetings (it can be updated with re- meeting the stakeholders throughout the work because the nature of software process is empirical) 1.2 Use the organizational process assets and measurement Given the Guidelines and Strategy of repository for estimating and planning the project’s Agile Standards: activities. Roadmap (Scope of Work) Release Planning Iteration Planning (the estimation of stories – both high 5
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 and low level) 1.3 Establish and maintain the project's work environment Given the Guidelines and Strategy of based on the organization's work environment standards. Agile Standards: List of required tools for agile or scrum activities Other requirements for work environment that are standardized in 1.4 Integrate the project plan and the other plans that affect the Project Integrated Plan which project to describe the project’s defined process. includes: Roadmap (Scope of Work over the releases) Release Plan Iteration Plan ( it’s important to integrate these plans to be synchronized due to the expected updates throughout the work) Using Rally, VersionOne, TFS 2010 or any other similar tools definitely help you in achieving that easily. 1.5 Manage the project using the project plan, the other plans Project Integrated plan that affect the project, and the project’s defined process. Review meetings that may update requirements and plans 1.6 Contribute work products, measures, and documented Iteration Retrospectives experiences to the organizational process assets. Release Retrospectives Project Lessons learned 2.1 Manage the involvement of the relevant stakeholders in the Updatable Schedule of the coming project. events (Release planning and retrospectives, Iteration planning and retrospectives, customer meetings) Roles and Responsibilities in GSAS 2.2 Participate with relevant stakeholders to identify, negotiate, Action items from standup meetings, and track critical dependencies. iteration and release retrospectives Story slicing that can show dependencies Senior Management meetings and its action items Action items should be assigned and tracked in whatever tool 2.3 Resolve issues with relevant stakeholders. The tool of action items tracking should show the status of all action items, and all issues. Results of action items’ tracking Risk Management The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives. 6
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 Important Notes: - It’s really *important* to manage your risks - Early risk identification (discovering and exploring) - Consider both internal and external chartering risks (cost, schedule, performance, technical and other risks) - Discuss any new risk - Prepare a mitigation for the identified risk with the collaboration of other stakeholders - Assign the responsibility of such mitigation actions to people - Monitor and follow up these mitigations in the agile meetings in your process - I personally prefer using any tracking tool that help you in adding/updating risks SP CMMI Practice Agile Practice 1.1 Determine risk sources and categories. Risk Categories in iteration and release retrospectives 1.2 Define the parameters used to analyze and categorize Discuss each risk in iteration and risks, and the parameters used to control the risk release retrospectives , define the management effort. parameters for risks, and not to involve the management in all risks, you can define threshold for management involvement other than the relevant risks by nature. 1.3 Establish and maintain the strategy to be used for risk Discuss the mitigation for each risk management. with the stakeholders in iteration and release retrospectives, identify assigned action items and how to monitored with due dates if possible. 2.1 Identify and document the risks. Here the call to use any tool for documenting and monitoring the risks. 2.2 Evaluate and categorize each identified risk using the Discuss and analyze each risk with defined risk categories and parameters, and determine its evaluating its defined parameters relative (priority, impact, probability and any priority. other parameter you need for your organization) 3.1 Develop a risk mitigation plan for the most important risks to Discuss the actions for each identified the project as defined by the risk management strategy. risk mitigation and plan for its follow up and handling 3.2 Monitor the status of each risk periodically and implement Iteration and release retrospective can the risk mitigation plan as appropriate. perform these actions: Update the risks with additional risks, status of old risks, status of actions and mitigations, References: [1] Neil Potter and Mary Sakry, Process Group Newsletter Volume 16 No 2, March 2009 [2] CMMI Product Team, CMMI for Development Ver 1.2, Nov 2007 [3] Agile CMMI Workshop by Ahmed Sidky, Marian Tadros, Sree Yellayi , Egypt 2008 [4] Software Process Improvement Community Meetings, Egypt 7
  • 2009 CMMI® 9th Technology Conference and User Group www.ndia.org/meetings/0110 IMPORTANT NOTES: • These practices are proposed and they may not be the best practices for your organization, • These practices are only for a proof of AgileCMMI, • Do NOT implement these proposed practices If you think there are other practices that ADD more value, • Explore more practices ! 8