CMMI Ltd Agile Support

With an Agile approach, the product is designed, developed, tested and delivered incrementally, using short, time-boxed iterations. See Agile Practices or go straight to CMMI Ltd approach to Agile. The information gained from each iteration is used to improve both the product and the process.  Note that when Test-Driven Development is used, as described below, tests are written before the code is developed.  See Criteria for Selecting an Agile Approach.

The program starts with the creation of a prioritized product backlog that contains a list of the features that are desired in the product.  The features in the product backlog are implemented through a series of 2-4 week iterations, where the team selects the highest priority items in the product backlog to create the iteration backlog, and then implements those features and presents for testing prior to customer and other stakeholders acceptance at the end of the iteration.

Customer feedback from the iteration or other changes in customer needs drive changes to the product backlog that can be considered for the next or future iterations.  Each iteration produces potentially shippable software, although in practice it is common for programs to release individual iterations to an internal team or customer surrogate, and release to the external customer less frequently, about every 3-6 months.  In some cases, iterations are released to user testing/demonstration for extended testing in an ops-like environment before being certified for operational use.

Each day the team members meet for a short 15 minute stand up meeting to examine progress and identify issues.  They also hold a evaluation review (40 – 60 minutes) at the end of each iteration to identify areas for improvement. 

The Agile Life Cycle below generally works well for small programs, or with a total size no more than twelve iterations

CMMI Ltd supports the Agile approach for software development if it is based on sound practices by skilled staff.  Agile should become a culture of best practice and whilst not all of the Agile Methodologies are applicable all of the time it is necessary that they are all understood.  CMMI Ltd can turn around a failing software development project by adopting an Agile approach or at least identify why it will fail before any more funding is wasted.  CMMI Ltd can provide

  1. Project Management

  2. Processes and Procedures

  3. Risk Assessment

  4. Training

  5. Staff recruitment

  6. Team building

  7. In a relatively short period of time leave an organisation with a team that can be successful in implementing software engineering

Sorry, Agile specific templates are available only through the consulting service.

Agile Lifecycle

The key to success with this approach is to focus on technical excellence throughout the development process.  This requires deploying skilled developers who have a thorough under standing of how to mix an match best practices.  Programs that adopt short iterative cycles without focusing on the production of quality software frequently fail to achieve the benefits associated with an Agile approach.

Tailoring the Agile Lifecycle for a Large Program

While the life cycle above is still at the heart of the Agile Life Cycle for a larger program, several modifications are needed to scale the Agile approach to accommodate the work of multiple teams.  These include:

·       Establishment of program plans to support Agile development within the larger program context.  Within a development program, it is often the case that Agile will be used only for a portion of the development effort.  When that is the case, the program plan and supporting plans (SEMP, SDP, Master Test Plan, etc) need to define how the Agile activities will interact with and support the rest of the program.  This includes defining how requirements traceability will be handled, how the Agile products will be integrated with the rest of the system, what the Agile role is in program reviews, and how interfaces between Agile and non-Agile components will be managed.  See Agile Estimate and Planning Quick Reference Sheet.

·       Establishment of a system architecture definition. With only a single small team, it is common to establish the system architecture during the first iteration, and refine it over time.  On larger programs, it is recommended that a system architecture be created to define the major components of the system and the boundaries within which the individual Agile teams will work prior to beginning iterative work by multiple teams.  The initial architecture will still evolve over time, but that evolution must be managed across the teams more formally than if there is only a single team.

·       Establishment of a Program Release Plan.  Frequently small teams release capability to their customer at the end of each iteration.  In such a case, there may be no need for a release plan since each iteration is a release.  On a larger program, there is frequently a need to group several iterations together for release to a customer.  In that case, the release plan defines the capability that will be released at the end of the group of iterations.  On very large programs with multiple releases, the release plan guides the content of the series of releases that are needed to deliver full program capability.  The program needs to consider what capabilities will be released in what order and must ensure that the system architecture supports a phased release of capabilities. 

·       On a large program, major development aspects are iteratively broken down to a level that identifies cross-team dependencies.  It is a common practice for acceptance tests for a feature to be completed one or more iterations before implementation begins.   This contrasts with the practice of completing the acceptance tests as part of an iteration, which is frequently the approach used on smaller projects.   On large projects, product backlog items also require more formal means of capture and collaboration. Communication has to be in clearly documented when developments teams are not collocated, this includes the requirements database and a current schedule.

