From AgilePM wiki
Revision as of 17:53, 14 December 2016 by Frank (talk | contribs) (Build Incrementally from Firm Foundations)

Jump to: navigation, search

Introduction to the AgilePM Principles

AgilePM has eight principles that support the philosophy: “best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motived and empower people”.

These principles act as guide for the team and organization (attitude, mindset and culture) to remain flexible, deliver consistently and often. In other words, the principles are a guide to a way to thinking and working. If the team does not follow any of the principles, they will just help to undermine the project and introduce risk. The team can expect to get the full benefits of the AgilePM approach if they follow all eight principles.

The eight DSDM principles are:

  1. Focus on the business need
  2. Deliver on time
  3. Collaborate
  4. Never compromise quality
  5. Build incrementally from firm foundations
  6. Develop iteratively
  7. Communicate continuously and clearly
  8. Demonstrate control

Focus on the Business Need

Every decision taken during a project should be viewed from the view point of the project goal and this should be to deliver what the business needs to be delivered, when it needs to be delivered. It is important to remember that a project is only there to deliver the required product.

In order to fulfil this principle, AgilePM teams will:

  • Understand the business priorities and this must be documented
  • Create a valid business case which is easy to understand
  • Ensure continuous business sponsorship and commitment:
  • ​​​Guarantee delivery of the Minimum Usable Subset meaning that not all requirements have to delivered and the more important requirements are prioritized.

This principle is supported by:

  • Roles:
    • Business Sponsor (BS)
    • Business Visionary (BV)
  • Products:
    • Business Case (by Business Sponsor)
  • Techniques
    • MoSCoW – prioritization technique
    • Timeboxing

Deliver on Time

Delivering a working product on time is a desirable outcome for a project. Delivering on time can be the most important success factor for some projects especially if the project is trying to bring a new product to market before the competition or to meet legal requirements. Delivering on is the best way for the project to demonstrate control and maintain business confidence.

In order to fulfil this principle, AgilePM teams need to:

  • Timebox the work in manageable chunks of time
  • Focus on business priorities using MoSCoW (know what is more important)
  • Always hit deadlines of time, cost, quality
  • Build confidence through predictable delivery

Combining the AgilePM techniques of timeboxing and MoSCoW prioritization enables AgilePM teams to protect deadlines whilst being flexible with the features. Each requirement should be estimated: size, priority and complexity so it can be compared to other requirements.

This principle is supported by:

  • Roles
    • Project Manager (PM)
    • Team Leader(TL)
  • Techniques
    • MoSCoW
    • Timeboxing


It is known that team that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association. Collaboration encourages  increased understanding, greater speed and shared ownership, which enable teams to perform at a level that exceeds the sum of their part and be much more productive.

In order to fulfil this principle, AgilePM teams need to:

  • Involve the right stakeholders, at the right time, throughout the project
  • Encourage pro-active involvement from the business representatives (pull them into the project and make them part of it)
  • Ensure that all members of the team are empowered to take decisions on behalf of those they represent. There is no room for micro management in AgilePM.
  • Build a one-team culture

AgilePM’s roles of Business Visionary, Business Ambassador and Business Advisor roles bring the appropriate subject matter experts into the project so they can contribute to the solution. Of course it is important that each role understands their role and responsibility and each roles knows what they can expect from another.

The Solution Development Team brings together business and technical roles in a single team.

The Business Analyst (BA) is responsible for facilitating high level collaboration between team members while the Team Leader taking responsibility for facilitating a high level of collaboration  between all Solution Development Team members.

Facilitated workshops enable stakeholders to share their knowledge effectively with other members of the project team.

This principle is supported by:

  • Roles
    • Business Sponsor (BS)
    • Business Visionary (BV)
    • Business Ambassador (BAMB)
    • Solution Development Team (SDTs)
    • Workshop Facilitator (WF)
  • Techniques
    • Facilitated Workshops
    • Daily Stand-ups (like Scrum Stand-up meetings)

Never Compromise Quality

In AgilePM, the level of quality to be delivered should be agreed at the start of the project. All work should be aimed at achieving that level of quality and not more or no less that than this. A solution has to be ‘good enough’ to meet the business need and it does not need to be gold plated. A perfect solution is too expensive.

In order to fulfil this principle, AgilePM teams need to:

  • Agree the level of quality from the outset, before development starts
  • Ensure that quality does not become a variable
  • Test early, test continuously and test to the appropriate level
  • Build in quality by constant reviewing and testing
  • Design and document appropriately. E.g. document the acceptance criteria

Testing has to be integrated into the Iterative Development process, with regular reviews throughout the project lifecycle. This helps the AgilePM team to build a quality solution.  The review and quality control products created as the project proceeds help demonstrate  that the quality of the solution is meeting the expected standard.

Using AgilePM, everything is tested as early as possible. AgilePM also uses the thinking of fail fast and this speeds up learning what will not work and find a solution. The MoSCoW prioritisation and timeboxing techniques are used to ensure that testing is appropriate and under taken without introducing unnecessary risks. 

In an IT project, the use of test-driven development techniques can also significantly improve the quality of the solution by ensuring that the acceptability of the solution is understood before development starts.

If the business agrees feature in Minimum Usable Subset has been provided, then the solution should be accepted. So no more development.

This principle is supported by:

  • Roles: Solution Tester (ST)
  • Products: Testing products
  • Techniques
    • Timeboxing
    • Daily Stand ups
  • Early and integrated testing
  • Regular reviews throughout lifecycle

Build Incrementally from Firm Foundations

One of the key differentiators for AgilePM within the Agile space is the concept of establishing firm foundations for the project before committing to significant development. The AgilePM approach advocates first understanding the scope of the business problem to be solved and the proposed solution, but not in such detail that the project becomes paralysed by too much detail.

Once firm foundations for development have been established, the AgilePM approach advocates incremental delivery of the solution in order to deliver real business benefit as early as is practical. This helps to deliver early ROI for the project. This incremental delivery encourages stakeholder confidence, offering a source of feedback for use in subsequent Timeboxes and may lead to the early realisation of business benefit.

In order to fulfil this principle, the AgilePM teams need to:

  • Carry-out appropriate analysis and enough design up front (EDUF)
  • Formally re-assess priorities and informally re-assess ongoing project viability with each delivered Increment

AgilePM teams implement this principle through the appropriate application of a project lifecycle, which delivers a solid base of knowledge during Feasibility and Foundations phases before building the solution incrementally during the Evolutionary Development phase.

This principle is supported by:

  • Techniques
    • Iterative Development (IPER cycle)
    • AgilePM Lifecycle