Leveraging Agile in the Project PPM World

In this article, I wanted to help detail out some of the more commonly used Agile disciplines for those who are wanting to understand or possibly leverage any one of these and find the right fit.

Key Article Topics Covered:

Understanding Agile Disciplines & Key Moving Processes

  1. Dynamic Systems Development Method (DSDM)
  2. Scrum
  3. Extreme Programming (XP)
  4. RUP
  5. Kanban and Lean Development
  6. Feature Driven Development (FDD)
  7. Crystal

Overview of Agile Disciplines Moving Parts:

Agile is comprised of many different frameworks and approaches that support a more interactive and feature prioritized and delivered model.

Collectively there are various methodologies that are known as agile.  They all promote the values of the agile manifesto and they are consistent with the above principles.   In this article, I will call out some of the most popular ones:

For example, DSDM is probably the original agile development method. DSDM was around before the term ‘agile’ was even invented, but it is based on all the principles we have come to know as agile.  DSDM seems not as well known outside of the UK.

Scrum is also an agile development method, which concentrates particularly on how to manage tasks within a team-based development environment.  Scrum is the most popular and widely adopted agile method – I think because it is relatively simple to implement and addresses many of the management issues that have plagued IT development teams for decades.

XP (Extreme Programming) is a more radical agile methodology, focusing more on the software engineering process and addressing the analysis, development and test phases with novel approaches that make a substantial difference to the quality of the end product.

DSDM is probably the most complete agile methodology, whereas Scrum and XP are easier to implement and complementary because they tackle different aspects of software development projects and are both founded on very similar concepts.

Agile methodologies fall typically under a structure of Values, Principles (for frameworks), then the actual methods for doing the development.

Let’s review and understand some of the main agile methodologies out there.

Dynamic Systems Development Method (DSDM):

Dynamic Systems Development Method or DSDM has its origins that go back to the early 1990s and originated because of the need to provide the technical community with a standard project delivery framework that was based on the very popular Rapid Application Development (RAD).  The widespread use and popularity of RAD around software development had grown in a way that there was little structure to its application.

To provide better software delivery processes and to promote a common industry framework, in 1994 the DSDM Consortium was created with this very specific goal in mind  The DSDM methodology has continued to grow and mature providing a great foundation for planning, managing, executing, and scaling agile in iterative software development projects.

There are nine basic principles that DSDM is based on.

They focus on the integration of team, customer, and stakeholders around delivering business value or “fitness for business purpose” as the primary criteria for delivery and acceptance and delivering the Pareto principle of 80% of the system value that can be delivered in 20% of the time.

In Technical development or solutions, there are 6 key values that DSDM teams work towards.

  1. Focus on the Highest Business Needs Value First
  2. Active User Involvement
  3. Empowered Teams
  4. Frequent Delivery of Features or Value
  5. Integrated Testing
  6. High Level of Stakeholder Collaboration

As a project/development team maps requirements, these requirements are baselined at a high level early in the project and as the team begins working on these requirements, rework is built into the process, allowing changes or modifications to be reversed for all development. Customer requirements are planned and delivered in short, pre-set length of time boxes called iterations.

You may have heard requirements prioritization using MoSCoW Rules, which refer to;

M – Must have requirements

S – Should have if at all possible

C – Could have, but not critical

W – Won’t have this time, but potentially later

All work prioritized at the highest level has to be completed. Not every requirement in a project or iteration is considered critical so that less critical features or items can be moved to other iterations to keep from affecting the highest priority requirements.

What is useful about the DSDM framework for project delivery is that it can be implemented with other methodologies such as Extreme Programming or the Rational Unified Process, making it a great option for very large-scale development projects.


Scrum is one of today’s more popular, and in the Agile realm, a more lightweight project management framework. It can be used broadly in technical project management to help to manage, direct, and control incremental or iterative projects. What makes is popular today is that its simplicity and proven ability for technical teams to utilize as well as to support engineering best practices and frameworks.

There are some great white papers and publications on this. Some of the main contributors to the growth and evolution of Scrum have been people like Jeff Sutherland, Ken Schwaber, and Mike Beedle.  I recommend reading some of their contributions and comments around effective use of Scrum.

If you would like to see some great success stories and case studies for Scrum, I recommend checking out this link:  https://www.scrumalliance.org/why-scrum/who-uses-scrum#sthash.3NXfUd32.dpuf

The Scrum process follows a series of sprints cycles that lead to a release of product or functionality to stakeholders or end-users. What is helpful here is that this is similar to a miniature Waterfall project lifecycle, all contained within delivering pre-defined functionality or features and allowing for the progressive elaboration of requirements with the end-users during the process. This ensures a higher satisfaction level by end-users and stakeholders, while still keeping the project confined to time-boxes.