·       Additional integration.  While team members can integrate their work within the team on a daily basis, it is often a good idea to integrate between teams less often.  A common approach is for each team to deliver their integrated product to a program-level integration team at the end of the iteration for integration with the work of other teams.  As a rule of thumb, the more dependencies, the more often integration is needed.  If two teams have substantial dependencies, they may need to integrate daily or every few days rather than wait until the end of an iteration.  Architectural partitioning of the system should be done in such a way as to minimize dependencies as much as possible to facilitate integration.

·       Additional levels of testing.  While a single-team project can usually do adequate testing within the scope of an iteration, it is quite common for large programs to need a period for system testing to address issues that cross teams, such as performance, security, reliability, etc. 

·       Additional formality and documentation. Since all of the individuals on a large program cannot be collocated, larger programs will need to rely more on documentation and will need some degree of formality for approving development progress.  When adding formality and documentation it needs to be kept to a minimum, and based on standard templates identifying the documentation requirements.  Larger programs traditionally have formal reviews such as PDR and CDR (DR3) that require more documentation than is traditional for an Agile program.  When such documentation is needed, it should be prioritized along with the rest of the items in the product backlog and scheduled as part of the work in iterations leading up to the reviews.

·       Iterative development of user documentation.  Include backlog tasks to create / update. every iteration in order to keep documents up to date and ready to deliver.  It is sometimes not possible to create System Administrator Manuals, User Manuals, Training Manuals, etc until new product features have been incorporated.  If the demonstrations at the end of an iteration usually result in many changes, you may want to update the documents one iteration after the product is demonstrated, but you should usually not defer all documentation to the last iteration.

For each individual release, the life cycle for the release would be as shown in Figure 4.  Release contents are refined through the Continuous Planning and System Evolution activities.  During that time, the teams update release plans with additional detail, tentatively allocate capability to cycles or iterations, and identify dependencies between teams. 

Maintaining the same iteration length for all teams on a project greatly simplifies coordination between teams and provides multiple synchronized opportunities for integrating across teams.  This may be balanced by calculating the man hours for an iterations and structuring the team size accordingly.  In order to keep a consistent iteration duration across teams, it may be necessary to break up large features into multiple features that can be implemented in successive iterations to reduce the work allocated to a team for a single iteration, or to pull in related but lower priority features to give a team enough work for the duration of the iteration.

It is highly recommended that all teams start/stop their iteration in the same week but due to unforeseen development problems it will not always be possible.  The iteration integration can be managed by allocating a period for verification starting with the development team that finished first leaving additional time to address issues.   CMMI Ltd would support the verification being undertake and approved by someone other than the development team.



Scrum comes from the rugby term and represents getting in a tight group heads down to solve a problem as a team.  The Scrum methodology focuses on the management and control of software products using an incremental/iterative approach.  Key roles for Scrum include:

  1. Stakeholder, who represents the voice of the customer.

  2. Scrum Master, who facilitates team activities and removes impediments to the ability of the team to deliver the iteration goal.

  3. Team, with the responsibility to deliver the product.

Once a team starts working on the tasks for an iteration (a Sprint in Scrum terminology) no external interruptions or changes of direction are allowed.  This allows the team to focus their attention on completing the tasks needed to accomplish the goals of the iteration.  The stakeholders working with the team provide clarification throughout the iteration, and are considered part of the team.

Scrum makes it possible to wrap an organization’s existing engineering methods into a controlled, iterative process.  It fact this is vital and it means all the teem need to understand the documented best practices.  Scrum does this by combining existing methods with Agile methods to provide a simple and balanced approach to Agile development.  Scrum has also been proven to be able to scale to multiple teams across programs consisting of over 800 people. 

For the above reasons, Scrum has become very popular in the commercial software community and is the basis for many of the Agile practices defined in this document. 

For Scrum to succeed long-term, teams must produce maintainable software;  otherwise, they are often not able to sustain the velocity needed to achieve program goals.

For additional information see http://www.scrumalliance.org/.

Extreme Programming (XP)

XP is the one of the earliest and most familiar of all Agile methodologies.  Introduced in 1999 as an alternative to the traditional heavyweight approaches that are often-times overkill for smaller programs, XP strictly adheres to the Agile principles while embracing sound software engineering principles, XP focuses on delivering timely software that meets customer requirements rather than focusing on the processes that often accompany large development efforts.

The underlying assumption for XP is that the high cost of change has been addressed by technologies such as objects, patterns, relational databases, information hiding, etc.  Because of this, XP focuses on rapid feedback, simplicity, incremental change, embracing change and quality work.


