This document discusses blending agile development methods with the CMMI framework. It begins by outlining two common myths about agile development and CMMI - that agile is undisciplined and CMMI is outdated. The document argues that with the right understanding, agile and CMMI can be philosophically compatible. It then provides an overview of agile methods like Extreme Programming and Scrum and the goals of CMMI. The rest of the document discusses how to map agile practices to CMMI process areas and provides examples of how an XP-inspired process could fulfill the requirements of CMMI level 2 processes like requirements management and project planning. It cautions that this mapping represents a minimum effort
1. The document discusses implementing the Capability Maturity Model Integration (CMMI) framework at El Sewedy Cables to improve its software development processes. It recommends defining the company's current CMMI level and then implementing requirements to advance to higher levels over several steps.
2. For information and communications technology (ICT), it suggests selecting a software development paradigm, applying key software development activities, and documenting business cycles and projects. Activities like testing, integration, and maintenance need improvement while others are missing.
3. Implementing these changes could take 6-9 months to help IT become more competitive internationally by adopting CMMI best practices for requirements management, project planning, and other process areas.
This document provides an overview and introduction to implementing the Capability Maturity Model Integration (CMMI) framework. It discusses initiating CMMI implementation, including understanding an organization's current business and processes to determine if CMMI is needed and gaining internal commitment. It also covers initial discussions with CMMI subject matter experts to plan the implementation. The document provides high-level information on CMMI components like representations, maturity levels, and process areas to help organizations approach CMMI implementation practically and successfully.
The document introduces the Capability Maturity Model (CMM) which describes five levels of software process maturity. It uses an analogy comparing little league and professional baseball teams to represent low and high maturity organizations. Little league teams operate chaotically while professional teams have well-defined, coordinated processes. CMM aims to help software organizations improve their processes and become more "mature" like professional teams. The five levels progress from initial/ad-hoc processes to optimized, continuously improving processes. The document also discusses some common criticisms of CMM such as it being used only as a certification stamp.
So WHY invest in better project management and process improvement? This paper points to the answer. The lessons are very powerful. Cut defects and costs by 60%. Read on ...
The business case for software process improvement may also be the business case for project management - in as much as CMMi process improvement implements the fundamentals of project management. This paper leverages work done by Larry Putnam, Stan Rifkin and Joe Kolinger in applying metrics to understand productivity and cost improvements in technology projects.
The document introduces the Capability Maturity Model (CMM) for software development. It discusses that CMM provides a framework for improving software processes through defined maturity levels. It describes the five maturity levels and the 18 key process areas addressed at each level, which are focused on establishing disciplined and measurable software processes. The ultimate goal of CMM is to help organizations achieve continuous process improvement.
This is the second upload of the book "The Story of Tahini-Tahini: Software Process Improvement with Agile Methods and Maturity Models". We are seeking help to find mistakes and perfect the book.
Maturity Models have been around for some time. There is the well known Capability Maturity Model of the Software Engineering Institute, a building Architecture Maturity Model, an Enterprise Architecture (EA) Maturity Model, an Acquisition Maturity Model, many business process maturity models and – PMI’s Organizational Project Management Maturity Model OPM3™.
1. The document discusses implementing the Capability Maturity Model Integration (CMMI) framework at El Sewedy Cables to improve its software development processes. It recommends defining the company's current CMMI level and then implementing requirements to advance to higher levels over several steps.
2. For information and communications technology (ICT), it suggests selecting a software development paradigm, applying key software development activities, and documenting business cycles and projects. Activities like testing, integration, and maintenance need improvement while others are missing.
3. Implementing these changes could take 6-9 months to help IT become more competitive internationally by adopting CMMI best practices for requirements management, project planning, and other process areas.
This document provides an overview and introduction to implementing the Capability Maturity Model Integration (CMMI) framework. It discusses initiating CMMI implementation, including understanding an organization's current business and processes to determine if CMMI is needed and gaining internal commitment. It also covers initial discussions with CMMI subject matter experts to plan the implementation. The document provides high-level information on CMMI components like representations, maturity levels, and process areas to help organizations approach CMMI implementation practically and successfully.
The document introduces the Capability Maturity Model (CMM) which describes five levels of software process maturity. It uses an analogy comparing little league and professional baseball teams to represent low and high maturity organizations. Little league teams operate chaotically while professional teams have well-defined, coordinated processes. CMM aims to help software organizations improve their processes and become more "mature" like professional teams. The five levels progress from initial/ad-hoc processes to optimized, continuously improving processes. The document also discusses some common criticisms of CMM such as it being used only as a certification stamp.
So WHY invest in better project management and process improvement? This paper points to the answer. The lessons are very powerful. Cut defects and costs by 60%. Read on ...
The business case for software process improvement may also be the business case for project management - in as much as CMMi process improvement implements the fundamentals of project management. This paper leverages work done by Larry Putnam, Stan Rifkin and Joe Kolinger in applying metrics to understand productivity and cost improvements in technology projects.
The document introduces the Capability Maturity Model (CMM) for software development. It discusses that CMM provides a framework for improving software processes through defined maturity levels. It describes the five maturity levels and the 18 key process areas addressed at each level, which are focused on establishing disciplined and measurable software processes. The ultimate goal of CMM is to help organizations achieve continuous process improvement.
This is the second upload of the book "The Story of Tahini-Tahini: Software Process Improvement with Agile Methods and Maturity Models". We are seeking help to find mistakes and perfect the book.
Maturity Models have been around for some time. There is the well known Capability Maturity Model of the Software Engineering Institute, a building Architecture Maturity Model, an Enterprise Architecture (EA) Maturity Model, an Acquisition Maturity Model, many business process maturity models and – PMI’s Organizational Project Management Maturity Model OPM3™.
The document discusses the history and relationships between several process improvement methodologies: Agile, CMMI, Lean Six Sigma, and their DMAIC roadmap. It argues that while many organizations employ one of these methods, few combine all three in a synergistic way despite the benefits. The document examines how the DMAIC roadmap aligns with the key Measurement and Analysis process area of CMMI, noting they can be combined effectively to establish objectives, measures, analysis procedures, and implement improvements.
Lightweight processes are beginning to replace more formal methods. The motivation for this transition is based on many factors. The Internet, time to market, cost reduction, quality increases, market pressures, as well as the popularization of these programming methods. This series of articles will investigate the various lightweight methods, their impact on the management of software development projects and the processes by which managers can determine the appropriateness and usefulness of
the various processes.
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGYcscpconf
Agility is bringing in responsibility and ownership in individuals, which will eventually bring out effectiveness and efficiency in deliverables. Companies are drifting from traditional Software Development Life Cycle models to Agile Environment for the purpose of attaining quality and for the sake of saving cost and time. In Traditional models, life cycle is properly defined and also phases are elaborated by specifying needed input and output parameters. On the other hand, in Agile environment, phases are specific to methodologies of Agile - Extreme
Programming etc. In this paper a common life cycle approach is proposed that is applicable for different kinds of methods. This paper also aims to describe a mapping function for mapping of traditional methods to Agile methods.
Mapping of traditional software development methods to agile methodologycsandit
Agility is bringing in responsibility and ownership in individuals, which will eventually bring
out effectiveness and efficiency in deliverables. Companies are drifting from traditional
Software Development Life Cycle models to Agile Environment for the purpose of attaining
quality and for the sake of saving cost and time. In Traditional models, life cycle is properly
defined and also phases are elaborated by specifying needed input and output parameters. On
the other hand, in Agile environment, phases are specific to methodologies of Agile - Extreme
Programming etc. In this paper a common life cycle approach is proposed that is applicable for
different kinds of methods. This paper also aims to describe a mapping function for mapping of
traditional methods to Agile methods
This document outlines an asset management maturity continuum that progresses from reactive to proactive approaches. It shows increasing levels of optimization from minimal performance tracking up to enterprise-wide asset management integration. Key aspects that progress along the continuum include governance, systems/technology, processes, people/performance measures. The goal is to move from "fix it after it fails" approaches to preventative, predictive and reliability-focused asset management.
Failed ECM implementations typically stem from underestimating impacts to business processes, poor user training, and lack of governance over the project, not issues with the technology itself. Replacing a failed ECM system can easily double the total cost due to additional expenses like converting data, retraining users, and convincing users the new system won't fail. Careful vendor selection and thorough implementation planning are critical to avoid costly ECM implementation failures and replacements.
This document provides an introduction to the concepts and methodology of Six Sigma. It discusses how Six Sigma originated from efforts to improve quality at Motorola and other companies in the 1980s-1990s. Six Sigma aims to reduce defects to 3.4 per million opportunities through a data-driven approach to process improvement. The DMAIC methodology involves defining a process problem, measuring key aspects, analyzing sources of variation, improving the process, and controlling changes. Wide adoption of Six Sigma led to significant financial benefits and quality improvements for early adopters like Motorola, GE, and Allied Signal.
Six Sigma as a Quality and Continuous Improvement Strategyvivatechijri
As Global competition hikes, Quality become the highest priority in today manufacturing world.
Competitiveness, innovation and performance are the key words that best define the goals of this business
environment. Under the given circumstance concepts like quality and continuous improvement become important
actors in achieving these goals. These programs were instituted within the 1980s and early 1990s as response to
the “economic growth and manufacturing dominance of Japanese industries”. Most of these programs, are “Justin-Time (JIT), Total Quality Management (TQM), KAIZEN, Poka-yoke” were based partly on the tenets and
results of the Toyota Production System (TPS) that was established in an evolutionary manner since the 1950s
through the work of W. Edwards Deming and Taiichi Ohno. for many years, TQM has been a dominant
management concept for improving competitiveness and financial results. In recent years, however TQM seems
to have lost variety of its nimbus with other concepts and approaches like Lean Enterprise and Six sigma launched
and increasingly stylish. These aims of this paper is to clarify that sigma could also be alternative for its
predecessor i.e. TQM and their similarities and differences to sort out whether the two ideas truly are various
dishes or contain the indistinguishable fixings in various.
This document discusses the cost of poor quality (COPQ) in the automobile industry. It begins by defining COPQ as all the costs that would disappear if the manufacturing process was perfect, including appraisal, prevention, and failure costs. The industry average COPQ is about 20% of sales. The document then examines various quality cost models like the P-A-F model and activity-based costing approaches. It also discusses Taguchi's quality loss function and Six Sigma frameworks. Overall, the key points made are that reducing COPQ through continuous improvement tools like Six Sigma can significantly increase profits for automobile companies.
The document describes the Dynamic System Development Method (DSDM) framework. It discusses DSDM's 9 principles, which include active user involvement, empowering teams to make decisions, and iterative and incremental development. It outlines the typical project structure in DSDM, including roles like project manager, team leader, and user ambassador. Projects follow a 7 phase process including feasibility study, business study, and iterative development phases. Core techniques recommended in DSDM are also described, such as timeboxing, prioritization rules, prototyping, and workshops.
Resending a small update on an "accessible IT Strategy for Software Development" (People, Process, Technology, Execution, Delivery with Governance). I.e. No more playing games with fragile (or aino - agile in name only) fit for use for Capability Maturity Level 1 only. Rather this presentation pins down Agile and Scrum method with DevOps and underpinned by ITIL 4 operated at CM Level 2+!
The document discusses Just-in-Time (JIT) and Lean manufacturing models and why they cannot be effectively implemented in Egyptian organizations. It outlines the key elements and requirements of JIT, including eliminating waste, continuous improvement, total quality management, parallel processing, Kanban production control, JIT purchasing, step-up reduction, and repetitive manufacturing. However, the author argues that JIT is not suitable for Egypt due to its heavy reliance on organizational leadership commitment, resources, and human factors that are difficult to achieve given Egyptian culture and circumstances.
Presenting this set of slides with name - Product Lifecycle Management Powerpoint Presentation Slides. This deck consists of total of twenty four slides. It has PPT slides highlighting important topics of Product Lifecycle Management Powerpoint Presentation Slides. This deck comprises of amazing visuals with thoroughly researched content. Each template is well crafted and designed by our PowerPoint experts. Our designers have included all the necessary PowerPoint layouts in this deck. From icons to graphs, this PPT deck has it all. The best part is that these templates are easily customizable. Just click the DOWNLOAD button shown below. Edit the colour, text, font size, add or delete the content as per the requirement. Download this deck now and engage your audience with this ready made presentation.
Analysis of applying TRIZ in and on a Large Scale System - SemiconductorsRichard Platt
An analysis of applying TRIZ towards a engineering system (semiconductor technology) and the necessary process factors and issues that were found and resolved as a part of the implementation of the TRIZ methodology at Intel, including a methodology for designing innovation methods into the design for manufacturability process
1) Many change initiatives fail because stakeholders are not satisfied with the results or the organization fails to recoup its investment. Studies show remarkably consistent failure rates across industries and organization sizes.
2) For change to succeed, there must be dissatisfaction with the current state, a clear vision for the future, a clear implementation plan, and low resistance to change. Leaders must not be blinded by their vision and underestimate resistance.
3) A formula developed by Gleicher suggests change will succeed if dissatisfaction with the current state (D) and clarity of the vision (V) and implementation plan (F) outweigh resistance to change (R). Both leadership and individual commitment are important.
The document discusses various topics related to software engineering including:
1) The fundamental activities in the software development process like planning, analysis, design, implementation, testing and maintenance.
2) The different phases of the Rational Unified Process including inception, elaboration, construction and transition.
3) The drawbacks of the spiral model including high costs, expertise required for risk analysis, and poor fit for smaller projects.
CMMI is a framework of best practices which is stand for Capability Maturity Model Integration. CMMI-DEV is the current version which describesthe best practices in measuring, managing and monitoring software development process.
The document provides an overview of the Capability Maturity Model Integration (CMMI). It discusses key aspects of CMMI including its focus on process improvement, the two representations (staged and continuous), maturity/capability levels, process areas, and components such as goals and practices. It compares CMMI to its predecessor models and explains how CMMI integrates multiple disciplines like systems engineering, software engineering, and integrated product development.
The document discusses the history and relationships between several process improvement methodologies: Agile, CMMI, Lean Six Sigma, and their DMAIC roadmap. It argues that while many organizations employ one of these methods, few combine all three in a synergistic way despite the benefits. The document examines how the DMAIC roadmap aligns with the key Measurement and Analysis process area of CMMI, noting they can be combined effectively to establish objectives, measures, analysis procedures, and implement improvements.
Lightweight processes are beginning to replace more formal methods. The motivation for this transition is based on many factors. The Internet, time to market, cost reduction, quality increases, market pressures, as well as the popularization of these programming methods. This series of articles will investigate the various lightweight methods, their impact on the management of software development projects and the processes by which managers can determine the appropriateness and usefulness of
the various processes.
MAPPING OF TRADITIONAL SOFTWARE DEVELOPMENT METHODS TO AGILE METHODOLOGYcscpconf
Agility is bringing in responsibility and ownership in individuals, which will eventually bring out effectiveness and efficiency in deliverables. Companies are drifting from traditional Software Development Life Cycle models to Agile Environment for the purpose of attaining quality and for the sake of saving cost and time. In Traditional models, life cycle is properly defined and also phases are elaborated by specifying needed input and output parameters. On the other hand, in Agile environment, phases are specific to methodologies of Agile - Extreme
Programming etc. In this paper a common life cycle approach is proposed that is applicable for different kinds of methods. This paper also aims to describe a mapping function for mapping of traditional methods to Agile methods.
Mapping of traditional software development methods to agile methodologycsandit
Agility is bringing in responsibility and ownership in individuals, which will eventually bring
out effectiveness and efficiency in deliverables. Companies are drifting from traditional
Software Development Life Cycle models to Agile Environment for the purpose of attaining
quality and for the sake of saving cost and time. In Traditional models, life cycle is properly
defined and also phases are elaborated by specifying needed input and output parameters. On
the other hand, in Agile environment, phases are specific to methodologies of Agile - Extreme
Programming etc. In this paper a common life cycle approach is proposed that is applicable for
different kinds of methods. This paper also aims to describe a mapping function for mapping of
traditional methods to Agile methods
This document outlines an asset management maturity continuum that progresses from reactive to proactive approaches. It shows increasing levels of optimization from minimal performance tracking up to enterprise-wide asset management integration. Key aspects that progress along the continuum include governance, systems/technology, processes, people/performance measures. The goal is to move from "fix it after it fails" approaches to preventative, predictive and reliability-focused asset management.
Failed ECM implementations typically stem from underestimating impacts to business processes, poor user training, and lack of governance over the project, not issues with the technology itself. Replacing a failed ECM system can easily double the total cost due to additional expenses like converting data, retraining users, and convincing users the new system won't fail. Careful vendor selection and thorough implementation planning are critical to avoid costly ECM implementation failures and replacements.
This document provides an introduction to the concepts and methodology of Six Sigma. It discusses how Six Sigma originated from efforts to improve quality at Motorola and other companies in the 1980s-1990s. Six Sigma aims to reduce defects to 3.4 per million opportunities through a data-driven approach to process improvement. The DMAIC methodology involves defining a process problem, measuring key aspects, analyzing sources of variation, improving the process, and controlling changes. Wide adoption of Six Sigma led to significant financial benefits and quality improvements for early adopters like Motorola, GE, and Allied Signal.
Six Sigma as a Quality and Continuous Improvement Strategyvivatechijri
As Global competition hikes, Quality become the highest priority in today manufacturing world.
Competitiveness, innovation and performance are the key words that best define the goals of this business
environment. Under the given circumstance concepts like quality and continuous improvement become important
actors in achieving these goals. These programs were instituted within the 1980s and early 1990s as response to
the “economic growth and manufacturing dominance of Japanese industries”. Most of these programs, are “Justin-Time (JIT), Total Quality Management (TQM), KAIZEN, Poka-yoke” were based partly on the tenets and
results of the Toyota Production System (TPS) that was established in an evolutionary manner since the 1950s
through the work of W. Edwards Deming and Taiichi Ohno. for many years, TQM has been a dominant
management concept for improving competitiveness and financial results. In recent years, however TQM seems
to have lost variety of its nimbus with other concepts and approaches like Lean Enterprise and Six sigma launched
and increasingly stylish. These aims of this paper is to clarify that sigma could also be alternative for its
predecessor i.e. TQM and their similarities and differences to sort out whether the two ideas truly are various
dishes or contain the indistinguishable fixings in various.
This document discusses the cost of poor quality (COPQ) in the automobile industry. It begins by defining COPQ as all the costs that would disappear if the manufacturing process was perfect, including appraisal, prevention, and failure costs. The industry average COPQ is about 20% of sales. The document then examines various quality cost models like the P-A-F model and activity-based costing approaches. It also discusses Taguchi's quality loss function and Six Sigma frameworks. Overall, the key points made are that reducing COPQ through continuous improvement tools like Six Sigma can significantly increase profits for automobile companies.
The document describes the Dynamic System Development Method (DSDM) framework. It discusses DSDM's 9 principles, which include active user involvement, empowering teams to make decisions, and iterative and incremental development. It outlines the typical project structure in DSDM, including roles like project manager, team leader, and user ambassador. Projects follow a 7 phase process including feasibility study, business study, and iterative development phases. Core techniques recommended in DSDM are also described, such as timeboxing, prioritization rules, prototyping, and workshops.
Resending a small update on an "accessible IT Strategy for Software Development" (People, Process, Technology, Execution, Delivery with Governance). I.e. No more playing games with fragile (or aino - agile in name only) fit for use for Capability Maturity Level 1 only. Rather this presentation pins down Agile and Scrum method with DevOps and underpinned by ITIL 4 operated at CM Level 2+!
The document discusses Just-in-Time (JIT) and Lean manufacturing models and why they cannot be effectively implemented in Egyptian organizations. It outlines the key elements and requirements of JIT, including eliminating waste, continuous improvement, total quality management, parallel processing, Kanban production control, JIT purchasing, step-up reduction, and repetitive manufacturing. However, the author argues that JIT is not suitable for Egypt due to its heavy reliance on organizational leadership commitment, resources, and human factors that are difficult to achieve given Egyptian culture and circumstances.
Presenting this set of slides with name - Product Lifecycle Management Powerpoint Presentation Slides. This deck consists of total of twenty four slides. It has PPT slides highlighting important topics of Product Lifecycle Management Powerpoint Presentation Slides. This deck comprises of amazing visuals with thoroughly researched content. Each template is well crafted and designed by our PowerPoint experts. Our designers have included all the necessary PowerPoint layouts in this deck. From icons to graphs, this PPT deck has it all. The best part is that these templates are easily customizable. Just click the DOWNLOAD button shown below. Edit the colour, text, font size, add or delete the content as per the requirement. Download this deck now and engage your audience with this ready made presentation.
Analysis of applying TRIZ in and on a Large Scale System - SemiconductorsRichard Platt
An analysis of applying TRIZ towards a engineering system (semiconductor technology) and the necessary process factors and issues that were found and resolved as a part of the implementation of the TRIZ methodology at Intel, including a methodology for designing innovation methods into the design for manufacturability process
1) Many change initiatives fail because stakeholders are not satisfied with the results or the organization fails to recoup its investment. Studies show remarkably consistent failure rates across industries and organization sizes.
2) For change to succeed, there must be dissatisfaction with the current state, a clear vision for the future, a clear implementation plan, and low resistance to change. Leaders must not be blinded by their vision and underestimate resistance.
3) A formula developed by Gleicher suggests change will succeed if dissatisfaction with the current state (D) and clarity of the vision (V) and implementation plan (F) outweigh resistance to change (R). Both leadership and individual commitment are important.
The document discusses various topics related to software engineering including:
1) The fundamental activities in the software development process like planning, analysis, design, implementation, testing and maintenance.
2) The different phases of the Rational Unified Process including inception, elaboration, construction and transition.
3) The drawbacks of the spiral model including high costs, expertise required for risk analysis, and poor fit for smaller projects.
CMMI is a framework of best practices which is stand for Capability Maturity Model Integration. CMMI-DEV is the current version which describesthe best practices in measuring, managing and monitoring software development process.
The document provides an overview of the Capability Maturity Model Integration (CMMI). It discusses key aspects of CMMI including its focus on process improvement, the two representations (staged and continuous), maturity/capability levels, process areas, and components such as goals and practices. It compares CMMI to its predecessor models and explains how CMMI integrates multiple disciplines like systems engineering, software engineering, and integrated product development.
The document provides an overview of the Capability Maturity Model Integration (CMMI) framework. It discusses the key concepts of CMMI including the reasons for focusing on software processes, the structure and components of the CMMI model, and the different maturity levels. The summary highlights the five maturity levels within CMMI and some of the process areas associated with each level.
The three-day workshop introduces participants to the fundamental concepts of the CMMI model and assists companies in integrating best practices from proven process improvement models. The workshop uses lectures, exercises, and discussions to help participants understand the CMMI framework, requirements of process areas, make valid judgments about process implementation, and identify issues to address in process improvements. The agenda covers CMMI basics and process areas at different maturity levels.
The three-day course, "Introduction to CMMI", introduces participants to the fundamental concepts of the CMMI model. The course assists companies in integrating best practices from proven discipline-specific process improvement models, including systems engineering, software engineering, integrated product and process development and supplier sourcing.
The course is composed of lectures and class exercises with ample opportunity for participant questions and discussions. After attending the course, participants will be able to describe the components of CMMI, discuss the process areas in CMMI, and locate relevant information in the model.
The workshop will help the participants to:
Understand the CMMI framework
Understand the detailed requirements of the process areas in the CMMI V1.3
Make valid judgments regarding the organization's implementation of process areas
Identify issues that should be addressed in performing process improvements using the CMMI V1.3
Software Configuration Management into a CMMI Level 1 Projectelliando dias
This document discusses introducing software configuration management (SCM) into a project at CMMI Level 1 maturity. It describes how Level 1 projects typically lack uniform processes and feel chaotic. The document provides an overview of SCM and guidelines for beginning SCM implementation, such as finding an ally, addressing immediate problems, and gradually implementing procedures while gaining acceptance. It stresses the importance of SCM and challenges of changing behaviors for Level 1 teams.
The True Costs and Benefits of CMMI Level 5rhefner
The document discusses the true costs and benefits of achieving CMMI Level 5. It notes that while CMMI aims to produce software and systems faster, better and cheaper, simply claiming a high maturity level does not guarantee success. For organizations and customers to realize the benefits, CMMI processes must be properly implemented across all projects from the start, and appraisals must accurately reflect the organization's capabilities. The use of Lean Six Sigma tools can help organizations institutionalize improvements and achieve quantifiable benefits from CMMI.
This document discusses the perceived discord between CMMI and Agile development methods. It argues that the discord stems from two main reasons: 1) Early adopters of each approach represented extremes that set negative tones, and 2) Misperceptions arose due to misuse, lack of accurate information, and differing terminology between the approaches. The document seeks to clarify misperceptions, discuss the value of both approaches, and argue that when properly used together, CMMI and Agile can improve software development performance. It calls for experts of each approach to work on understanding and combining the approaches.
CMMI was developed in the 1980s by the Software Engineering Institute to help organizations improve processes for developing software after many projects failed to be delivered on time and budget. The CMMI model identifies 25 processes areas that organizations can implement to improve capabilities and maturity in managing projects. Adopting CMMI has become a market demand as contractors providing software to the government must follow CMMI, and competing companies are using it for best practices. CMMI aims to improve an organization's performance and ability to consistently deliver high-quality products and services to customers. It provides a framework for comprehensive process improvement across three constellations: development, acquisition, and services.
0aa93679eaf34c5017be9470ae48bbd16ca0.pdfOuheb Group
The document discusses how applying systems thinking concepts can help address common problems that arise when using process improvement frameworks like CMM and CMMI. It describes two systems archetypes - "fixes that backfire" and "shifting the burden" - that are useful for understanding issues. For the "fixes that backfire" archetype, it provides examples of how overfocusing on maturity levels or process for its own sake can unintentionally worsen problems. Addressing only surface issues without a deep understanding of the root causes can lead to negative long-term consequences.
Configuration management (CM) involves identifying system components, controlling changes, tracking status, and auditing configurations. It aims to manage changes in a planned, systematic way. CM is important throughout the software development lifecycle and provides benefits like stability, empowering decision making, and introducing standards. While CM requires effort, poor CM results in issues like heavy maintenance costs, unwanted surprises, and dropping service levels.
presentations_Day 3 & 4-Capability Maturity Model Integration (CMMI).pptxBenjaminFamili
This document provides an overview of the Capability Maturity Model Integration (CMMI). It discusses common project challenges faced by immature versus mature organizations. It then defines CMMI and explains that it was created to combine several existing maturity models into a single framework. The document outlines the history and development of CMMI. It also describes the benefits organizations can realize by implementing CMMI, including cost savings, schedule improvements, productivity gains, quality enhancements, and increased customer satisfaction and ROI. Finally, it explains the two representations of CMMI - staged and continuous - and how process areas are organized differently within each.
The document provides an overview of the Capability Maturity Model Integration (CMMI). It discusses that CMMI is a process improvement approach that provides organizations with the essential elements of effective processes. It combines best practices from software engineering, systems engineering, and integrated product and process development. CMMI can be used to guide process improvement across these disciplines. The document outlines the key components of CMMI including the staged and continuous representations, core process areas, and how it addresses the needs of development, services, and acquisition.
CMMi provides a framework of best practices to improve processes through five levels of maturity. Pursuing process improvement requires time and investment but provides directed progress towards goals like coordinated teamwork and predictable results, complementing a focus on technology and people. Common myths are that processes interfere with creativity or are unnecessary for small projects, but processes can reduce costs and defects while improving customer satisfaction. The five maturity levels progress from ad-hoc processes to continuous improvement. While culture change causes pain, the gains of improved cost, schedule and quality make the journey worthwhile.
The document discusses the Capability Maturity Model Integration (CMMI), which defines elements required to build great products and deliver great services. It provides five maturity levels that help organizations understand their strengths and areas for improvement. Level 1 is initial, where processes are ad-hoc. Level 2 is repeatable, where processes are defined and documented. Level 3 is defined, where processes are consistent across the organization. Level 4 is managed, where processes and results are measured quantitatively. Level 5 is optimizing, focused on continuous process improvement.
The document discusses CMMI (Capability Maturity Model Integration), an internationally recognized standard for process improvement in software development. It provides an overview of CMMI and how it helps organizations improve processes, ensure quality, increase customer satisfaction and realize cost savings. Specific examples are given of organizations that achieved returns on investment from 5:1 to 13:1 after implementing CMMI. The relationship between CMMI and other frameworks like COBIT, ITIL and ISO 27001 is also summarized.
The Government Accountability Office found 14 Challenges in Agile adoption. See how EMT answers those challenges with CMMI and Agile together.
Effective Practices and Federal Challenges in Applying Agile Methods
GAO-12-681: Published: Jul 27, 2012. Publicly Released: Jul 27, 2012
TuVinhSoft - Software Development Company from Vietnam provides Offshore software development, Software Outsourcing, Staff augmentation, Application Software Development, Web Design and Development, Business Process Outsourcing, Search Engine Optimization to USA, UK, Japan etc.
Software development lifecycle (SDLC) has traditionally been used for in-house systems
or custom-developed software. Capability Maturity Model Integration (CMMI) has been
used specifically in software engineering to demonstrate the maturity of an organization's
software development process. Implementations of packaged enterprise software bring a
unique set of challenges that need to be viewed from the different perspectives of SDLC
and CMMI. This presentation demonstrates how ERP managers can articulate their
development and support process within the context of SDLC and CMMI.
Capability maturity model integration (CMMI) is a process level improvement training and appraisal program. iT can be used to guide process improvement across a project, division, or an entire organization. CMMI defines the following maturity levels for processes: Initial, Managed, Defined, Quantitatively Managed, and Optimizing.
Managing risk with deliverables planningGlen Alleman
This document discusses managing risk through continuous risk management (CRM). It introduces the five principles of risk management and outlines the CRM process, which includes identifying risks, analyzing and prioritizing them, planning mitigations, tracking mitigation progress and risks, making decisions based on risk data, and communicating throughout the project. The presentation provides examples of risk statements, evaluation criteria, classification approaches, and integrating risks and mitigation plans into project schedules. The goal of CRM is to continually identify, assess, and mitigate risks to improve project outcomes.
Planning projects usually starts with tasks and milestones. The planner gathers this information from the participants – customers, engineers, subject matter experts. This information is usually arranged in the form of activities and milestones. PMBOK defines “project time management” in this manner. The activities are then sequenced according to the projects needs and mandatory dependencies.
Increasing the Probability of Project SuccessGlen Alleman
This document discusses principles and practices for increasing the probability of project success by managing risk from uncertainty. It defines risk as the effect of uncertainty on objectives. There are two types of uncertainty - epistemic (reducible) and aleatory (irreducible). Risk from epistemic uncertainty can be reduced through work on the program, while risk from aleatory uncertainty requires establishing margins. The document argues that effective risk management is needed to deliver capabilities on time and budget by identifying risks, understanding their interactions and impacts, and implementing risk handling strategies. This increases the likelihood of project success by preventing problems, improving quality, enabling better resource use, and promoting teamwork.
Process Flow and Narrative for Agile+PPMGlen Alleman
This document describes how an organization integrates agile software development practices with earned value management (EVM) to provide program status updates. It outlines a process that begins with developing a rough order of magnitude estimate of features needed. These features are then prioritized, mapped to a product roadmap and product backlog. Stories are developed from features and estimated, and tasks are estimated in hours. Physical percent complete data from tasks in Rally is used to calculate EVM metrics to inform stakeholders.
This document discusses principles of effective risk management for projects. It emphasizes the importance of clearly defining requirements and success criteria before releasing requests for proposals. This includes quantifying measures of effectiveness and performance for different use scenarios. Effective risk management also requires developing a funded implementation plan informed by historical risks and uncertainties. The document outlines key data and processes needed to reduce risks and increase the probability of a project's success, including defining requirements, developing plans and schedules, identifying risks and adjustments needed to plans. It discusses uncertainties from both known and unknown sources that can impact cost, schedule and performance.
Cost and schedule growth for complex projects is created when unrealistic technical performance expectations, unrealistic cost and schedule estimates, inadequate risk assessments, unanticipated technical issues, and poorly performed and ineffective risk management, contribute to project technical and programmatic shortfalls
From Principles to Strategies for Systems EngineeringGlen Alleman
From Principles to Strategies How to apply Principles, Practices, and Processes of Systems Engineering to solve complex technical, operational,
and organizational problems
Building a Credible Performance Measurement BaselineGlen Alleman
The document discusses establishing a credible Performance Measurement Baseline (PMB) for programs by integrating technical and programmatic plans. It recommends starting with a Work Breakdown Structure (WBS) that identifies system elements, associated risks, and processes to produce outcomes. An Integrated Master Plan (IMP) should then define how system elements mature at Program Events, with Measures of Effectiveness (MOEs) and Measures of Performance (MOPs) assigned. Finally, an Integrated Master Schedule (IMS) should arrange tasks to increase technical maturity, identify reducible and irreducible risks, and establish a risk-adjusted PMB to increase the probability of program success. Connecting these elements through the WBS, IMP and IMS
Integrated master plan methodology (v2)Glen Alleman
The document describes a methodology for developing an Integrated Master Plan (IMP). It outlines five conditions an IMP must meet, five steps in the development process, five common questions about IMP development, five common mistakes, and provides five templates/samples for key IMP sections. The methodology is intended to help program and project teams create effective IMPs that integrate execution plans and align with contractual requirements.
Capabilities‒Based Planning the capabilities needed to accomplish a mission or fulfill a business strategy
Only when capabilities are defined can we start with requirements elicitation
Starting with the development of a Rough Order of Magnitude (ROM) estimate of work and duration, creating the Product Roadmap and Release Plan, the Product and Sprint Backlogs, executing and statusing the Sprint, and informing the Earned Value Management Systems, using Physical Percent Complete of progress to plan.
Program Management Office Lean Software Development and Six SigmaGlen Alleman
Successfully combining a PMO, Agile, and Lean / 6 starts with understanding what benefit each paradigm brings to the table. Architecting a solution for the enterprise requires assembling a “Systems” with processes, people, and principles – all sharing the goal of business improvement.
This resource document describes the Program Governance Road map for product development, deployment, and sustainment of products and services in compliance with CMS guidance, ITIL IT management, CMMI best practices, and other guidance to assure high quality software is deployed for sustained operational success in mission critical domains.
Generating privacy-protected synthetic data using Secludy and MilvusZilliz
During this demo, the founders of Secludy will demonstrate how their system utilizes Milvus to store and manipulate embeddings for generating privacy-protected synthetic data. Their approach not only maintains the confidentiality of the original data but also enhances the utility and scalability of LLMs under privacy constraints. Attendees, including machine learning engineers, data scientists, and data managers, will witness first-hand how Secludy's integration with Milvus empowers organizations to harness the power of LLMs securely and efficiently.
In the rapidly evolving landscape of technologies, XML continues to play a vital role in structuring, storing, and transporting data across diverse systems. The recent advancements in artificial intelligence (AI) present new methodologies for enhancing XML development workflows, introducing efficiency, automation, and intelligent capabilities. This presentation will outline the scope and perspective of utilizing AI in XML development. The potential benefits and the possible pitfalls will be highlighted, providing a balanced view of the subject.
We will explore the capabilities of AI in understanding XML markup languages and autonomously creating structured XML content. Additionally, we will examine the capacity of AI to enrich plain text with appropriate XML markup. Practical examples and methodological guidelines will be provided to elucidate how AI can be effectively prompted to interpret and generate accurate XML markup.
Further emphasis will be placed on the role of AI in developing XSLT, or schemas such as XSD and Schematron. We will address the techniques and strategies adopted to create prompts for generating code, explaining code, or refactoring the code, and the results achieved.
The discussion will extend to how AI can be used to transform XML content. In particular, the focus will be on the use of AI XPath extension functions in XSLT, Schematron, Schematron Quick Fixes, or for XML content refactoring.
The presentation aims to deliver a comprehensive overview of AI usage in XML development, providing attendees with the necessary knowledge to make informed decisions. Whether you’re at the early stages of adopting AI or considering integrating it in advanced XML development, this presentation will cover all levels of expertise.
By highlighting the potential advantages and challenges of integrating AI with XML development tools and languages, the presentation seeks to inspire thoughtful conversation around the future of XML development. We’ll not only delve into the technical aspects of AI-powered XML development but also discuss practical implications and possible future directions.
Threats to mobile devices are more prevalent and increasing in scope and complexity. Users of mobile devices desire to take full advantage of the features
available on those devices, but many of the features provide convenience and capability but sacrifice security. This best practices guide outlines steps the users can take to better protect personal devices and information.
Your One-Stop Shop for Python Success: Top 10 US Python Development Providersakankshawande
Simplify your search for a reliable Python development partner! This list presents the top 10 trusted US providers offering comprehensive Python development services, ensuring your project's success from conception to completion.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
Main news related to the CCS TSI 2023 (2023/1695)Jakub Marek
An English 🇬🇧 translation of a presentation to the speech I gave about the main changes brought by CCS TSI 2023 at the biggest Czech conference on Communications and signalling systems on Railways, which was held in Clarion Hotel Olomouc from 7th to 9th November 2023 (konferenceszt.cz). Attended by around 500 participants and 200 on-line followers.
The original Czech 🇨🇿 version of the presentation can be found here: https://www.slideshare.net/slideshow/hlavni-novinky-souvisejici-s-ccs-tsi-2023-2023-1695/269688092 .
The videorecording (in Czech) from the presentation is available here: https://youtu.be/WzjJWm4IyPk?si=SImb06tuXGb30BEH .
Cosa hanno in comune un mattoncino Lego e la backdoor XZ?Speck&Tech
ABSTRACT: A prima vista, un mattoncino Lego e la backdoor XZ potrebbero avere in comune il fatto di essere entrambi blocchi di costruzione, o dipendenze di progetti creativi e software. La realtà è che un mattoncino Lego e il caso della backdoor XZ hanno molto di più di tutto ciò in comune.
Partecipate alla presentazione per immergervi in una storia di interoperabilità, standard e formati aperti, per poi discutere del ruolo importante che i contributori hanno in una comunità open source sostenibile.
BIO: Sostenitrice del software libero e dei formati standard e aperti. È stata un membro attivo dei progetti Fedora e openSUSE e ha co-fondato l'Associazione LibreItalia dove è stata coinvolta in diversi eventi, migrazioni e formazione relativi a LibreOffice. In precedenza ha lavorato a migrazioni e corsi di formazione su LibreOffice per diverse amministrazioni pubbliche e privati. Da gennaio 2020 lavora in SUSE come Software Release Engineer per Uyuni e SUSE Manager e quando non segue la sua passione per i computer e per Geeko coltiva la sua curiosità per l'astronomia (da cui deriva il suo nickname deneb_alpha).
HCL Notes und Domino Lizenzkostenreduzierung in der Welt von DLAUpanagenda
Webinar Recording: https://www.panagenda.com/webinars/hcl-notes-und-domino-lizenzkostenreduzierung-in-der-welt-von-dlau/
DLAU und die Lizenzen nach dem CCB- und CCX-Modell sind für viele in der HCL-Community seit letztem Jahr ein heißes Thema. Als Notes- oder Domino-Kunde haben Sie vielleicht mit unerwartet hohen Benutzerzahlen und Lizenzgebühren zu kämpfen. Sie fragen sich vielleicht, wie diese neue Art der Lizenzierung funktioniert und welchen Nutzen sie Ihnen bringt. Vor allem wollen Sie sicherlich Ihr Budget einhalten und Kosten sparen, wo immer möglich. Das verstehen wir und wir möchten Ihnen dabei helfen!
Wir erklären Ihnen, wie Sie häufige Konfigurationsprobleme lösen können, die dazu führen können, dass mehr Benutzer gezählt werden als nötig, und wie Sie überflüssige oder ungenutzte Konten identifizieren und entfernen können, um Geld zu sparen. Es gibt auch einige Ansätze, die zu unnötigen Ausgaben führen können, z. B. wenn ein Personendokument anstelle eines Mail-Ins für geteilte Mailboxen verwendet wird. Wir zeigen Ihnen solche Fälle und deren Lösungen. Und natürlich erklären wir Ihnen das neue Lizenzmodell.
Nehmen Sie an diesem Webinar teil, bei dem HCL-Ambassador Marc Thomas und Gastredner Franz Walder Ihnen diese neue Welt näherbringen. Es vermittelt Ihnen die Tools und das Know-how, um den Überblick zu bewahren. Sie werden in der Lage sein, Ihre Kosten durch eine optimierte Domino-Konfiguration zu reduzieren und auch in Zukunft gering zu halten.
Diese Themen werden behandelt
- Reduzierung der Lizenzkosten durch Auffinden und Beheben von Fehlkonfigurationen und überflüssigen Konten
- Wie funktionieren CCB- und CCX-Lizenzen wirklich?
- Verstehen des DLAU-Tools und wie man es am besten nutzt
- Tipps für häufige Problembereiche, wie z. B. Team-Postfächer, Funktions-/Testbenutzer usw.
- Praxisbeispiele und Best Practices zum sofortigen Umsetzen
OpenID AuthZEN Interop Read Out - AuthorizationDavid Brossard
During Identiverse 2024 and EIC 2024, members of the OpenID AuthZEN WG got together and demoed their authorization endpoints conforming to the AuthZEN API
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
UiPath Test Automation using UiPath Test Suite series, part 6DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 6. In this session, we will cover Test Automation with generative AI and Open AI.
UiPath Test Automation with generative AI and Open AI webinar offers an in-depth exploration of leveraging cutting-edge technologies for test automation within the UiPath platform. Attendees will delve into the integration of generative AI, a test automation solution, with Open AI advanced natural language processing capabilities.
Throughout the session, participants will discover how this synergy empowers testers to automate repetitive tasks, enhance testing accuracy, and expedite the software testing life cycle. Topics covered include the seamless integration process, practical use cases, and the benefits of harnessing AI-driven automation for UiPath testing initiatives. By attending this webinar, testers, and automation professionals can gain valuable insights into harnessing the power of AI to optimize their test automation workflows within the UiPath ecosystem, ultimately driving efficiency and quality in software development processes.
What will you get from this session?
1. Insights into integrating generative AI.
2. Understanding how this integration enhances test automation within the UiPath platform
3. Practical demonstrations
4. Exploration of real-world use cases illustrating the benefits of AI-driven test automation for UiPath
Topics covered:
What is generative AI
Test Automation with generative AI and Open AI.
UiPath integration with generative AI
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Unlock the Future of Search with MongoDB Atlas_ Vector Search Unleashed.pdfMalak Abu Hammad
Discover how MongoDB Atlas and vector search technology can revolutionize your application's search capabilities. This comprehensive presentation covers:
* What is Vector Search?
* Importance and benefits of vector search
* Practical use cases across various industries
* Step-by-step implementation guide
* Live demos with code snippets
* Enhancing LLM capabilities with vector search
* Best practices and optimization strategies
Perfect for developers, AI enthusiasts, and tech leaders. Learn how to leverage MongoDB Atlas to deliver highly relevant, context-aware search results, transforming your data retrieval process. Stay ahead in tech innovation and maximize the potential of your applications.
#MongoDB #VectorSearch #AI #SemanticSearch #TechInnovation #DataScience #LLM #MachineLearning #SearchTechnology
Driving Business Innovation: Latest Generative AI Advancements & Success StorySafe Software
Are you ready to revolutionize how you handle data? Join us for a webinar where we’ll bring you up to speed with the latest advancements in Generative AI technology and discover how leveraging FME with tools from giants like Google Gemini, Amazon, and Microsoft OpenAI can supercharge your workflow efficiency.
During the hour, we’ll take you through:
Guest Speaker Segment with Hannah Barrington: Dive into the world of dynamic real estate marketing with Hannah, the Marketing Manager at Workspace Group. Hear firsthand how their team generates engaging descriptions for thousands of office units by integrating diverse data sources—from PDF floorplans to web pages—using FME transformers, like OpenAIVisionConnector and AnthropicVisionConnector. This use case will show you how GenAI can streamline content creation for marketing across the board.
Ollama Use Case: Learn how Scenario Specialist Dmitri Bagh has utilized Ollama within FME to input data, create custom models, and enhance security protocols. This segment will include demos to illustrate the full capabilities of FME in AI-driven processes.
Custom AI Models: Discover how to leverage FME to build personalized AI models using your data. Whether it’s populating a model with local data for added security or integrating public AI tools, find out how FME facilitates a versatile and secure approach to AI.
We’ll wrap up with a live Q&A session where you can engage with our experts on your specific use cases, and learn more about optimizing your data workflows with AI.
This webinar is ideal for professionals seeking to harness the power of AI within their data management systems while ensuring high levels of customization and security. Whether you're a novice or an expert, gain actionable insights and strategies to elevate your data processes. Join us to see how FME and AI can revolutionize how you work with data!
Best 20 SEO Techniques To Improve Website Visibility In SERPPixlogix Infotech
Boost your website's visibility with proven SEO techniques! Our latest blog dives into essential strategies to enhance your online presence, increase traffic, and rank higher on search engines. From keyword optimization to quality content creation, learn how to make your site stand out in the crowded digital landscape. Discover actionable tips and expert insights to elevate your SEO game.
Best 20 SEO Techniques To Improve Website Visibility In SERP
Blending Agile with CMMI®
1. Cutter Journal, Jim Highsmith Editor
Blending Agile Development Methods with CMMI®
by Glen Alleman
There are two popular myths living on opposite poles of the software development globe
[Glaz01]. The first myth, which lives in the high–ceremony world of government contractors and
corporate IT outsourcing organizations, holds that agile development processes are the same as
“hacking” — undisciplined, ad hoc, and prone to rapid change by external forces. The other
myth, which lives in software firms that practice some variant of an agile development
methodology (Extreme Programming, Scrum, etc.), holds that CMMI® [CMMI] is a dinosaur that
will go the way of all dinosaurs.1
This camp claims that the CMMI® processes do not address the
core issue of software — validating that the customer is getting what [they] want in the presence
of changing requirements.
Like most myths in the software development business, each carries a grain of truth along with a
large dose of falsehood. Further examination shows both myths to be flawed in important and
misleading ways. This paper attempts to put both agile development process and the CMMI® in a
context where each myth–holder can see the motivation, purpose, benefit, and applicability of
each side by describing how CMMI and XP–inspired processes are blended at Rocky Flats
Environmental Technology Site www.rfets.gov.
WHERE TO START?
Much of the problem with discussing the blending of CMMI with agile has to do with where the
discussion starts. One difficulty with the conversation is the assumption by both sides that they
understand how the other side works. CMMI’ers assume they understand agile enough to know it
has problems, and agilists assume they understand enough about CMMI to know it will be trouble
for their approach to development. This situation is not unusual where strongly held positions
produce barriers to discussion.
The first step in closing the gap in these assumptions is the realization that CMMI and Agile are
philosophically compatible but still culturally separated. In spite of this cultural gap, their goals
have much in common:
• They seek to improve the performance of software development organizations.
• Rigorous planning is part of their core processes.
• Rules form the basis of the work processes.
• Neither is comprehensive or suitable for all software development or acquisition problems.
• Both are based on experience from past successes and failures.
MOTIVATION FOR CMMI
Improvement in software quality has been associated with higher levels of CMMI compliance
[Herb94], [Gold03]. These improvements include:
• Reduced rework
• Predictable engineering milestones
• Measurable improvements of products and services
1
In the agile literature there is confusion between CMM and CMMI. In some sense CMM is a
dinosaur and has already gone away. [STSC] is a good reference for the differences between
CMM and CMMI.
1/14
2. Cutter Journal, Jim Highsmith Editor
• Greater customer satisfaction
MOTIVATION FOR AGILE
Continued problems with cost, schedule, and functionality of software development projects have
motivated a segment of the software community to search for alternatives to traditional
development methodologies. One difficulty faced by agile processes in the presence of a CMMI
culture is “where’s the proof” that these new methods add value?
If you are an adherent of Geoffrey Moore’s Crossing the Chasm [Moor02] then you’ll understand
that “proof” is asked by those on the right side of the adaptation curve. Agile is in the innovative,
early adopters, and early majority part of the curve [Ambl04].
Figure 1 – Incorporating agile development into CMMI involves crossing the chasm and becoming
an early adopter. Asking for proof before adopting is done by the late majority and laggards.
For early innovators and adopters the motivation for agile is to move from the current paradigm
to something new. They’re “moving away” from the current paradigm. Late majority and
laggards need to “move toward” something new with the assurances that whatever this new thing
is, it will not disrupt their old paradigm.
WHAT IS THE CMMI ALL ABOUT?
CMMI is a framework for improving the processes of software organizations that is premised on
the idea that “the quality of a system or product is highly influenced by the quality of the process
used to develop or maintain it.” It was strongly influenced by Watts Humphrey’s work
[Hump89], which provided the basic principles of a “capability maturity model.” The Software
Engineering Institute’s (SEI) research shows there are three critical dimensions that organizations
typically focus on: people, procedures and methods, and tools and equipment [Gold03].
The core idea in CMM is – it’s the process that delivers the quality. Institutionalizing the
process assures it will deliver. This is different from the core idea in an agile
methodology, where individuals and their interactions are guided by the principles of
agile. [integrate into preceding or following paragraph?]
CMMI is a collection of Process Area components that are institutionalized across an
organization. There are several CMMI process frameworks. For this paper I’ll use the CMMI for
Software, Staged Representation [SEI02]. There are innumerable examples and pictures of these
five levels, so I won’t reproduce them here. It is important, though, to understand these five levels
build on each other. Higher levels of maturity include the process areas of the lower levels or
have enhanced versions of the same process areas.
As a result, prematurely mandating achievement of a specific level leads to failure. Some firms
applying CMMs have little knowledge of their use in process improvement. They impose a
CMMI level without understanding the effort, cultural changes, or resource impact.
2/14
3. Cutter Journal, Jim Highsmith Editor
Without understanding the taxonomy of CMMI, the “agilist” can easily claim CMMI is too
complex. The fact that the CMMI for software is 624 pages and there are equally large books just
to explain the CMMI easily supports this claim.
CMMI in One Chart
The five (5) levels of maturity, the process areas for each maturity level and their relationship to
the process categories are shown in Table 1. 2
Maturity Level Process Areas by Maturity Level Category
ProcessManagement
ProjectManagement
Engineering
Support
5 Optimizing
Continuous process
improvement
CAR Causal Analysis and Resolutions
OID Organizational Innovation and Deployment
4 Quantitatively
Managed
Quantitative
management
QPM Quantitative Project Management
OPP Organizational Process Performance
3 Defined
Process
Standardization
DAR Decision Analysis And Resolution
RSKM Risk Management
IPM Integrated Project Management
OT Organizational Training
OPD Organizational Process Development
OPF Organizational Process Focus
VAL Validation
VER Verification
PI Product Integration
TS Technical Solution
RD Requirements Development
2 Managed
Basic project
management
CM Configuration Management
PPQA Process and Quality Assurance
M&A Measurement and Analysis
SAM Supplier Agreement Analysis
PMC Project Monitoring and Control
PP Project Planning
REQM Requirements Management
1 Initial
Table 1 — Five Maturity Levels, Their Processes and Categories
WHAT ARE AGILE PROCESSES ALL ABOUT?
Agile software development processes come in several “flavors” [Pekk02], [Kale02]. The most
recognizable is Extreme Programming (XP). Others include Crystal, Scrum, Dynamic Systems
Development Method (DSDM), Adaptive Software Development, Test Driven Design (TDD),
2
All this detail seems unnecessary in the agile world and is representative of the complexity
of CMMI. There may be a grain of truth here, but very little if any of the Process Areas found
in CMMI are not applicable to any software development methodology. The problem comes
when the CMMI is used as a club to beat quality into an organization rather than as a
framework for improving the development processes – as it is designed to do.
3/14
4. Cutter Journal, Jim Highsmith Editor
and Xbreed, which is a mix of XP and Scrum. Background and supporting materials for agile
development methods can be found at the Agile Alliance web site www.agilealliance.org.
Extreme Programming and the CMMI
Extreme Programming (XP) is a good starting place for mapping agile development practices to
the CMMI’s process areas. Other agile processes could also be a starting point, but XP practices
provide a unique insight into the values and culture of agile development. XP makes use of the 13
practices shown in Table 2.3
Customer Practices Programming Practices Support Practices
Planning Game – predicts
what will be accomplished by
the due date
Simple Design – start with
simple code and through
testing keep it simple
Continuous Integration –
keeps system running at all
times
Small Releases – provides
code in very small sets of
functionality
Pair Programming – two
developers participate at one
work station
Coding Standards – follow
common coding standard
Whole Team – on site
customer, co–located with
the development team
Test Driven Development –
defines automated test first
to verify code
Collective Code Ownership –
any pair can improve any
code at any time
Customer Acceptance Test –
live tests on working code
Refactoring – removes
duplication, increases
cohesion, and lowers coupling
Sustainable Pace – maintain
a sustainable pace
Metaphor – guide
development with a simple
story of how the whole
system works
Table 2 — The 13 practices of Extreme Programming
INSTALLING AGILE IN A CMMI PROCESS
As stated before, there are two approaches to blending CMMI and Agile: start with CMMI or
start with agile. The former is the example described here. The latter seems difficult because of
the culture of agile development.
Table 3 describes the mapping between agile practices and CMMI process areas.
Legend
– XP match
– XP moderate match
– XP partial match
– XP provides little support
PlanningGame
SmallReleases
Metaphor
SimpleDesign
TestDriveDevelopment
Refactoring
CustomerAcceptance
PairProgramming
CollectiveCodeOwnership
ContinuousIntegration
SustainablePace
WholeTeam
CodingStandards
Causal Analysis And Resolution CAR
Organizational Innovation & Deployment OID
Quantitative Project Management QPM
Organizational Process Performance OPP
Decision Analysis And Resolution DAR
3
There are 12 practices defined in [Beck99]. The 13th
practice, “whole team” was
added in some descriptions of XP.
4/14
5. Cutter Journal, Jim Highsmith Editor
Legend
– XP match
– XP moderate match
– XP partial match
– XP provides little support
PlanningGame
SmallReleases
Metaphor
SimpleDesign
TestDriveDevelopment
Refactoring
CustomerAcceptance
PairProgramming
CollectiveCodeOwnership
ContinuousIntegration
SustainablePace
WholeTeam
CodingStandards
Risk Management PM
Integrated Project Management IPM
Organizational Training OT
Organizational Process Development OPD
Organizational Process Focus OPF
Validation VAL
Verification VER
Product Integration PI
Technical Solution TD
Requirements Development RD
Configuration Management CM
Process And Quality Assurance PQA
Measurement & Analysis M&A
Supplier Agreement Management SAM
Project Management and Control PMC
Project Planning PP
Requirements Management REQM
Table 3 — Mapping CMMI Process Areas to XP Practices
The First Stage Is Denial…
The process of installing agile development practices in a CMMI framework goes through several
emotional, cultural, and technical lifecycles:
1. Adding XP can’t be done simply because CMMI does not provide the means for an agile–
centric development process.
2. After some more thought and much hand waving, adding agile can be done because CMMI
does not describe the actual details of implementation.
3. Once over this hurdle, it turns out to be harder than it looks because the two distinct cultures
need to be brought together. Both cultures need to understand each other and search for join
points.
4. Then it becomes easier than it looks once the cultural aspects are overcome and the search for
process improvement and software quality are joined in both cultures.
5. Then it becomes hard again once the first major problem is encountered. The naysayers will
naturally say, “I told you not to do that.” The supporters will naturally say, “Give it a chance and
we’ll work out the kinks.”
The last two items (4) and (5) will repeat for some time until experience, consensus, and cultural
connections are reached about the benefits, risks, issues, and costs of incorporating agile in the
CMMI framework.
Critical Success Factors for Agile inside CMMI
The critical success factors for deploying agile process into a CMMI framework include:
5/14
6. Cutter Journal, Jim Highsmith Editor
• The CMMI processes need to be well understood, in place, and operational. Formal
assessment is not necessary, but the displacement of the CMMI culture is not the goal of the
agile introduction process.
• Agile development processes need to be well understood, in place, and operational in some
form. This doesn’t mean full XP or Scrum is being used but rather, XP–inspired processes
have some experience base with the team. Using Table 3, each XP–inspired practice needs to
find a specific home in a CMMI process area.
• Use the terminology of CMMI when joining the two cultures. Agile is the newly arrived
foreigner to the “new world” of CMMI so learning the native language is critical to rapidly
becoming integrated with the CMMI society, so the Lingua Franca should be CMMI.
• The development of macro–level schedules and budgets through delivery of working code
rather than Big Design Up front (BDUF) must be understood agreed to by management .
• The realization that the agile practices are found in any good development method. What is
significantly different is the frequency and granularity with which they are performed.
Practices of Agile on a CMMI Project
Having an understanding of what to do and doing it are two distinct things. The following
behaviors have allowed our Rocky Flats Information and Communication technology (ICT) team
to blend XP–inspired development processes inside a CMMI framework. Let’s look at the
Process Areas for Level 2 and see how agile processes fulfill their requirements. 4
One critical difference between an agile project and a CMMI–based project is the collection and
analysis of long–term data for process improvement. CMMI identifies several process areas that
are dedicated to collection and analysis. This would be considered unnecessary on an XP project.
Table 4 describes how agile methods can be used to fulfill [CMMI Practice Area]. This is a brief
description, since the details are beyond the space of this paper. The details for each agile method
be found in their respective texts: Adaptive Software Development [High01], Crystal [Cock02],
DSDM [Stap03], Extreme Programming [Beck99], Scrum [Schw01], Test Driven Development
[Beck02].
A Word of Caution
Before getting too enthusiastic about how easy it will be to blend CMMI and agile, [the items
described] in Table 4 are not only brief, they are a bare minimum effort to comply with CMMI.
This approach is “pure agile” since only the minimum needed to deliver the value is one of the
underlying axioms of any agile process. In fact more is needed to comply with the “intent” of
CMMI. This additional effort is almost always centered on documentation, formal training, and
the management of the process improvement process.
4
Starting with Level 2 is important. A critical understanding in CMMI is to not skip levels on
the way to some desired level. If levels are skipped, gaps appear in the supporting structure
for the next level up. Each Specific Practice (SP) for the Process Areas is described in detail
in [SEI02]. The reader should be familiar with the structure of the CMMI framework [to the
level of understanding] the Process Areas for Level 2 and the Specific Practices for each
Process Area. With this understanding the connection between agile and CMMI will be much
easier.
6/14
7. Cutter Journal, Jim Highsmith Editor
Connecting Agile to the CMMI Process Areas
Table 4 describes how an XP–inspired software development process can be integrated with a
CMMI Level 2 framework. 5
Level 2 CMMI
Process Area
XP–Inspired Agile Practices
(Summary of CMMI process area activities)
Requirements
Management
REQM
Manage requirements of product and identify inconsistencies
between those requirements and the plans and work products.
SP1.1: Requirements are managed through “story cards.”
SP1.2: Face–to–face communication confirms requirements.
SP1.3: Traceability provided through face–to–face communication.
Key Point
Unlike a traditional XP shop where old story cards are torn up and tossed, the
evolution of the requirements needs to be maintained as the requirements evolve
[Meke03]. This requirements configuration control is done through a version
numbering scheme. Here’s where electronic means help, since handling all the cards
and keeping the requirements straight manually does not scale well.
Project Planning
PP
Establish and maintain plans that define the project’s activities.
SP1.1: Project scope is established through the Planning Game.
SP1.2: Story cards are used to estimate the work products.
SP1.3: Rigorous steps are followed during each iteration.
SP1.4: Planning Game produces Estimates of effort and cost.
SP2.1: Schedules are established in the Planning Game.
SP2.2: Risk assessment is part of each XP practice.
SP2.3: The data management processes are outside XP.
Key Point
Total project budgets can be estimated, but agile processes are better suited for
emergent budgets. The solution is to establish a “not to exceed budget” and deliver
features within that value. History shows that budgets and end–to–end schedules for
software projects are notoriously wrong. Acceptance that agile methods develop this
information through feedback and delivery processes is a critical success factor.
[Boeh04]
Project
Monitoring
and Control
PMC
Understand the project’s progress so that appropriate corrective
actions can be taken in the presence of deviations.
SP1.1: Parameters monitored through continuous feedback.
SP1.2: Commitments monitored through daily standups.
SP1.3: Project risks are monitored through daily standups.
SP1.4: Data management monitored through external resources.
SP1.5: Stakeholder involvement monitored by direct conversations.
SP1.6: Progress reviews conducted at the end of each iteration.
SP1.7: Milestone reviews conducted at the end of each iteration.
SP2.1: Corrective actions are taken at the end of each iteration.
SP2.2: Reviews are used in Planning game for the next iteration.
SP2.3: Corrective actions managed by the collective team.
Key Point
One issue in an agile team is “What is the role of a project manager?” One answer is
5
It is assumed the reader has access to a CMMI reference. Each Process Area (PA), Specific
Practice (SP) can be referenced in the CMMI documentation.
7/14
8. Cutter Journal, Jim Highsmith Editor
that the project manager oversees the relationship between the customer, the
development team, and the supporting processes.
Supplier
Agreement
SAM
Manage acquisition of products from suppliers.
SP1.1: The acquisition process starts with an agile environment.
SP1.2: Suppliers selected by ability to adapt to the agile.
SP1.3: Agreements need to be informal as possible.
SP2.1: COTS products must have an agile capability as well.
SP2.2: The supplier agreements are not through paper contracts.
SP2.3: Acceptance testing identical to the internal products.
SP2.4: Products transitioned on iteration boundaries not “big bang”.
Key Point
A critical factor in supplier relationships is their ability to adapt to the agile paradigm.
A supplier wanting a firm fixed price contract or one wanting a “hands off”
relationship will not be a good partner in an agile development situation.
Measurement
and Analysis
M&A
Develop and sustain a measurement capability that is used to support
management information needs.
SP1.1: Stories delivered in code at the end of the iteration.
SP1.2: Measures defined in quantifiable terms.
SP1.3: The data collection in “big visible charts.”
Key Point
Measurement and analysis are provided through “big visible charts” hanging on the
wall in the development area. In an agile environment, pair programming and shared
development are common. The performance of the team is based on the completion
of the selected stories for an iteration. The critical success factor is to have the
development team tell the customer what can be done in an iteration rather than
have the deliverables specified by project management or some outside source.
Process and
Product
Quality
Assurance
PPQA
Provide staff and management with objective insight into processes
and associated work products.
SP1.1: Process objectively evaluated during the Planning Game.
SP1.2: Work products evaluated daily through 100% unit tests.
SP2.1: Noncompliance is communicated directly to customer.
SP2.2: Records of noncompliance are kept by the team.
Key Point
This is one problematic area for agile processes. Agile quality assurance processes are
powerful and flexible, but their document “footprint” is very low compared to more
formal practices.
Configuration
Management
CM
Establish and maintain the integrity of work products using
configuration identification, control, status accounting, and audits.
SP1.1: Configuration items are identified through unit tests.
SP1.2: CM system critical to success of agile development project.
SP1.3: Baselines performed daily in XP projects.
SP2.2: Change requests tracked through stories and task cards.
SP2.2: Agile depends on tight configuration control.
SP3.1: Configuration records takes place through the unit tests.
SP3.2: Configuration audits take place through the unit tests.
Key Point
Tracking change requests in a formal manner requires configuration control of story
and task cards. Having just the current cards is not sufficient. A historical file of
cards, their change history, and the “conversations” around the changes are also
8/14
9. Cutter Journal, Jim Highsmith Editor
needed.
Table 4 — Mapping agile processes to CMMI Level 2 Process Areas
Agile and CMMI Comparison
Agile and CMMI are philosophically compatible but still separated culturally and even more
separated in many practice areas. Inserting an agile development process into a CMMI framework
is often met with resistance. There is no guidance on how to do this or even how to talk about
doing this. Since the agile community is on the “outside looking in,” it falls on the CMMI
community to take the first steps [Reif03].
A simple comparison between CMMI and agile is provided in Table 5. This comparison is naïve,
of course, but it shows similarities as well as the significant differences to meeting the goal
delivering software on cost, on schedule, with high quality that meets the customer’s
requirements. [CSE02].
Agile CMMI
Core Values
Customer response drives change Measurements drive change
Participants are:
comfortable,
creative, and
risk takers
Participants are:
disciplined,
follow rules, and
risk averse
Communication is person to person at
the “micro” level
Communication is organizational at the
“macro” level
The management of knowledge is [held]
by the participants
The management of knowledge is [held]
by the process assets
Characteristics
Improvements take place within the
project initiated by the participants.
Improvements take place across the
organization initiated by the software
process improvement team.
Variance drives improvements. Low variance is sought
Process knowledge is personal, evolving,
and temporal.
Process knowledge is cross dimensional
and standardized.
Shortcutting of rules is encouraged. Shortcutting of rules is discouraged.
Management is by individuals. Management is by committees.
Trust with the customer is built by
delivering working software.
Trust with the customer is built by
adherence to the process infrastructure.
Test–driven design Front–loaded design
Small and directed at a [project focused
scope of view]
Broad, inclusive, and directed at an
[organization scope of view]
Level of discussion limited to the
problem at hand
Level of discussion based on words,
definition, enduring concepts, and
comprehensible paradigm
Approach
Descriptive
Qualitative
Situational
Product deliverables
Tactical
“Just do it”
Risk management: reactive
Prescriptive
Quantitative
Universality
Process activities
Strategic
“What do we call it?”
Risk management: proactive
9/14
10. Cutter Journal, Jim Highsmith Editor
Agile CMMI
Focus
Business focus
External
Innovative
Business focus
Internal
Rules based
Challenges
Scaling up Scaling down
Table 5 — Comparison between Agile and CMMI
Getting it to work
The approach of inserting agile into a CMMI framework may seem difficult at first. But there are
several “no brainer” processes and outcomes that must be understood from an agile as well as
CMMI point of view.
• 100% unit tested code is trusted code. Trusted code is configured to pass tests and configured
to provide functionality.
• Continuous feedback between the customer and the development team is the basis of trusted
schedules and requirements compliance assurance.
• A fully engaged team raises the level of quality, job fulfillment, and customer candor no
matter what the development process.
• Start small and avoid “big bang” for any change process.
• Treat process improvement as a project just like software development.
• Get customers involved at the same level of the developers.
Closing the Gaps
After all this technical and philosophical background, the issue of blending agile with CMMI
comes down to a simple concept. Kent Beck has a critical quote that cements Agile with CMMI:
“In software development, optimism is a disease; feedback is the cure.” CMMI strives to replace
the optimism in Kent Beck’s quote with measurement and analysis. 6
CMMI–based process improvement initiatives drive an organization toward repeatability of work
and data gathering, but they do not specify what the data looks like or how often it is gathered.
Agile processes specify the data needed to satisfy the process areas of CMMI. This data includes:
• Verification that 100% of the unit and functional tests pass on fine–grained sample intervals.
• On–site customers provide the “macro level” measure of functional compliance with needs of
the stakeholders.
• Viability of the schedule is determined through real project performance data. XP uses
velocity; agile projects in CMMI domains can use Earned Value.
The majority of software development projects are not conducted under conditions of rationality.
Software projects are not repetitive, stable, or linear. They are unique; driven by unstable
requirements, technology, and market forces; and contain many nonlinear activities. Software
development is complex, and the exact business and technical outcome is difficult to plan. The
6
This idea of data, control systems and project management in the CMMI context comes from
a near daily conversations with my colleague here at Rocky Flats – Martin Radley. Martin is a
contributor to Using Microsoft Project 2002, Tim Pyron editor, Que 2002. [ref]
10/14
11. Cutter Journal, Jim Highsmith Editor
processes used to manage the outcome may be chaotic. Software projects are often subjected to
forces outside the control of the project manager, developers, and stakeholders.
If CMMI and Agile processes are to be successfully “merged:”
• Customers must augment requirements specifications with their physical presence
• Feedback for quality, functionality, and team productivity is available on fine–grained
boundaries – days and weeks.
• Real project performance data replaces the optimism of management.
• Viability of the schedule is shared by the developers and the customer through continuous
integration, feedback, and performance measures.
When these processes are inserted into the CMMI Level 2 framework, agile development
processes become fully integrated and indistinguishable from the current CMMI–compliant
processes.
OUR LESSONS LEARNED
Mistakes (or lessons learned) are tuition costs on the way to knowledge. We have many lessons
learned that have improved our knowledge of deploying agile inside CMMI.
Our motivations for agile were well founded on previous use of XP and agile management, so we
were not novices, but we struggled with the political and organizational aspects. Several team
members came from prestigious XP shops in the Denver area. One senior member worked in this
shop as well as at a major aerospace firm where agile and earned value were used inside CMMI.
Other members had experience with agile methods in commercial and Web services firms. We
“talked the talk.” We had empowered teams, motivated management, and a clear sense that this
was going to work.
We were not prepared for the level of effort it takes to move an organization from “command and
control” to agile self–directed teams. Using the agile manifesto as a template, our difficulties are
summarized below.
Individuals and Interaction over Processes and Tools
Hanging on the wall in our primary work space is a “swim lane” chart of our CMMI Level 3
software process. It is 27 feet long and 4 feet high. This chart is our CMMI process map.
Moving the vocabulary from that chart to the vocabulary used in agile was very difficult. The
terms in XP were not only confusing, they were seen as obfuscating. Managers did not have a feel
for what the terms meant, how they were used, or even why we needed new terms to describe the
obvious.
Following a defined process was part of the air. We naïvely thought team building would be a
simple step toward agility. “We’ll have self–directed teams, we’ll have engaged customers, we’ll
do XP, and we’ll all move to a higher plane of existence!” It turns out installing self–directed
teams in a culture of “command and control” is very difficult. Allowing individuals to make
decisions that were previously made by functional and a line manager borders on insurrection.
“You simply can’t turn over the project to the team and the customer! Why, it’ll be chaos by the
first week.” And it was.
We had not prepared for the disruptive event [effect?] of removing the “command and control”
management structure had on the organization. As individuals, we had high expectations for
everyone. They’d become “self–actualized” to use Maslow’s term. What emerged was confusion
about being “self–directed.” Opinion ranged from autonomous decision making by the teams to
11/14
12. Cutter Journal, Jim Highsmith Editor
line managers thinking self–directed meant “come see me to confirm your direction.” Senior
management thought it meant “I don’t have to be concerned about the details, because you’re
self–directed now.”
It took several months to sort out how the teams were to interact with management, customers,
and internal audit functions. We had not planned for this, and our credibility as “change agents”
was damaged for not providing resources and training to move from our old “command and
control” to agile.
Working Software over Comprehensive Documentation
In our high–ceremony world, specifications are king. Replacing these specifications with working
software was a major cultural disruption.
Cards on the cubicle wall are not the same as walking through a 50 page document. The latter is a
linear process — reading the specification. The former is a multi–dimensional process where
someone with context and interpretation skills is needed to pull everything together.
We needed a “road map” to follow. This was provided by assembling the story cards to follow the
WBS of the master schedule. Encoding the cards with project WBS numbers was the solution.
Assigning effort in units of measure familiar to management – dollars and man hours. Velocity
was replaced with earned value to produce an accurate “estimate at completion” (EAC). 7
Customer Involvement over Contracts
Lack of customer commitment would be a likely problem, but in our case it was a lack of
developer commitment. The development team had too many projects on their plate and could not
dedicate their efforts to a single project.
There were to two false starts due to this lack of commitment. The solution was to move the
developers from our high rise building to the near by customer site, rather than have the
customers come to the development location. A trailer on the construction site was found where
customers and developers lived and worked on the project. Once this “forced” proximity was
created, the team jelled, and code started to appear that met the customer’s needs.
Responding to Change over Following a Plan
Change control and change management are core to CMMI. The formality of change
management is embedded in our culture is [of?] mission–critical systems development.
Introducing a “team based” change control process required embedding CM and SV&V staff on
the team. This staff was accustomed to receiving change packages through formal channels – the
Change Control Board (CCB).
We first attempted to keep the CCB and SV&V teams at the boundaries of the release cycles.
This created friction not from the XP team but from the CCB and SV&V team members. They
wanted to be “on the team” and operate inside the process. In the past they were in a hands–off
relationship, but now they wanted to be fully connected.
Finally, Success
Agile work processes can be installed in a CMMI framework if they can demonstrate:
7
The concepts of Earned Value Management can be easily found on the web. EV is used in
many industries. It has a “natural” connection to testable requirements and incremental and
iterative development.
12/14
13. Cutter Journal, Jim Highsmith Editor
• Agile practices exist independent of the team — in a “manual” — and are passed on to any
new members.
• Someone oversees the application of the agile “rules.”
• When the rules are not followed, there is an independent means to get the team back on track.
• The effectiveness of the rules and practices is measured in some way.
• The artifacts of the project are measured for quality, compliance with requirements, and
project performance.
• There is a means of adjusting the rules through some form of measurement.
• There is an independent assessment of the effectiveness of the agile process.
The search for “better” development methods is the goal of CMMI. Agile methods bring “faster”
and “cheaper” attributes to this search.
REFERENCES
[Ambl04] Ambler, Scott, “Answering the ‘Where is the Proof That Agile Methods Work’
Question,” www.agilemodeling.com, 2004.
[Beck99] Beck, Kent, eXterme Programming Explained, Addison Wesley, 1999.
[Beck02] Beck, Kent, Test Driven Development: By Example, Addison Wesley, 2002.
[Boeh04] Boehm, Barry, Windsor Brown, Victor Basili, and Richard Turner, “Spiral Acquisition
of Software–Intensive Systems of Systems,” CrossTalk, May 2004, pp. 4–9.
[Cock02] Cockburn, Alistair, Agile Software Development, Addison Wesley, 2001
[CMMI] Capability Maturity Model Integrated – Systems Engineering/Software,
www.sei.cmu.edu/cmmi/products/models.html
[CSE02] “Agile Methods and CMMI,” Annual research Review & Executive Workshop, Post
Workshop Progress Report, March 14, 2002
[Glaz01] Glazer, Hillel, “Dispelling the Process Myth: Having a Process Does Not Mean
Sacrificing Agility or Creativity,” CrossTalk, November 2001, pp. 27–30.
[Gold03] Goldenson, Dennis R. and Diane L. Gibson, “Demonstrating the Impact and Benefits of
CMMI®: An Update and Preliminary Results,” CMU/SEI–2003–SR–009, Software Engineering
Institute, October 2003.
[Herb94] Herbsleb, J., “Benefits of CMM–Based Software Process Improvement: Initial Results,”
CMU/SEI–94–TR–013, Software Engineering Institute, August 1994.
[High00] Highsmith, James A., Adaptive Software Development: A Collaborative Approach to
managing Complex Systems, Dorset House, 2000.
[Hump89] Humphrey, Watts S., Managing the Software Process, Addison Wesley, 1989.
[Kale02] Kalermo, Jonna and Jenni Rissanen, “Agile Software Development in Theory and
Practice,” Master’s Thesis, Software Business program, Department of Computer Science and
Information Systems, University of Jyväskulä, June 2002.
[Meke03] Mekelburg, Diana, “Project Expectations: The Boundaries of Agile Development,”
CrossTalk, April 2003, pp. 28–30.
[Moor02] Moore, Geoffrey, Crossing the Chasm, Harper Business, 2002.
13/14
14. Cutter Journal, Jim Highsmith Editor
[Pekk02] Abrahamsson, Pekka, Puti Salo, Jussi Ronkainen, and Juhani Warsta, “Agile Software
Development Methods,” VTT Publications 478, ESPOO 2002.
[Reif03] Reifer, Donald J., “XP and CMM,” IEEE Software, 20(3), pp. 14–15, 2003.
[Schw01] Schwaber, Ken and Mike Beedle, Agile Software Development with Scrum, Prentice
Hall, 2001
[SEI02] Capability Maturity Model Integration for Software Engineering, version 1.1, Staged
Representation, CMU/SEI–2002–TR–029, Carnegie Mellon, Software Engineering Institute,
2002.
[SEI04] Process Maturity Profile, CMMI V1.1, SCAMPI V1.1 Appraisal Results, 2003 Year End
Update, Software Engineering Institute, March 2004.
[Stap03] Stapleton, Jennifer, DSDM: Business Focused Development, Addison Wesley, 2003.
[STSC] “CMMI–SE/SW V1.1 to SW–CMM V1.1 Mapping,”
http://www.stsc.hill.af.mil/consulting/cmmi/cmmiseswippdv11.pdf.
Glen Alleman is Vice President of Program Management for CH2M HILL’s Communication
Group. CH2M HILL provides services to Rocky Flats Environmental Technology Site (RFETS) in
Golden, Colorado. Rocky Flats is a former nuclear weapons complex that is operated by the US
Department of Energy and is scheduled for closure by the end of 2006. Mr. Alleman’s office
provides project management services to the information and communications services groups at
RFETS. This involves program management, earned value management, portfolio management,
and direct involvement in over 300 software and infrastructure projects.
Before joining CH2M HILL, Mr. Alleman was the Principal Consultant for Niwot Ridge
Consulting, where he specialized in the management of enterprise application integration
projects for ERP, document management, and product data management systems in
manufacturing, petrochemicals, and electric utilities. Prior to his consulting work, Mr. Alleman
worked in a variety of aerospace and high–technology firms as a manager and technical
contributor. His education includes undergraduate and graduate work in physics at the
University of California as well as an MBA from the University of Southern California.
Mr. Alleman can be reached at CH2M HILL, Rocky Flats Environmental Technology Site, 10808
Highway 93, Unit B, Bldg. 060, MV72, Golden, CO 80502, USA. Tel: +1 303 966 5865; E–mail:
glen.alleman@rfets.gov.
14/14
View publication statsView publication stats