With Scrum, several key roles work together in the Scrum process.

  • Product Owner
  • Scrum Master
  • Team
  • Stakeholders
  • Users

Many, working around Scrum teams have heard terms like “Chickens” and “Pigs”.  This refers to the classification of involvement around the Scrum Meetings that different stakeholders have.

As illustrated in this cartoon, “Chickens” only have involvement in the meetings, but “Pigs” are the people who are primarily speaking and actively involved.

The Scrum Master is the overseer of the process, the compilation, and recorder of progress, action items, features, what is moving from the backlog to the sprints, the facilitator of the team and the process, but not the director of the actual physical tasks.

Stakeholders and Users are actively working with or even embedded or collocated within the teams ensuring that immediate feedback and fine-tuning of the functionality will deliver the necessary value. This involvement allows planning to be at a higher level and requirements can unfold as the teams tackle the work in each sprint.

Scrum Team members, sometimes even cross-functional teams, work together to produce estimates and then sign up to deliver shippable or functional increments during successive sprints. Sprints can range from 1 week to 1 month, with the goal being enough time to deliver functionality to the end-users and stakeholders.  These time-boxed increments ensure that the focus is on working software or product.  Items not completed will be moved to later sprints or to the backlog for re-prioritization.

During the planning process, once a Sprint’s Product Backlog is committed to, no additional functionality or features can be added, except by the team itself.  After a Sprint is completed, the Product Backlog is analyzed and reprioritized, and the next set of features or functionality is selected and approved for the next Sprint.

The Product Owner works with the development team to help map out key functionality and then to prioritize the functionality into what is called the “Backlog”.  The Product Backlog consists of features, bug fixes needed, functional and non-functional requirements, what needs to be completed to successfully deliver a working system.

Anyone who has complex projects can benefit from using Scrum to help prioritize and manage large lists into manageable tasks with a high level of interaction amongst the delivery teams and the stakeholders and end-users.

Scrum, just like all the methodologies in this article have provided successful delivery to large and small projects with large and small companies worldwide alike.

Extreme Programming (XP):

Extreme Programming emphasizes teamwork. Managers, customers, and developers are all equal partners in a collaborative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible.

Extreme Programming and Scrum are similar, but there are some key differences between these two methods. Typically, SCRUM sprints last longer than XP iterations, for example, SCRUM may be 2-4 weeks, while the normal XP iterations 1-2 weeks. In addition, SCRUM teams do not allow changes in sprints, but XP teams are allowed to make changes within iterations.

XP is a disciplined approach to delivering high-quality software quickly and continuously. What makes XP useful is that you can leverage it within other frameworks, like TDD, Pair Programming, or Refactoring. It promotes high customer involvement, short and rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.

The original XP construct is rooted around on four simple values that guide the teams.

  • Simplicity
  • Communication
  • Feedback
  • Courage

From these four key values, it has twelve supporting practices for technical teams.

  1. Planning Game
  2. Small Releases
  3. Customer Acceptance Tests
  4. Simple Design
  5. Pair Programming
  6. Test-Driven Development
  7. Refactoring
  8. Continuous Integration
  9. Collective Code Ownership
  10. Coding Standards
  11. Metaphor
  12. Sustainable Pace

In XP, the “Customer” works very closely with the development team to define and prioritize the work units of functionality referred to as “User Stories”. What I like about “User Stories” is that for testers and end-users sometimes creating a description or a “story” is an easier way to elicit the functionality needed. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software. The user stories are completed on an iteration-by-iteration basis. Work is performed in the priority order to maximize productivity. The overall practices with XP provide a supportive, lightweight framework to guide a team and ensure high-quality software for stakeholders.

Rational Unified Process (RUP):

Another agile methodology is Rational Unified Process (RUP). RUP is an object-oriented and Web-enabled program development framework that supports development and development processes.

According to Rational developers (developers of Rational Rose and the Unified Modeling Language), RUP is an online guidance or solution program that provides guidelines, templates, and examples for all aspects and stages of program development.

For RUP and similar products, such as OPEN Process, Object-Oriented Software (OOSP), there are comprehensive software development tools, templates, and processes that allow you to combine the procedural aspects of development (such as defined phase, stages, techniques, and practices) with other elements of development (such as models, documents, documentation, and code, etc.) All of this is tied together within a unifying framework, hence Rational Unified Process or RUP.

Most people call Rational Unified Process, RUP.  It is a software development methodology from Rational. RUP organizes the development of software into four phases, each consisting of one or more executable iterations of the software at that stage of development.