XP rigorously adheres to the 11 XP practice.

  1. The planning game:  determine the scope of the next release, based on business priorities and technical estimates.

  2. Small releases:  every release should be as small as possible, containing the most valuable business requirements.

  3. Metaphor:  guide all development with a simple, shared story of how the whole system works.

  4. Simple design:  design for the current functionality, not future needs and make the design as simple as possible for that functionality.  CMMI Ltd would however advocate that whilst a modular approach is applied this does not preclude starting with the end in mind.

  5. Refactoring:  ongoing redesign of software to improve its responsiveness to change.  Again without a long term aim this approach can become costly without delivering new functionality.

  6. Test-Driven Development:  developers write the unit tests before the code; unit tests are run “continuously”; customers write the functional tests.  The key to achieving this is to have the requirements clearly documented a the ability to record traceability.

  7. Pair programming:  an extreme form of inspection; two people sit in front of the same terminal to write test cases and code.

  8. Collective ownership:  anyone can change any code anywhere in the system at any time.

  9. 40-hour week:  Be smart let the software developers work where they want and when some may work well at 2am.  Work no more than 40 hours as a rule; never work overtime two weeks in a row.

  10. On-site customer:  have a real user on the team full time.

  11. Coding standards:  must be adhered to rigorously because all communication is through code.  This requires developers undertaking code reviews against a defined standard.

As its name indicates, XP is an extreme implementation of Agile principles and practices, geared towards small programs.  For this reason limit the use of XP to small programs unless they wrap XP in another methodology such as Scrum. 

For additional information see http://wiht.link/extreme_programming .

Dynamic System Development Method (DSDM)

DSDM emerged from a pre-Agile approach to software development called Rapid Application Development (RAD).    DSDM consists of 3 phases:  pre-project phase, project life cycle phase, and post-project phase.  The project life cycle phase is subdivided into 5 stages:  feasibility study, business study, functional model iteration, design and build iteration, and implementation.  DSDM has 9 underlying principles:

  1. Active user involvement is imperative.

  2. The team must be empowered to make decisions.

  3. The focus is on frequent delivery of products.

  4. Fitness for business purpose is the essential criterion for acceptance of deliverables.

  5. Iterative and incremental development is necessary to converge on an accurate business solution.

  6. All changes during development are reversible.

  7. High level scope and requirements are baseline before the project starts.  This requires ensuring the customer has a clear understanding of the project aims.   Utilize UDI presentations to obtain sign up.

  8. Testing is integrated throughout the project lifecycle.

  9. Communication and cooperation among all project stakeholders is required.

A distinguishing characteristic of DSDM is its emphasis on rapidly delivering the features that provide the most value to the customer, and deferring any other work until a later time.  DSDM specifically focuses on the 80% of useful features that can be delivered in 20% of the time of the overall program.

DSDM may be useful on Information Systems projects that are characterized by tight schedules and budgets.  For additional information see http://en.wikipedia.org/wiki/Dynamic_Systems_Development_Method.

Feature Driven Development

FDD is client-centric, architecture centric, and pragmatic.  It provides just enough process to ensure scalability and repeatability and encourage creativity and innovation along the way.  FDD uses a five step process that focuses on developing an overall “shape” object model, building a features list, and then planning-by-feature followed by iterative design-by-feature and build-by-feature steps. 


 FDD is unique from the other methodologies in that it balances the waterfall approach with the iterative Agile approach.  The result is an approach that begins with up-front domain modeling from a client-valued functionality perspective.  The models are decomposed into lists of small features.   Once the features have been identified, a series of short iterations begin in which a two week design phase is followed by a two week implementation phase.

One of the advantages of FDD is that the management process allows easy visibility into the progress of features under construction.  Proponents also claim that FDD is the easiest Agile methodology to scale up to large programs.  Therefore, FDD may appeal to larger programs that need tighter control over the planning and managing aspects of a program. 

For additional information see http://en.wikipedia.org/wiki/Feature_Driven_Development .

Lean Software Development

Lean Software Development is an approach that translates lean manufacturing practices and principles to the software development domain.  The Lean approach is very consistent with the principles and practices outlined in the Agile Manifesto.  With Lean, work is driven using a “pull” approach, where features are only built in response to customer request.  In order to respond quickly to the customer, Lean places particular emphasis on the reduction of wasteful, non-value added activities that slow down the workflow.  The Lean approach advocates organizing into small, collaborative autonomous teams that produce batches of features in short iterations.