Here are the key four RUP phases of development:

  1. Inception
  2. Elaboration
  3. Construction
  4. Transition

Each of these phases are organized into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken.

  • Inception:
    • At this stage, the project’s business case is stated and the team decides if the project is worth doing or if it is even possible. This is very important to the RUP process, to first formulate the scope of the project simultaneously determine what resources are required to be successful.
  • Elaboration:
    • At this stage, the developers take a more granular look at the project to determine its foundation, architecture, and evaluate the architecture in relation to the overall project, environment. At this stage, stage developers analyze the risks associated with changing the scope of the project or adding new technologies or solution approaches while the projects are underway.
  • Construction:
    • At this stage, the development work of the project is completed.  The source code is completely written and the application is ready to be tested to determine if the project has delivered the requirements identified in the inception phase.
  • Transition:
    • At this stage, any final adjustments, the delivery team performs fine-tuning. These final adjustments can be based on functionality, deployment experience or based on end-user feedback.

In RUP only what is useful and required is produced.  This is similar to Extreme Programming (XP). Within RUP, the development plan is updated throughout the process. Both RUP and XP methods seek to develop a system of best practices in software development.

Kanban and Lean Software Development:

Kanban is another framework for managing projects in an agile fashion. It is used by organizations to manage the creation of products with an emphasis on continual delivery and ensuring to not overload the development team.

Kanban came from the Toyota approach production system for “Just-in-Time” (JIT) delivery. While manufacturing automobiles is very different from software development, the approach form managing either a production line or a software development project has a similar application.

The approach between engineering, manufacturing, and supply-side management dates back to the 1940s. Toyota optimized its engineering process by modeling how grocery stores would keep its shelves stocked with just enough product to meet consumer demand. This practice focusses on the optimization of flow between one functional group and another.

By looking at how supermarkets maintained just enough inventory, not too much and not too little, and the efficiencies and savings gained by optimizing, Toyota brought that concept to their manufacturing floors. The idea is that when a team who is assembling components of a car, for example, the dashboard to the frame, would go and give a card, or a “Kanban” to each other signaling the need to pull more materials so they can continue to be productive. Just in time ordering or the flow of materials to those who need it would be timely and set at the pace that each group needs it.

Kanban Boards:

Kanban is based on three very basic principles.

  1. Visualize what you are doing today (existing workflow): Having visibility to see all the action items for each group.
  2. Limit or manage the amount of work in progress (WIP): This will help balance the flow of work so that it is not outstripping those who are downstream from the actual work. This avoids teams starting or committing to too much work at the same time.
  3. Enhance flow: When tasks are finished, then the team would work on the next highest priority task or project.  This next activity is pulled from the backlog and put into the process workflow.

Kanban promotes and makes visual continuous collaboration on activities. It encourages active, ongoing learning and improving by defining the best possible team workflow.

By applying this process to software teams, Kanban matches the amount of work in progress to the team’s capacity and ability to deliver. Kanban gives technical or solution teams more flexible planning options, faster output, clear focus, and visibility throughout the development cycle.

Kanban teams focus only on the work that is actively in progress. Once the team finishes a work item, they pull the next work item off the top of the backlog.  This backlog is prioritized by customer need or team requirements and the Product Owner is able to re-prioritize work in the backlog without disrupting the team since those changes are outside the current work items in progress.

A useful technique is adding time estimates to each card to help quantify the work effort in each phase.

Lean Development, Estimating & Planning:

Lean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. They felt that since software development is a continuous learning process based on iterations of code writing. Lean Software Development acknowledges that software design is a problem-solving process that involves the technical teams and developers surfacing and utilizing what they have learned through the development process. The success of Lean is that the software is measured in fitness for use and not in the conformance of that software to requirements.

Instead of adding more documentation or detailed planning, software teams can try different ideas in writing and developing code. The process of gathering stakeholder requirements is streamlined by presenting models or mockups to the end-users and getting their input. The efficiency and reduction of defects needing more testing is optimized by running tests as soon as the code is written.

Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” and the approaches or mechanisms that deliver that value.

The main principles of Lean methodology include:

  • Eliminating Waste
  • Amplifying Learning
  • Deciding as Late as Possible
  • Delivering as Fast as Possible
  • Empowering the Team
  • Building Integrity In
  • Seeing the Whole

Lean methodology seeks to eliminate waste through activities such as, selecting only the most valuable features for a system, then prioritizing those selected features, and finally, delivering them in small batches. It focuses on the speed and efficiency of development workflow and relies on rapid and reliable feedback between developers and stakeholders.

Lean leverages the concept of work product or deliverables being “pulled” via customer requests. It focuses on individuals or development teams and their ability to make decisions since research shows this to be faster and more efficient than hierarchical flow decision-making control.

Another important aspect of Lean is the efficiency and use of team resources. The goal is to ensure that every team member is productive as much as possible. Lean improves efficiencies through the completion of development being accomplished with the fewest possible intra-team workflow dependencies. When using a Lean approach to software development, it is strongly recommended that automated unit tests be created at the same time the code is written, increasing the efficiency and validation of that programming.

Some of the tools of a Lean Software Development process are:

  • Daily Standup Meetings
  • Cumulative Flow Diagrams
  • Virtual Kanban Systmes
  • Visual Controls
  • Small Batch Sizes / Single Piece Flow
  • Retrospectives
  • Operation Reviews

Lean can leverage other frameworks or can be implemented with other software development processes and methodologies. For example, Scrum or Test Driven Development (TDD).

Feature Driven Development (FDD):

Feature Driven Development (FDD) is another variation of the agile methodology. It is a model-driven, short iteration process for delivering technical solutions.

Again, as other Agile disciplines, this was born out of a need to focus on the key features that stakeholders needed. As well as having the technical teams focus development efforts in complete alignment in producing this value.

Feature Drive Development was created by Jeff De Luca and had major contributions and influences by Jon Kern, Stephen Palmer, M.A. Rajashima, Lim Bak Wee, and Paul Szego. If you do any searching, these contributors have great writings, comments, and white papers embellishing upon the process and use of FDD.

With Feature Driven Development, you start with an overall shape for a solution and then continues with a series of iterations, usually two week periods, that focus on “design by feature” or “build by feature” iterations.  Each iteration is small in order to help produce results that are the most useful to customers. FDD designs all of its development processes around key feature implementation that following these key 8 practices.

  1. Domain Object Modeling
  2. Developing by Feature
  3. Component/Class Ownership
  4. Feature Teams
  5. Inspections
  6. Configuration Management
  7. Regular Builds
  8. Visibility of Progress and Results

FDD best practices guide the programming team to follow “Regular Builds” and “Component/Class Ownership”. Scaling for large development projects or programs is more straightforward than other approaches. Plus it is more usable for larger teams on cross interconnected projects.

FDD as a development methodology differs from other methodologies in that it has very specific, short phases of work, which are geared around each feature identified by the customer. Key phrases within FDD are:

  • Domain Walkthrough
  • Design
  • Design Inspection
  • Coding
  • Code Inspection
  • Promote to Build


Crystal is a family of agile software development methodologies. These methodologies were based on his research of ten years, where he studied the properties of successful projects. This research showed two key elements. First, the properties of projects changed based on the number of people involved. Second, the criticality of the project, ranging from loss of discretionary money to the loss of life had a direct impact on the team and their success.

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies.  Examples of these are Crystal Clear, Crystal Yellow, Crystal Orange, and others. Those of which unique characteristics are driven by several factors such as team size, system criticality, and project priorities.

This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project‘s unique characteristics.

Crystal is not “all or nothing”.  Teams using other agile frameworks like RUP, XP or other methodologies can “borrow” useful techniques from Crystal Clear.  Similarly, if you are using the Crystal Clear method, you can also leverage from other methodologies.

Crystal introduces the importance of people and communications and adjusting the techniques used in a project to the characteristics of that particular project. While other software development methods, particularly other agile methods, do stress the importance of people, the Crystal family uses a focus on people and communications as its organizing principle. Most of the properties and techniques are based on strengthening that process.

The chart below helps reference the right Crystal method starting point for a team.

Along the x-axis is the size of the team. As a team gets larger (more team members), it moves to the right along the x-axis.  That means it is harder to manage the process via face-to-face (which is one of the key values in Crystal). It increases the need for coordinating on documentation, development practices, and tools.

The y-axis addresses the system’s potential for causing damage. The lowest damage impact is loss of comfort, discretionary money, essential money, and finally loss of life.

Essentially the graph uses the team’s size and the criticality of the system being developed or worked on. Additionally, it helps identify the corresponding Crystal methodology. Each of the different methodologies has a set of recommended practices, a core set of roles, work products, and techniques for how to work.

The key tenets of Crystal include teamwork, communication, and simplicity. As well as reflection to frequently adjust and improve the process. Like other agile process methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.

In Summary

I hoped you enjoyed this overview of Agile disciplines and key concepts around Agile in a Project PPM world.

As we continue with additional articles, I think you will find that MS Project and Microsoft PM tools fit well within this framework.

If you saw an example or template that intrigues you, please reach out to me directly at Tim.Runcie@Advisicon.com.  I’d love to share these with you and help your continued journey with Microsoft PPM and Agile disciplines.