Key principles behind Lean Software Development, and a set of tools for implementing those principles, have been defined by Mary and Tom Poppendieck in their book Lean Software Development.  These principles, with associated tools, include:

  1. Eliminate waste, using the tools Seeing Waste and Value Stream Mapping

  2. Amplify learning, using the tools Feedback, Iterations, Synchronization and Set-based Development

  3. Decide as late as possible, using the tools Options Thinking, the Last Responsible Moment and Making Decisions

  4. Deliver as fast as possible, using the tools Pull Systems, Queuing Theory and Cost of Delay

  5. Empower the team, using the tools Self Determination, Motivation, Leadership and Expertise

  6. Build integrity in, using the tools Perceived Integrity, Conceptual Integrity, Refactoring and Testing

  7. See the whole, using the tools Measurements and Contracts.

Consider using lean principles and tools in conjunction with other Agile methodologies.

For additional information see http://en.wikipedia.org/wiki/Lean_software_development.  

Adaptive Software Development

Traditional methodologies often employ a “plan-deliver-review” approach based on the assumption that system functionality is reasonably predictable and changes can be managed in order to achieve the original plan.  The ASD methodology offers an alternative “speculate-collaborate-learn” approach for environments where change is the norm.  Rather than unrealistically attempting to initially plan the final system state and then doing whatever it takes to “make plan”, ASD places emphasis on developing loose plans and then skillfully adapting to changing requirements.  Its underlying philosophy is that adaptation is more important than optimization.    Another key aspect of ASD is its focus on favoring a leadership-collaboration management style over command and control management.   Figure below shows a high-level perspective of the ASD Life Cycle.

ASD may be appropriate for programs with domains where requirements are likely to change frequently 

For additional information see Adaptive Software Development by James A Highsmith III.

Agile Unified Process

The Agile Unified Process is a simplified version of the Rational Unified Process (RUP).  It provides an approach for developing business application software using Agile techniques and concepts while still following the RUP framework.

AUP is serial in the large, with the traditional four RUP phases of Inception, Elaboration, Construction and Transition.  In the small, however AUP is iterative.  Modeling, Implementation, Testing, Deployment, Configuration Management, Project Management and Environment Support are performed iteratively to build, validate and deliver working software.  

AUP teams deliver development releases into pre-production staging area(s) at the end of each iteration.  A development release of an application is software that is potentially releasable after it has been through the pre-production quality assurance, testing and deployment processes. 

  1. The principles behind AUP include:

  2. Your staff knows what they are doing

  3. Simplicity

  4. Agility

  5. Focus on high-value activities

  6. Tool independence

  7. Tailor AUP to your own needs

A high level view of the AUP Life Cycle is shown below

AUP is a good choice for programs that want a process in between XP and traditional RUP. 

For additional information see http://www.ambysoft.com/unifiedprocess/agileUP.html .

Further Agile References

An Introduction to Agile Concepts:   Wikipedia has a very good description of Agile principles, practices and methodologies.  It is a good starting place for anyone with little or no knowledge of Agile.  http://en.wikipedia.org/wiki/Agile_software_development.  The Agile Alliance (http://www.agilealliance.org/) is also a good source for information.  For a list of alternative best practices the agile modeling by Scott W Ambler provides a good source of information.  www.agilemodeling.com

Scrum:  Scrum is one of the most popular Agile methodologies.  Mike Cohn’s web site has a lot of training material for individuals new to Scrum, as well as several good articles on various Agile topics.  Mike Cohn’s classes are recommended for individuals seeking certification as Scrum Masters.    http://www.mountaingoatsoftware.com.  The Scrum Alliance (http://www.scrumalliance.org/) is also a good source for information.    

Lean:  Mary and Tom Poppendieck’s web site has excellent information about Lean Software Development and Agile management.   http://www.poppendieck.com


D17 Build Automation E21 Retrospective Review of Each Itteration T20 Demonstrations at End of Each Iteration T19 Automated Testing T18 Test Driven Development D16 Refactoring D15 Continuous Integration D14 Pair Programming D13 Coding Standards D12 Minimum Documentation R11 Product Backlog R10 User Stories R9 Visible Progress Indicators C8 Teams of Teams C7 Visible Progress Indicators C6 Daily 14 Minute Meetings C5 Collocated Teams C4 Clear Product Vision P2 Continuous Planning P3 Self Directed Teams P1 Short Time Box Iterations AGILE PRACTICES Click on blue boxes for details Page-1

Go to CMMI Ltd Agile Approach