DSDM® AgilePF® - Agile Project Framework (6th version / 2014)

1. Current DSDM® Consortium products family

1.1. DSDM® Consortium products history in a nutshell

1.1.1. positioning DSDM® AgilePF® in comparision to other Agile approaches

2. Dynamic Systems Development Method (DSDM®) Agile Project Framework (AgilePF®) - an iterative, incremental and adaptive (change-driven / empirical) agile project management method and framework (not just framework like Scrum) originally from UK and was intended for software development projects (but can be easily adopted to any business domain). It has very long history of development - 20 years with 6 releases/versions, which makes it one of the oldest Agile project Management methods. DSDM® is seen as a hybrid method, which combines project management / delivery with product development / construction into one lifecycle and method. DSDM® can be easily managed together within programme using Agile Programme Management method (AgilePgM®. DSDM® and AgilePgM® were created by DSDM® Consortium - www.dsdm.org

2.1. Dynamic Systems Development Method (DSDM®) 1st version was published in early 1995 (with training and accreditation scheme).

2.2. Version 2 was published in 12.1995.

2.3. Version 3 was published in 10.1997.

2.4. Version 4 was published in 2002 (online only).

2.5. Version 4.1 was published in 02.2003 (online only).

2.6. Version 4.2 was published in 01.2003 (online only).

2.7. Version 5 (called DSDM® Atern®) was published in 06.2008.

2.7.1. The portmanteau Atern, is derived from the "Artic Tern" - a collaborative bird[citation needed] that can travel vast distances, whose characteristics reflect agile behaviour

2.8. 6th (current, newest) version was published in 20th anniversary of DSDM® in 07.2014 and was named "The DSDM® Agile Project Framework"

2.8.1. Overview of changes in newest 6th version from 2014

3. DSDM® Fundamentals

3.1. What is DSDM®?

3.1.1. DSDM® project delivery framework and methodology that delivers the right solution at the right time.

3.1.2. An iterative, incremental and adaptive project management methodology.

3.1.2.1. Less sequential.

3.1.2.2. Different style than waterfall (no better or worst - just different).

3.1.3. DSDM® method was created in 1994.

3.1.4. DSDM® is a framework rather than a method.

3.1.4.1. It does not say how things should be done in detail, but provides a skeleton process and product descriptions that are to be tailored to suit a particular project or a particular organisation.

3.1.5. DSDM® integrates:

3.1.5.1. project management lifecycle

3.1.5.1.1. e.g. PRINCE2®, PMBOK5®

3.1.5.2. product development lifecycle

3.1.5.2.1. e.g. Scrum, FDD, TDD

3.1.5.3. which means that DSDM® can bee seen as a hybrid methodology

3.1.6. Right business solution is delivered because

3.1.6.1. The project team and other significant stakeholders remain focused on the business outcome.

3.1.6.2. Delivery is on time ensuring an early return on investment (ROI).

3.1.6.2.1. On time due to short time interval of Timeboxes

3.1.6.3. All people involved with the project work collaboratively to deliver the optimum solution.

3.1.6.3.1. Even lowest level them members like SDTs (developers, testers, graphics designers etc.)

3.1.6.4. Work is prioritised according to business need and the ability of users to accomodate changes in the agreed timescale.

3.1.6.5. DSDM® does not compromise on quality, i.e. the solution is not over- or under-engineered.

3.1.6.5.1. Solution is fit for purpose

3.1.7. DSDM® agility

3.1.7.1. Avoids cumbersone rigidity of "Big Design Up Front (BDUF)" with the inevitable risks of "no design" up front.

3.1.7.2. DSDM® advocates that projects should do just "Enough Design Up Front (EDUF)".

3.1.8. DSDM® flexibility

3.1.8.1. DSDM® can be used to complement other project management disciplines (PRINCE2®, PMBOK® Guide).

3.1.8.2. DSDM® can also incorporate other agile delivery approches (development techniques) such as eXtreme Programming (XP) and SCRUM.

3.2. How DSDM® addresses key project problems?

3.2.1. Ineffective communication

3.2.1.1. Poor communication is highlighted time after time as a major failing on projects.

3.2.1.2. How DSDM® helps?

3.2.1.2.1. DSDM® emphasis on human interaction (e.g. Facilitated Workshops), visualization (e.g. Modelling, Prototyping) and clearly defined roles is at the heart of improved project communication.

3.2.2. Late Delivery

3.2.2.1. Slippage of the completion date causes much frustration, as well as causing significant knock-on effects for a business.

3.2.2.2. How DSDM® helps?

3.2.2.2.1. DSDM® sees this issue as one of the most important problems to address and DSDM®'s approach and many of the DSDM® practices are geared towards always being on time.

3.2.2.2.2. If there is ever a need for compromise on a project, DSDM® advocates that revising the scope of what is delivered should always be considered ahead of a extending the deadline that compromising the deadline is not an option.

3.2.3. The delivered solution does not meet the business needs (not just requirements)

3.2.3.1. Frustration is that when the solution is delivered, it doesn't meet the expectations of the business.

3.2.3.1.1. Due to bad requirements understanding, it may have features that don't do what the business really wanted it to do, or contain errors which prevent the deliverable from performing smoothly, or it simply might not be properly aligned with business processes.

3.2.3.2. How DSDM® helps?

3.2.3.2.1. In DSDM®, getting the correct understanding of the needs of the business is of paramount importance.

3.2.3.2.2. DSDM® encompasses practices which encourage collaboration and enable visual and verbal communication.

3.2.3.2.3. Most importantly, DSDM® teams are encouraged to embrace change, allowing them to deal with problems and opportunities that occur, to encompass new ideas that appear and to build the solution based on a deepening understanding of the solution detail.

3.2.4. Building the right thing - the business changing their mind

3.2.4.1. A frequent cry from those building the solution on a traditional project is that 'the users have changed their minds and requirements'. Far from being a problem, DSDM® embraces change and believes that change often arises as the result of a deepening understanding or an unavoidable external event.

3.2.4.1.1. In line with principle 1 - Focus on the business need.

3.2.4.2. How DSDM® helps?

3.2.4.2.1. DSDM® capitalises on the greater depth of understanding and so ensures that the Deployed Solution meets the true business need.

3.2.4.2.2. DSDM® enables change through iterative development, with regular reviews to make sure what is being developed is what the business really needs.

3.2.5. Unused Features

3.2.5.1. Researches has highlighted that a relatively low percentage of features delivered as part of the overall solution developed using traditional approaches are actually used.

3.2.5.1.1. This often happens because the business is encouraged to define all of its possible needs and wants at the outset of a project.

3.2.5.2. How DSDM® helps?

3.2.5.2.1. By helping the business to prioritise their needs as understanding of the detail grows, DSDM® keeps focus on what is important. This also avoids causing delays to a project by developing features that are never used.

3.2.6. Over-engineering ("Gold plating")

3.2.6.1. There is normally a diminishing return (on value) when trying to make a deliverable 'perfect'.

3.2.6.1.1. Usually the highest business benefits can be derived by getting something that is 'good enough' into a window of opportunity for the business.

3.2.6.2. How DSDM® helps?

3.2.6.2.1. DSDM® is a pragmatic approach that focuses on the business need in order to prevent a team being tempted into adding 'bells and whistles' which the business could live without and as a result missing the deadline.

3.2.7. Delayed or late Return on Investment (ROI)

3.2.7.1. Usually, the business value of a feature decreases over time and therefore delivering everything towards the end of a project will reduce the ROI.

3.2.7.2. How DSDM® helps?

3.2.7.2.1. DSDM® uses incremental delivery to get the most important and most valuable features to the business as soon as it can.

3.2.8. "Fragile" Agile

3.2.8.1. Many organisations have adopted Agile behaviours and approaches but have done so in a very casual and disorganized manner.

3.2.8.1.1. In an attempt to reduce the burden of bureaucracy, they have gone to the other extreme and created a very ad hoc situation which is typified by poor discipline, little documentation and a general feeling of chaos.

3.2.8.2. How DSDM® helps?

3.2.8.2.1. DSDM® helps here by placing the right Agile concepts and constructs in a structured and controlled framework that enables a project to respond to change and stay in control, whist still being fully Agile.

3.2.9. Waterfall dressed up as Agile

3.2.9.1. A common mistake made when transitioning to Agile is to use the iterative and incremental way of working but constraining it by applying an overall Waterfall licecycle.

3.2.9.2. How DSDM® helps?

3.2.9.2.1. DSDM does just enough work up front to ensure clarity of objectives and to provide a foundation for solution development.

3.2.9.2.2. Active engagement of business roles in the detail of development ensures the right solution evolves.

3.3. Why using DSDM®?

3.3.1. DSDM® has a broader focus than most other Agile approaches in that deals with projects rather than just the development and delivery of a product

3.3.2. DSDM® has a long track record of successful Agile project delivery in all types of corporate environments, and has proved to be fully scalable, working effectively in small business, large, complex organisations and in highly regulated environments

3.3.3. DSDM® may also be used to supplement an existing in-house Agile approach, where this has proved to be lacking.

3.3.3.1. DSDM® is often used to provide the full "project" focus to complement Scrum's team focused product development process.

3.3.4. DSDM® takes pragmatic approach, recognising that is often needs to work alongside existing standards and approaches.

3.3.4.1. e.g. PRINCE2®, ITIL®, ISO, CMMI, PMO

3.3.5. Vendor-independent.

3.3.6. Independent of tools and techniques,

3.3.7. Higly scalable - for small and big projects.

3.3.8. Recognises that more projects fail because of people issues than technology,

3.3.9. Fundamental assumption of the DSDM® approach is that nothing is built perfectly first time

3.3.9.1. DSDM® team will constantly search for for better style of working.

3.3.10. DSDM® is a convergent approach, ensuring that basic foundations for the project are agreed at an early stage

3.3.11. Current step need be completed only enough to move to the next step, since it can be finished in a later iteration.

3.3.12. Less agile approaches is the expectation that potential solution users can predict what all their requirements will be at some distant point in time.

3.3.12.1. Based on traditional project statistics lots of functionalities are rearly used by end users, but project costs are based on ALL delivered functonalities.

3.3.13. Solutions built using the DSDM® approach address the current and imminent needs of the business.

3.3.14. DSDM® is not only about developing new solutions.

3.3.14.1. Enhancements to existing solutions can be created using DSDM®.

3.3.15. Management

3.3.15.1. Management chooses DSDM® because it promises (and delivers) projects on time and on budget.

3.3.15.1.1. If not enough of DSDM® is used (risks are too high) or the project is not set-up correctly, the timeboxing techniques give early warning of failures to come. Any seasoned manager will appreciate knowing about a problem 3 months before delivery, rather than two days after.

3.3.15.2. Track record of On Time and In Budget delivery

3.3.15.3. “Corporate strength” agile

3.3.15.4. Highlights failing projects early

3.3.15.5. Provides a common language

3.3.16. Project Manager

3.3.16.1. The objectives-minded PM chooses DSDM® because it helps him/her set, break down and distribute objectives within the project and its teams.

3.3.16.1.1. He/she also likes the reviews within the timeboxes because this allows the projects to spot mistakes while they are being made, rather than afterwards when it is too late.

3.3.16.2. Objectives-based

3.3.16.3. Clearly defined process with regular review points

3.3.16.4. Provides a common language

3.3.16.5. Effective planning

3.3.16.6. Appropriate formality

3.3.17. Business & Users

3.3.17.1. The users choose DSDM® because is allows them to control development while it is happening.

3.3.17.1.1. They realise that most projects do new things and nothing can be produced correctly the first time and therefore constant feedback and involvement is required to ensure they get what they need.

3.3.17.2. Ownership of solution

3.3.17.3. Ability to drive direction of project for optimum business benefit

3.3.17.4. Delivery of a working solution on time, every time

3.3.17.5. Provides a common language

3.3.18. Developers

3.3.18.1. The Solution Developer chooses DSDM® because it treats him/her like an accomplished adult and lets him/her take full responsibility for a complete signed-off deliverable.

3.3.18.1.1. This means wider responsibility, growth opportunities and a more rewarding job.

3.3.18.2. Responsibility

3.3.18.3. Growth opportunities

3.3.18.4. User involvement

3.3.18.5. Provides a common language

3.4. DSDM® vs Traditional Project Variables

3.4.1. Project Variables - Traditional and DSDM®.

3.4.1.1. Deliver on time.

3.4.1.2. Deliver on budget.

3.4.1.3. Guarantee to meet quality standards.

3.4.1.4. Focus on what business sees as important (not everything is important).

3.4.1.4.1. Agile projects will not necessarily deliver the full scope!

3.4.1.4.2. DSDM® is about delivering 80% functionality in 20% time.

3.4.2. DSDM® fixes Time, Cost and Quality at the early phases of a project.

3.4.2.1. Time is fixed e.g. due to short timescale of Timeboxes

3.4.3. According to DSDM®, most projects have four parameters - time, cost, features and quality.

3.4.4. In the traditional approach to project management (left hand diagram), the feature content of the solution is fixed whilst time and cost are subject to variation.

3.4.5. DSDM® approach to managing the project (right hand diagram), fixes time, cost and quality at the Foundations phase while contingency is managed by varying the features (the requirements) to be delivered.

3.4.6. As long as MoSCoW and Timeboxing rules are followed, a minimum subset of features (the Minimum Usable Subset) is absolutely guaranteed to be delivered on time and in budget.

3.4.7. Quality is fixed in an DSDM® project because acceptance criteria are agreed and set before development commences

3.4.7.1. Each Timebox in DSDM® has the same level of quality set at the beginning.

3.4.7.1.1. Which means that each deployment will have the save level of quality and whole solution will be build in one level of stable quality.

3.4.7.2. Quality is built in since quality control takes place throughout the project instead of being stuck on the end. Achieved by checking a bit at a time, & checking integration of components as they’re produced.

3.4.8. Contingency, in the form of lower priority features, ensures that on-time delivery of a viable solution can be achieved by protecting the Minimum Usable Subset and dropping or deferring lower priority features, if necessary, in accordance with MoSCoW rules.

3.4.9. Deliver at the right time

3.4.9.1. DSDM ensures solutions are delivered at the right time by breaking the project down into focused, fixed duration Project increments and within these into one or more timeboxes also of fixed duration and lasting typically, two to four weeks.

3.4.10. Delivering the right solution

3.4.10.1. The people team and other significant stakeholders remain focused on the business needs

3.4.10.2. All people involved with the project work collaboratively to achieve that outcome

3.4.10.3. DSDM harnesses the knowledge, experience and creativity of teams to understand the business problem or opportunity, and then to work together to build the optimum solution

3.4.10.4. A limited amount of early work ensures firm foundations to support the solution as it grows

3.4.10.5. Work is prioritised according to business need and the ability of the business to accommodate changes in the agreed timescale

3.4.10.6. An iterative and incremental approach to development and delivery of the solution assures alignment with business need

3.4.10.7. Quality is never allowed to become a variable

3.5. DSDM® rigour

3.5.1. Too much formality can slow progress down and even cause paralysis.

3.5.2. Too little formality can lead to a seat-of-the-pants approach.

3.5.3. DSDM® should be tailored to suit a project's individual needs within the organisation's governance needs.

3.5.4. The aim is to have adequate formality, so that waste is eliminated and all activities at each incremental level add value.

3.5.5. DSDM® project ensures that formality and rigour are there to help rather than hinder progress.

3.6. Download: Traditional vs DSDM® project variables (PDF)

4. Agile fundamentals (agile in general not DSDM® fundamentals)

4.1. Agile Manifesto

4.1.1. http://agilemanifesto.org/

4.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto

4.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development

4.1.3. disciplines that gave rise to the Agile Manifesto

4.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.

4.2. Agile Alliance

4.2.1. http://www.agilealliance.org/

4.3. Agile currently is buzzword, a marketing term

4.3.1. Agile is like any other newly introduced popular concept. “… Everybody is talking about it. Very few are doing it and those who are, are doing it badly” (James O. Coplien)

4.3.2. Agile as a word by it's own simply means - nothing more than merketing term.

4.3.2.1. there are so many Agile methodologies, Agile standards, Agile techniques, Agile tools, Agile good / best agile practices, Agile frameworks etc., that 'Agile' word itself is to general

4.3.2.1.1. see Agile World mind map

4.3.3. Agile is a generic description of a “Style of Working”.

4.3.3.1. Not only style of working on project but rather culture in ENTIRE organization

4.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron

4.4. The Agile Mindset, Values and Principles

4.4.1. 4 Agile Value

4.4.1.1. 1. Individuals and interactions over processes and tools

4.4.1.2. 2. Working software over comprehensive documentation

4.4.1.3. 3. Customer collaboration over contract negotiation

4.4.1.4. 4. Responding to change over following a plan

4.4.2. 12 Agile Principles

4.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

4.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

4.4.2.3. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4.4.2.4. 4. Business people and developers must work together daily throughout the project.

4.4.2.5. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

4.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

4.4.2.7. 7. Working software is the primary measure of progress.

4.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

4.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.

4.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.

4.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.

4.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

4.4.3. The unlimited number of Agile Practices

4.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...

4.4.3.1.1. see Agile World mind map

4.4.3.2. Being Agile vs Doing Agile

4.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks

4.5.1. In Agile community umbrella symbolizes family of different standards but yet all from them are Agile based - which means are compatible with Agile Manifesto

4.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices

4.5.2.1. No Project Manager role

4.5.2.2. No project definition and etablished project / programme governance

4.5.2.3. ...

4.5.3. see Agile World mind map

4.6. Plan-Driven Projects vs. Change-driven Project Projects

4.6.1. Traditional (waterfall or sequential) Project Management metaphor

4.6.1.1. Railway metaphor

4.6.1.1.1. Moving forward, based on delivering predicted upfront requirements in accepted tolerances with limited tolerance to change

4.6.1.1.2. Changing course of train based on requirements

4.6.1.2. a.k.a. Plan-driven

4.6.1.2.1. build around paradigm of process

4.6.1.3. defined process control model

4.6.1.3.1. All work is understood before execution

4.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time

4.6.1.3.3. Follow the pre-determined steps to get known results

4.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor

4.6.2.1. Sailing metaphor

4.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.

4.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements

4.6.2.2. a.k.a. Change-driven

4.6.2.2.1. build around paradigm of change / adaptation

4.6.2.3. empirical (adaptive) process control model

4.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds

4.6.2.3.2. Processes are accepted as imperfectly defined

4.6.2.3.3. Outputs are often unpredictable and unrepeatable

4.7. Agile is best for complex projects

4.7.1. Simple (straightforward)

4.7.1.1. Everything is known and predicatable

4.7.2. Complicated

4.7.2.1. More is known than unknown

4.7.3. Complex

4.7.3.1. More is unknown than known

4.7.4. Chaotic (unpredictable)

4.7.4.1. Very little is known

4.7.5. See also Cynefin framework (by Dan Snowden)

4.7.5.1. different view on Cynefin Framework

4.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8

4.8. Agile is about delivering Value

4.8.1. VALUE is NOT the same as BENEFIT

4.8.1.1. Benefits

4.8.1.1.1. Benefit is about outputs

4.8.1.1.2. Benefit is a objective

4.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)

4.8.1.1.4. Benefit can be financial & non financial

4.8.1.1.5. Benefit can be ...

4.8.1.1.6. Benefit MUST be measurable and observable

4.8.1.1.7. Benefits are identifiable and quantifiable

4.8.1.1.8. Benefits SHOULD have baselines

4.8.1.1.9. Benefits SHOULD have priorities

4.8.1.1.10. Benefits types:

4.8.1.1.11. Benefit metaphore

4.8.1.1.12. in general benefit = delivered requirements

4.8.1.2. Value

4.8.1.2.1. Value is about outcomes

4.8.1.2.2. Value is subjective

4.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in agile)

4.8.1.2.4. Value can be ...

4.8.1.2.5. Values SHOULD have priorities

4.8.1.2.6. Value metaphore

4.8.1.2.7. in general value = designed fit for purpose, as small as possible solution

4.9. Agile is about focusing on business value / outcome, not strictly project plan / output

4.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan

4.9.1.1. That's why most Agile approaches define Project Vision

4.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing

4.11. Agile respects the common sense that all requirements can not be known at the outset, particularly when the outcomes are intangible and subject to an evolving understanding.

4.11.1. “People don't know what they want until you show it to them“ (Steve Jobs)

4.12. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)

4.12.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)

4.13. Agile is about change, constant change which leads to better value

4.13.1. “If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and adapt) is the method of choice“ (Ken Schwaber)

4.13.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook

4.13.3. "Change is the only constant." Heraclitus, Greek philosopher

4.14. Agile thinking / approach often requires mind change

4.14.1. Not every organization is ready for that change!

4.15. Agile thinking / approach often requires cultural shift

4.15.1. Not every organization is ready for that change!

4.15.2. "It is quite difficult for a highly structured and seniority-based organization to mobilize itself for change, especially under noncrisis conditions. this effort collapses somewhere in the hierarchy" K. Imai, I. Nonaka, H. Takeuchi

4.15.3. "Scrum exposes every cultural dysfunction that impedes developing software [...] It is not an approach or process that can be modified to fit the existing organizational culture; the culture must change to enable Scrum." K. Schwaber, J. Sutherland

4.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)

4.16. Why Agile Works

4.16.1. 1. The customer's representative is in the driver's seat

4.16.2. 2. Quick reaction to the changing market and needs

4.16.3. 3. More visibility

4.16.4. 4. Ideal environment for development

4.16.5. 5. Self-manged teams

4.16.6. 6. Removes confusion and distraction

4.16.7. 7. No fortune tellers; Plan as you go

4.16.8. 8. Issues are less disruptive

4.16.9. 9. Continuous improvement

5. DSDM® Philosophy

5.1. The DSDM® philosophy

5.1.1. "best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people."

5.2. 6P Model

5.2.1. Philosophy

5.2.2. Principles

5.2.2.1. Eight principles articulate the core elements of the philosophy

5.2.3. Process

5.2.3.1. A full project lifecycle model that describes the transitions through phases that enable iterative, incremental and adaptive practices

5.2.4. People

5.2.4.1. Facilitation of communication, support of collaboration and the composition and distribution of skills within project teams

5.2.5. Products

5.2.5.1. A set of evolutionary and milestone artefacts cater for different project perspectives

5.2.6. Practices

5.2.6.1. Structured techniques and activities

5.3. Philosophy is achieved when all stakeholders

5.3.1. Understands and buy into the business vision and objectives

5.3.2. Are empowered to make decisions within their area of expertise

5.3.3. Collaborate to deliver a fit for purpose business solution

5.3.4. Collaborate to deliver to agreed timescales in accorddance with business priorities

5.3.5. Accept that change is inevitable as the understanding of the solution grows over time

5.4. The DSDM® philosophy is supported by a set of 8 principles that build the mindset and behaviours necessary to bring the philosophy alive.

5.5. The 8 principles are themself supported by people, Agile process, clearly defined products and recommended practices

5.6. Common sense

5.6.1. "sound practical judgment independent of specialised knowledge or training; normal native intelligence"

5.7. Pragmatism

5.7.1. "action or policy dictated by consideration of the immediate practical consequences rather than by theory or dogma"

6. DSDM® Principles (8)

6.1. Principles are universally applicable statements.

6.1.1. Principles are universal, self-validating and empowering.

6.1.2. They provide guidance to organizations.

6.2. The 8 principles of DSDM® direct the team (not mandates) in the attitude and culture they must take and the mindset they must adopt in order to deliver consistently.

6.2.1. A way of thinking and working.

6.3. If a team doesn't follow all the principles then they don't get the full benefit.

6.3.1. It increases risk.

6.4. Treat non-adherence to the principles as a risk.

6.4.1. Compromising any of the Principles undermines the philosophy of DSDM® and introduces risk to the successful outcome of the project.

6.5. The 10 Golden Rules for Successful Agile Projects (by Keith Richards)

6.5.1. https://www.youtube.com/watch?v=P84PqqJV7Es

6.5.2. No. 1: Define the project objective in less than 10 words

6.5.2.1. You must start with the end in mind

6.5.2.2. You need to know exactly where you are going

6.5.2.3. The business case is your best friend

6.5.2.4. This will take you a long time to do

6.5.2.5. It will help you to kill a project going nowhere

6.5.2.6. The scope of the project will map on to this.

6.5.2.7. TIP

6.5.2.7.1. Can you write the project objective on a Post-it note with a flip chart marker?

6.5.3. No. 2: Build a team with those who say ‘can’

6.5.3.1. A lot of being agile is about options

6.5.3.2. If you get the right people you are half way there

6.5.3.3. Choose the right person above the right skill set

6.5.3.4. “If you think you can’t, you’re right” – Carol Bartz

6.5.3.5. You need collaboration and team spirit.

6.5.3.6. TIP

6.5.3.6.1. Ask a team member this question: ‘can I ask a favour?’

6.5.4. No. 3: Go slow early to go fast later

6.5.4.1. This is counter intuitive

6.5.4.2. How much ‘DUF’ is enough? Answer EDUF!

6.5.4.3. Build from firm foundations

6.5.4.4. You must avoid analysis paralysis

6.5.4.5. Try and spot early solutioneering.

6.5.4.6. TIP

6.5.4.6.1. Ask yourself ‘is it safe to move on?’

6.5.5. No. 4: Look backwards to go forwards

6.5.5.1. Learn your lessons – both good and bad

6.5.5.2. Evolve the process – it has to evolve

6.5.5.3. If it doesn’t work – do something else!

6.5.5.4. Try this! - Review, Plan, Do

6.5.5.5. Share your experiences with other teams.

6.5.5.6. TIP

6.5.5.6.1. Ask yourself how many of your projects have ended with a project review.

6.5.6. No. 5: Change is great!

6.5.6.1. You need to anticipate change and embrace it

6.5.6.2. This allows a more accurate solution to result

6.5.6.3. Do not confuse the breadth of the scope with the depth

6.5.6.4. Evolve and converge on the solution with the right kind of change.

6.5.6.5. TIP

6.5.6.5.1. How do you feel when a customer says “I’ve changed my mind”?

6.5.7. No. 6: To be understood, seek first to understand.

6.5.7.1. Command and control may not work with Agile

6.5.7.2. Facilitation is a core competency

6.5.7.3. Big ears, big eyes, small mouth

6.5.7.4. You have to play with the cards you are dealt

6.5.7.5. This will give you ownership.

6.5.7.6. TIP

6.5.7.6.1. Try the 10 second silence when getting a progress update – nothing else can compete with it!

6.5.8. No. 7: Collect Actuals – this is the oxygen for your project

6.5.8.1. ‘You cannot control what you cannot measure’ – Tom de Marco

6.5.8.2. Meten is weten – to measure is to know

6.5.8.3. Start now – build a metrics database

6.5.8.4. Keep it simple to start with

6.5.8.5. Calibrate your estimates.

6.5.8.6. TIP

6.5.8.6.1. Do you know (to the nearest day) how much time was spent on testing during your last project?

6.5.9. No. 8: Use fat communication channels

6.5.9.1. Shift the communication traffic to bigger pipes

6.5.9.2. The written word is a silent killer

6.5.9.3. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)

6.5.9.4. Go visual

6.5.9.5. Use workshops.

6.5.9.6. TIP

6.5.9.6.1. Try turning a document over and take a look at what is on the back

6.5.10. No. 9: Work hard at controlling what you can’t control

6.5.10.1. Continuously manage external risks

6.5.10.2. You may get your team right but what about 3rd parties?

6.5.10.3. Are they playing by the same rules as you?

6.5.10.4. Get the team involved

6.5.10.5. Be ‘a bit of a worrier’.

6.5.10.6. TIP

6.5.10.6.1. Actively manage your risk log – it is not a storage area

6.5.11. No. 10: One more day? NO! We’ll catch up? NO!

6.5.11.1. Time focus is your greatest weapon

6.5.11.2. Force the issue – understand your condition

6.5.11.3. Timeboxes not milestones

6.5.11.4. If you are going to fail – fail early

6.5.11.5. Prioritise with MoSCoW – it should be natural.

6.5.11.6. TIP

6.5.11.6.1. Set a deadline and hit it – never extend it, not even once!

6.6. 1 - Focus on the business need

6.6.1. Every decision taken during a project should be viewed in the light of the overriding project goal - to deliver what the business needs to be delivered, when it needs to be deliveres.

6.6.1.1. Project is a means to an end, not an end in itself.

6.6.1.1.1. Solution products are more important than documentation

6.6.2. Understand true business priorities

6.6.3. Establish valid business case

6.6.3.1. There is a formal document called Business Case

6.6.4. Ensure continuous business sponsorship and commitment

6.6.4.1. Business Sponsor (role) is responsible for finance decisions

6.6.4.2. Business Ambassador roles are representatives from client / user side available everyday (~min 15. minutes a day) to Solution Development Teams (SDTs)

6.6.4.2.1. Each Sollution Development Team (SDT) has it's own dedicated Business Ambassador

6.6.5. Guarantee delivery of the Minimum Usable Subset of requirements

6.6.5.1. Not all requirements must be delivered in DSDM® project, but as a minimum those having MUST priority

6.6.5.1.1. see MoSCoW prioritization

6.6.6. Deliver what the business needs when it needs it.

6.6.6.1. The true business priorities must be understood with a sound business case.

6.6.6.2. Discover and understand real client / user NEEDS not just requirements

6.6.6.2.1. Go back and ask WHY project is needed and WHY products are needed, what is the purpose

6.6.6.3. Focus on real/true business needs by questioning/challenging initial requirements; go into details; find valid business case for each requirement; confirm each requirement by looking at the value; maintain end user focus

6.6.6.3.1. “There is nothing so useless as doing efficiently that which should not be done at all” (Peter F. Drucker)

6.6.7. Principle supported by:

6.6.7.1. Roles

6.6.7.1.1. Business Sponsor (BS)

6.6.7.1.2. Business Visionary (BV)

6.6.7.2. Products

6.6.7.2.1. Business products (documents) created in the Foundation phase

6.6.7.3. Techniques

6.6.7.3.1. MoSCoW

6.6.7.3.2. Timeboxing

6.7. 2 - Deliver on time

6.7.1. Delivering a solution on time is a very desirable outcome for a project and is quite often the single most important success factor.

6.7.1.1. Late delivery can often undermine the very rationale for a project, especially where market opportunities or legal deadlines are involved.

6.7.2. Timebox the work into manageable chunks of time.

6.7.2.1. Timeboxes are planned in advance and the timeframe set.

6.7.2.1.1. The dates never change and features are varied depending on business priorities, in order to achieve the deadline.

6.7.2.1.2. DO NOT EVER EXTEND TIMEBOX!

6.7.3. Focus on business priorities and needs (not just requirements)

6.7.3.1. Question each decision

6.7.4. Always hit deadlines

6.7.4.1. Time is only asset that you can't (directly) control in life!

6.7.4.1.1. You can increade / decrease quality

6.7.4.1.2. You can increase / decrease risk

6.7.4.1.3. You can increase / decrease benefits

6.7.4.1.4. You can add / remove resources

6.7.4.1.5. All of above can give you (indirectly) some time ... but you cannot directly control time.

6.7.4.2. Build confidence through predictable delivery and maintain reputation

6.7.4.2.1. QDOS - Quality Delivery of Service

6.7.4.3. You can only loose time but never gain ...

6.7.4.3.1. You may think that you gain time by changing other project variables

6.7.4.4. "If you accept the premise that market needs change faster than the software industry‟s traditional ability to develop solutions, you‟re left with the question “what can we do about it?” For me, the answer is Agile." Israel Gat, Vice President, Infrastructure Management, BMC Software, Inc.

6.7.4.5. "My favorite things in life don't cost any money. It's really clear that the most precious resource we all have is time." Steve Jobs

6.7.5. Define the breadth (project scope) of your requirements without going into too much detail.

6.7.6. Estimate the relative size, priority and complexity of each requirement.

6.7.6.1. UTH rule (rule not law)

6.7.6.1.1. Units, Tens and Hundreds

6.7.6.1.2. U - Very early on during the initial work you would probably be able to count the (high-level) requirements on the fingers of your hands

6.7.6.1.3. T - Shortly after this and after more investigation has moved the project further forward, the number of (medium level) requirements would have increased but it would still be less than a hundred

6.7.6.1.4. H - Finally, as the project fully defines the products in detail (low-level requirements), you may have hundreds of requirements although not thousands.

6.7.7. Principle supported by:

6.7.7.1. Roles

6.7.7.1.1. Project Manager (PM)

6.7.7.1.2. Team Leader (TL)

6.7.7.2. Techniques

6.7.7.2.1. MoSCoW

6.7.7.2.2. Timeboxing

6.8. 3 - Collaborate

6.8.1. Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association.

6.8.1.1. Collaboration cncourages increased understanding, greater speed & shared ownership

6.8.2. Involve the right stakeholders, at the right time, throughout the project

6.8.3. Encourage pro-active involvement from the business representatives

6.8.4. Ensure that all members of the team are empowered to take decisions on behalf of those they represent

6.8.4.1. Even at the lowest level (of course with boundaries)

6.8.4.1.1. Power to the people!

6.8.5. Build a one team culture (also between supplier and customer)

6.8.5.1. Deployment is more likely to go smoothly, because of the cooperation of all parties concerned throughout development

6.8.5.2. Teams work in a spirit of active cooperation and commitment. Collaboration encourages understanding, speed and shared ownership. The teams must be empowered and include the business representatives

6.8.6. Actively involve business

6.8.6.1. Business involvment in every day

6.8.6.2. Done by Business Ambassador (BAMB) role

6.8.7. DSDM's Business Visionary (BV), Business Ambassador (BAMB) and Business Advisor (BADV) roles bring appropriate subject matter experts (SMEs) into project to contribute to solution

6.8.8. The Solution Development Team (SDT) brings together business and technical roles in a single team.

6.8.9. Facilitated workshops technique enable stakeholders to share knowledge with the project team

6.8.9.1. "A well-constructed project management workshop should give people a solid foundation to build on." Bentley & Borman, 2001

6.8.10. The risk of building the wrong solution is greatly reduced

6.8.10.1. a.k.a. "fatware"

6.8.10.2. a.k.a. "shelfware"

6.8.10.3. a.k.a. "zombieware"

6.8.10.4. ...

6.8.11. The final solution is more likely to meet the users' real business requirements

6.8.12. People want to be part of something

6.8.13. Recommended co-location

6.8.14. Solution Development Teams are:

6.8.14.1. Empowered

6.8.14.1.1. "Get the right people. Then, no matter what else you may do wrong after that, the people will save you. That's what management is all about." Tom DeMarco, 1997

6.8.14.1.2. "Worker are knowledge workers if they know more about the work they perform than their bosses." Peter Drucker

6.8.14.2. Self-directed / Self-disciplined

6.8.14.2.1. Teams commit only to the work they can accomplish and then perform that work as effectively as possible.

6.8.14.2.2. Fully and exclusively responsible for working out how the Timebox products will be developed.

6.8.14.3. Self-organizing

6.8.14.3.1. Teams estimate and plan their own work and then proceed to collaborate iteratively to do so.

6.8.14.3.2. Style of working

6.8.14.3.3. Who is needed on the team and not

6.8.14.3.4. When it needs help resolving Impediments

6.8.14.3.5. Needed process improvements

6.8.14.3.6. Technology practices

6.8.14.3.7. Techniques

6.8.14.3.8. Who does what and when

6.8.14.3.9. Self-organizing rarely means self-managing

6.8.14.3.10. "[...] study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records [...]" K. Imai, I.Nonaka, H. Takeuchi

6.8.14.3.11. "Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity." General George S. Patton

6.8.14.4. Self-aware

6.8.14.4.1. Teams strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.

6.8.14.5. Self-sufficient

6.8.14.5.1. Having all the skills needed within the team to deliver and test products.

6.8.14.6. No hierarchy within the team

6.8.14.6.1. No bosses or managers.

6.8.14.7. Cross-functional

6.8.14.7.1. Without demarcation by role e.g. analyst, developer, tester, everybody is expected to perform any type of work needed to get the job done.

6.8.14.8. Small (7 +/- 2)

6.8.14.8.1. AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead..

6.8.14.8.2. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"

6.8.14.9. Autonomical

6.8.14.9.1. Yet SDTs do not work in a vacuum.

6.8.14.10. Accountable

6.8.14.10.1. SDTs are accountable for fulfilling the goal(s) they have taken on.

6.8.14.11. Collaborative

6.8.14.11.1. Download: 17 Indisputable Laws of Teamwork by John Maxwell

6.8.14.11.2. Improved collaboration between peole correspondingly increases the opportunities for people to learn from one another.

6.8.14.12. Based on trust and respect

6.8.14.13. Ideally static

6.8.14.13.1. Most successful with long-term, full-time membership.

6.8.14.13.2. Subject to re-structuring if team is not working.

6.8.14.14. Ideally collocated

6.8.14.14.1. Most successful when located in one team room (particularly for the first few Timeboxes).

6.8.14.14.2. Collocated mentally not only phisically.

6.8.14.14.3. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001

6.8.15. Principle supported by:

6.8.15.1. Roles

6.8.15.1.1. Business Sponsor (BS)

6.8.15.1.2. Business Visionary (BV)

6.8.15.1.3. Business Ambassador (BAMB)

6.8.15.1.4. Solution Development Teams (SDTs)

6.8.15.1.5. Workshop Facilitator (WF)

6.8.15.2. Techniques

6.8.15.2.1. Facilitated Workshops

6.8.15.2.2. Daily Stand-ups (a.k.a. Scrum meetings)

6.9. 4 - Never compromise quality

6.9.1. In DSDM the level of quality to be delivered should be agreed at the start. All work should be aimed at achieving that level of quality - no more and no less.

6.9.2. Agree the level of quality from the outset, before development starts

6.9.2.1. Level of quality is agreed at the start at Foundations phase.

6.9.2.2. Quality level is set upfront and never changes through entire project and all Timeboxes

6.9.2.2.1. All increments have the same level of quality

6.9.3. Ensure that quality does not become a variable

6.9.3.1. A solution has to be “good enough”.

6.9.3.1.1. right-engineering (no under-engineering or over-engineering)

6.9.3.1.2. no "gold plating"

6.9.4. Projects must test early and continuously and review constantly.

6.9.4.1. Everything is tested as early as possible.

6.9.4.2. Test early, test continuously and test to the appropriate level

6.9.4.2.1. MoSCoW and timeboxing ensure testing is appropriate, without introducing unnecessary risks

6.9.4.2.2. "Bad programmers have all the answers. Good testers have all the questions.", Gil Zilberfeld

6.9.4.3. Build in quality by constant review

6.9.4.4. MoSCoW and timeboxing techniques ensure testing is appropriate, without introducing unnecessary risks

6.9.5. Ensure testing is properly integrated into the Iterative Development process, with regular reviews throughout the project lifecycle, helps the DSDM® team to build a quality solution.

6.9.5.1. The review and quality control products created as the project proceeds help demonstrate that the quality of the solution is meeting the expected standard.

6.9.6. Fail fast.

6.9.6.1. "fail fast, learn fast"

6.9.6.2. Do tests every day, not only before formal sign-off

6.9.6.2.1. Solution Tester (ST) role is responsible for everyday tests

6.9.6.3. User Acceptance Testing (UAT) testes are not enough

6.9.6.3.1. e.g. in IT - use black box testing / Unit testing every day even on unfinished product

6.9.6.4. "I have not failed. I’ve just found 10,000 ways that won’t work", Thomas Edison

6.9.6.5. "Failure is simply the opportunity to begin again, this time more intelligently", Henry Ford

6.9.6.6. "Testing is more than testing (and should start before testing)" (Dorothy Graham)

6.9.7. If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable

6.9.8. Principle supported by:

6.9.8.1. Roles

6.9.8.1.1. Solution Tester (ST)

6.9.8.2. Products

6.9.8.2.1. Testing products

6.9.8.3. Techniques

6.9.8.3.1. MoSCoW

6.9.8.3.2. Timeboxing

6.9.8.3.3. Daily Stand-ups

6.9.8.4. Early and integrated testing

6.9.8.5. Regular reviews throughout lifecycle

6.10. 5 - Build incrementally from firm foundation

6.10.1. One of the key differentiators for DSDM® within the Agile space is the concept of establishing firm foundations for the project before committing to significant development.

6.10.1.1. DSDM® 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 overly detailed analysis of requirements.

6.10.1.2. DSDM® advocates incremental delivery of the solution in order to deliver real business benefit as early as is practical.

6.10.1.2.1. 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.

6.10.2. Carry-out appropriate analysis and enough design up front (EDUF) to create strong foundations

6.10.3. Formally re-assess priorities and informally re-assess ongoing project viability with each delivered increment.

6.10.4. Incremental delivery (of value to production / live environment)

6.10.4.1. Increments allow the business to take advantage of work before the final product is complete, encouraging stakeholder confidence and feedback.

6.10.4.1.1. This is based on doing just enough upfront analysis to proceed and accepting that detail emerges later.

6.10.4.2. Deliver functionality in stages by focusing on ‘quick-wins’ to gain early confidence and early business support.

6.10.4.2.1. Momentum is built.

6.10.4.2.2. Solution should be delivered in increments that provide the greatest value to the customer.

6.10.5. Increments deployed into operational use for early ROI

6.10.6. Strive for early delivery of business benefit where possible.

6.10.7. Continually confirm the correct solution is being built.

6.10.8. Implement this principle using DSDM® lifecycle

6.10.9. "The increment must be completed, meaning the increment must be a complete piece of usable software." K. Schwager, J. Suterland

6.10.10. Principle supported by:

6.10.10.1. Techniques

6.10.10.1.1. Iterative Development

6.10.10.2. DSDM® Lifecycle

6.11. 6 - Develop iteratively

6.11.1. DSDM® uses a combination of Iterative Development, frequent demonstrations and comprehensive review to encourage timely feedback.

6.11.1.1. Embracing change as a part of this evolutionary process allows the team to converge on an accurate business solution.

6.11.1.2. The concept of iteration is at the heart of everything developed as part of the DSDM® approach.

6.11.2. Do enough design up front (EDUF) to create strong foundations.

6.11.3. Accept that work is not always right first time.

6.11.3.1. It is rare that anything is created perfectly first time and it is important to recognise that project operate within a changing world.

6.11.3.2. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.

6.11.3.2.1. Iterative approach on all projects

6.11.3.2.2. Previous steps can be revisited as part of its iterative approach.

6.11.3.2.3. This means that DSDM® project lifecycle is iterative

6.11.4. Build business / customer / user feedback into each iteration

6.11.4.1. This means that DSDM® project lifecycle is adaptive to new business requirements gathered after feedback

6.11.5. Accept that work is not always right first time.

6.11.5.1. It is rare that anything is created perfectly first time and it is important to recognise that project operate within a changing world.

6.11.5.2. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.

6.11.6. Accept most detail emerges later rather than sooner.

6.11.6.1. Often end users / clients doesn't know what then need and think they know what they want!

6.11.7. Embrace change, the right solution will not emerge without it.

6.11.7.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)

6.11.8. Be creative, experiment, innovate, test, learn, evolve.

6.11.9. Previous steps can be revisited as part of its iterative approach.

6.11.10. Principle supported by:

6.11.10.1. Techniques

6.11.10.1.1. Iterative Development

6.11.10.1.2. Timeboxing

6.11.10.1.3. Prototyping

6.11.10.1.4. Modelling

6.11.10.2. Iteration and constant review

6.12. 7 - Communicate continuously and clearly

6.12.1. Poor communication is often cited as the biggest single cause of project failure.

6.12.1.1. DSDM practices are specifically designed to improve communication effectiveness for both teams and individuals.

6.12.2. Encourage informal, face-to-face communication at all levels

6.12.3. Run daily stand-ups sessions

6.12.3.1. Same like Daily Scrum Meetings in Scrum framework. Agile daily team stand-up session are exactly the same.

6.12.4. Use workshops, with a facilitator where appropriate

6.12.5. Use rich, visual communication (best interactive) communication techniques such as Modelling and Prototyping

6.12.6. Demonstrate the Evolving Solution early and often

6.12.7. Keep documentation lean and timely.

6.12.8. Manage the expectations of the stakeholder at all levels throughout the project.

6.12.9. Always aim for honesty and transparency in all communication

6.12.10. DSDM® emphasises the value of human interaction through Stand-ups, Workshops, clearly defined role and active business involvement.

6.12.11. Modelling and Prototyping make early instances of the solution available for scrutiny.

6.12.11.1. These practices are far more effective than the use of large textual documents, which are sometimes written for reasons other than achieving the business objectives of the project.

6.12.11.2. Present instances of the evolving solution (not perceptions hidden behind PowerPoint presentations) early and often.

6.12.12. Communication, Conversation, Collaboration, Community, Culture (5C).

6.12.13. Principle supported by:

6.12.13.1. Roles

6.12.13.1.1. Workshop Facilitator (WF)

6.12.13.2. Techniques

6.12.13.2.1. Facilitated workshops

6.12.13.2.2. Daily Stand-ups

6.12.13.3. Clearly defined roles

6.12.13.4. User and business involvement

6.12.13.5. Team empowerment

6.12.13.6. Models and prototypes

6.13. 8 - Demonstrate control

6.13.1. Demostrate control - for customer and users to show that everything is under control

6.13.1.1. “If everything seems under control, you're not going fast enough.“ (Mario Andretti, Italian American world champion racing driver)

6.13.2. In many environments it is not enough simply to be in control, it needs to be able to prove it

6.13.2.1. It is essential to be in control of a project at all times to be able to demonstrate that this is the case.

6.13.2.1.1. This can only be achieved by reference to a plan for the work being done, which is clearly aligned with agreed business objectives.

6.13.2.1.2. It is also vital to ensure transparency of all work being performed be the team.

6.13.3. Make plans and progress visible to all.

6.13.3.1. Even to lowest level team members.

6.13.4. Measure progress through focus on delivery of products rather than completed activities.

6.13.5. Manage proactively

6.13.6. Evaluate continuing project viability based on the business objectives.

6.13.7. Use an appropriate level of formality for tracking and reporting.

6.13.8. The team needs to be proactive when monitoring and controlling progress in line with Foundations Phase.

6.13.8.1. They need to constantly evaluate the project viability based on the business objectives.

6.13.9. The use of well-defined Timeboxes, with constant review points, and the preparation of the Management Foundations product (document) and Timebox Plans, are designed to assist the Project Manager and the rest of the project team to follow this principle.

6.13.10. Principle supported by:

6.13.10.1. Roles

6.13.10.1.1. Project Manager (PM)

6.13.10.1.2. Team Leader (TL)

6.13.10.2. Products

6.13.10.2.1. Management Foundations

6.13.10.2.2. Timebox Plans

6.13.10.3. Techniques

6.13.10.3.1. Timeboxing

6.13.10.4. Constant review with client and users

6.14. Summary & Conclusion

6.14.1. DSDM® is an Agile Project Delivery Framework that delivers the right solution at the right time

6.14.1.1. Iterative

6.14.1.2. Incremental

6.14.1.3. Adaptive

6.14.1.4. Empirical

6.14.1.5. Change-driven

6.14.2. The right business solution is delivers because

6.14.2.1. The Project Team and others significant stakeholders remain focused on the business outcome

6.14.2.2. Delivery is on time providing an early ROI and reduced risk

6.14.2.3. All people involved with the project work collaboratively to deliver the optimum solution

6.14.2.4. Work is prioritized according to business need and the ability of users to accommodate changes

6.14.2.5. DSDM® does not compromise quality

7. DSDM® Roles (13)

7.1. Introduction

7.1.1. Roles are not positions, nor are they meant to be.

7.1.1.1. Agile deemphasizes specialized roles and considers all team members equal - everyone pitches in to deliver a working solution regardless of their job description.

7.1.2. The Project-level roles are

7.1.2.1. Business Sponsor (BS), Business Visionary (BV), Technical Coordinator (TC), Project Manager (PM) and Business Analyst (BA)

7.1.2.2. Directors, managers and coordinators of the project work. They will either be on or directly report to any project board or steering committee.

7.1.3. The Business Visionary (BV) and the Technical Coordinator (TC) hold the customer and supplier visions of solution excellence.

7.1.4. The Project Manager (PM) ensures that the funding supplied is used effectively to create the envisaged solution.

7.1.5. The Development roles are

7.1.5.1. Team Leader (TL), Business Ambassador (BAMB), Business Analyst (BA), Solution Developer (SD) and Solution Tester (ST).

7.1.5.2. Jointly these roles form the engine room of the project.

7.1.6. The Development roles shape and build the solution, are collectively responsible for its day-to-day development and for assuring its fitness for business purpose.

7.1.7. The Supporting roles are

7.1.7.1. Business Advisors (BADV), Technical Advisors (TADV), Workshop Facilitator (WF) and DSDM Coach (DC) provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

7.1.7.2. The project may bring in subject matter experts as necessary for their specialist expertise.

7.1.7.2.1. Business Advisors (BADV)

7.1.7.2.2. Technical Advisors (TADV)

7.1.8. There may be one or more SDT: the membership of each team should be stable and cover all the responsibilities defined for the Development roles.

7.1.8.1. SDTs are team with goals, not set of individuals forming a group of unrelated peoples having different personal goals.

7.1.8.1.1. Team means:

7.2. Legend

7.2.1. Orange

7.2.1.1. Business intrest roles representing the business view

7.2.1.2. Typically taken by business personnel

7.2.2. Blue

7.2.2.1. Management intrest roles representing the management / leadership view

7.2.2.2. Managing or facilitating the management / leadership aspects of the project

7.2.3. Green

7.2.3.1. Solution / technical intrest roles representing the solution / technical view

7.2.3.2. Contributing to technical consistency, design or development of the solution

7.2.4. Grey

7.2.4.1. Process intrest roles representing the process view

7.2.4.2. Facilitating the process aspects of the project

7.3. Role Combinations

7.3.1. Permissible Role Combinations

7.3.1.1. Combinations should not in general be considered transitive.

7.3.1.1.1. The ability to combine two distinct but overlapping pairs of roles does not imply that all three roles should be combined

7.3.1.2. Business Sponsor + Business Visionary

7.3.1.3. Business Visionary + Business Ambassador

7.3.1.4. Team Leader + Solution Developer

7.3.1.5. Team Leader + Solution Tester

7.3.1.6. Business Advisor + Soluton Tester

7.3.2. Non Permissible Role Combinations

7.3.2.1. Business Sponsor + Project Manager

7.3.2.2. Business Visionary + Project Manager

7.3.2.3. Business Visionary + Technical Coordinator

7.3.2.4. Business Analyst + Business Ambassador

7.3.2.5. Project Manager + Team Leader

7.3.2.6. Solution Developer + Solution Tester

7.3.2.7. Workshop Facilitator + any Project level role

7.3.2.8. DSDM Coach + any SDT role

7.4. Project-level roles

7.4.1. The Project-level roles are

7.4.1.1. Business Sponsor (BS), Business Visionary (BV), Technical Coordinator (TC), Project Manager (PM) and Business Analyst (BA)

7.4.1.2. Directors, managers and coordinators of the project work. They will either be on or directly report to any project board or steering committee.

7.4.2. Business Sponsor (BS)

7.4.2.1. Project Champion.

7.4.2.2. Most senior project-level business role.

7.4.2.3. Provides the overall strategic direction and funding.

7.4.2.4. Hold a sufficiently high position in the organisation to be able to resolve business issues (e.g. to force open closed doors) and make financial decisions.

7.4.2.5. Has a crucial responsibility to ensure and enable fast progress throughout the project.

7.4.2.6. There should be only one person responsible for this role.

7.4.2.7. Prime concern is in the value and benefit of the project, rather than details

7.4.2.8. Responsibilities

7.4.2.8.1. Owns the Business Case.

7.4.2.8.2. Ensuring ongoing viability of the project in line with the Business Case.

7.4.2.8.3. Ensuring that funds and other resources are made available as needed.

7.4.2.8.4. Ensuring the decision-making process for escalated project issues is effective and rapid.

7.4.2.8.5. Responding rapidly to escalated issues.

7.4.2.9. Mappings to other roles in other methods ...

7.4.2.9.1. PRINCE2®

7.4.3. Business Visionary (BV)

7.4.3.1. Senior project-level business role.

7.4.3.2. Provides the “big picture” and the context for the project.

7.4.3.3. More actively involved than the Business Sponsor.

7.4.3.4. Responsible for interpreting the needs of the Business Sponsor, communicating these to the team and, where appropriate, ensuring they are properly represented in the Business Case.

7.4.3.5. If the project is part of a larger programme, the Visionary is in a position to judge project issues in the light of the programme and the potential impacts beyond the project.

7.4.3.6. Remains involved throughout the project.

7.4.3.7. Providing the team with strategic direction.

7.4.3.8. Ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.

7.4.3.9. Responsibilities

7.4.3.9.1. Owning the wider implications of any business change from an organisational perspective.

7.4.3.9.2. Defining the business vision for the project.

7.4.3.9.3. Communicating and promoting the business vision to all interested parties.

7.4.3.9.4. Monitoring progress of the project in line with the business vision.

7.4.3.9.5. Contributing to key requirements, design and review sessions.

7.4.3.9.6. Approving changes to the high-level requirements in the Prioritised Requirements List.

7.4.3.9.7. Ensuring collaboration across stakeholder business areas.

7.4.3.9.8. Ensuring business resources are available as needed.

7.4.3.9.9. Promoting the translation of the business vision into working practice.

7.4.3.9.10. Acting as a final arbiter of any disagreements between team members.

7.4.3.9.11. ... in general governing WHAT

7.4.3.10. Mappings to other roles in other methods ...

7.4.3.10.1. PRINCE2®

7.4.4. Technical Coordinator (TC)

7.4.4.1. Technical design authority for the project.

7.4.4.2. Technical architecture design authority.

7.4.4.3. Ensures technical consistency and coherence across SDTs.

7.4.4.4. Ensures adherence to agreed standards.

7.4.4.5. The “glue” that holds the project together for technology and innovation.

7.4.4.6. Equivalent to the Business Visionary (BV), ensuring the solution is technically sound and cohesive.

7.4.4.6.1. When the same person is in both roles (BV and TC) there is too much temptation to gold plate the solution with features that are technically interesting but of little or no value to the actual stakeholders.

7.4.4.7. Responsibilities

7.4.4.7.1. Agreeing and controlling the technical architecture.

7.4.4.7.2. Determining the technical environments.

7.4.4.7.3. Advising on and coordinating each team's technical activities.

7.4.4.7.4. Identifying and owning architectural and other technically based risk, escalating to the Project Manager as appropriate.

7.4.4.7.5. Ensuring the non-functional requirements (NFRs) are achievable and subsequently met.

7.4.4.7.6. Ensuring adherence to appropriate standards or best practice.

7.4.4.7.7. Controlling the technical configuration of the solution.

7.4.4.7.8. Managing technical aspects of the transition of the solution into live use.

7.4.4.7.9. Resolving technical differences between technical team members.

7.4.4.7.10. ... in general governing HOW

7.4.4.8. Mappings to other roles in other methods ...

7.4.4.8.1. PRINCE2®

7.4.4.8.2. Disciplined Agile Delivery (DAD)

7.4.5. Project Manager (PM)

7.4.5.1. Delivery focused.

7.4.5.2. Provides high level direction to SDTs

7.4.5.2.1. Multiple SDTs at once if project team is dividen on several SDTs.

7.4.5.3. Good communicator, with planning, management and co-ordination skills

7.4.5.4. Project Manager (PM) is a role - not necessarily the same as a job title that might be used in their organisation

7.4.5.5. Team Leaders (TL) often do DSDM® PM role in small projects.

7.4.5.5.1. This only works, however, if the PM clearly steps back from any resemblance of a command and control style in favor of self-organization.

7.4.5.6. There is usually only one PM, or at least a single person is ultimately accountable for delivery of the project.

7.4.5.7. Responsibilities

7.4.5.7.1. Communicating with senior management and the project governance authorities (Business Sponsor, project board, steering committee, etc.) with the frequency and formality that they deem necessary.

7.4.5.7.2. High-level project planning and scheduling, but not detailed task planning.

7.4.5.7.3. Monitoring progress against the baselined project plans.

7.4.5.7.4. Managing risk and any issues as they arise, escalating to senior business or technical roles as required.

7.4.5.7.5. Managing the overall configuration of the project.

7.4.5.7.6. Motivating the teams to meet their objectives.

7.4.5.7.7. Managing business involvement within the SDTs.

7.4.5.7.8. Resourcing Specialist Roles as required.

7.4.5.7.9. Handling problems escalated from the Solution Development Teams.

7.4.5.7.10. Coaching the SDTs when handling difficult situations.

7.4.5.8. Mappings to other roles in other methods ...

7.4.5.8.1. PRINCE2®

7.4.6. Business Analyst (BA)

7.4.6.1. Fully integrated with SDT.

7.4.6.1.1. Not an intermediary between Business Ambassador and team.

7.4.6.1.2. Supports communication between the business and the SDT.

7.4.6.2. Focuses on the relationship between the business and technical roles

7.4.6.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.

7.4.6.4. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.

7.4.6.5. Responsibilities

7.4.6.5.1. Managing development, distribution and baseline approval of all documentation and products related to business requirements and their interpretation

7.4.6.5.2. Ensuring that the business implications of all day-to-day decisions are properly thought through

7.4.6.6. The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team.

7.4.6.6.1. This allows the Business Analyst to, for example, help the business to formulate the Business Case, and also to be involved in assisting the business in defining their requirements during feasibility and foundations, sometimes before the full Solution Development Team. is assigned.

7.4.6.7. see AgileBA® mind map

7.5. Solution Development Team (SDT) (project can have multiple SDTs)

7.5.1. The Development roles are

7.5.1.1. Team Leader (TL), Business Ambassador (BAMB), Business Analyst (BA), Solution Developer (SD) and Solution Tester (ST).

7.5.1.2. Jointly these roles form the "engine room" of the project.

7.5.1.2.1. They shape and build the solution and are collectively responsible for its day-to-day development and for assuring its fitness for business purpose.

7.5.2. The SDT on an DSDM® project is empowered to make decisions on a day-to-day basis within their agreed terms of reference.

7.5.2.1. They do not have to formally agree each and every decision with the PM.

7.5.2.2. Business decisions (within agreed boundaries are made by Business Ambassador(s), so healthy Solution Development Team does not need to escalate all issues.

7.5.3. The SDT has every competency it needs to deliver a done Timebox / Increment.

7.5.4. The majority of team members should be “generalizing specialists”

7.5.4.1. Also known as “T-Shaped” people

7.5.5. We should allow them to create an environment in which they will thrive as a team.

7.5.5.1. This includes allowing them to set up a work environment that fosters collaboration, use of tooling that they find most effective, and the freedom to customize and optimize their team’s development process.

7.5.6. Solution Development Teams are:

7.5.6.1. Empowered

7.5.6.1.1. "Get the right people. Then, no matter what else you may do wrong after that, the people will save you. That's what management is all about." Tom DeMarco, 1997

7.5.6.1.2. "Worker are knowledge workers if they know more about the work they perform than their bosses." Peter Drucker

7.5.6.2. Self-directed / Self-disciplined

7.5.6.2.1. Teams commit only to the work they can accomplish and then perform that work as effectively as possible.

7.5.6.2.2. Fully and exclusively responsible for working out how the Timebox products will be developed.

7.5.6.2.3. Enterprise awareness is an important aspect of self-discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you.

7.5.6.3. Self-organizing

7.5.6.3.1. Teams estimate and plan their own work and then proceed to collaborate iteratively to do so.

7.5.6.3.2. Style of working

7.5.6.3.3. Who is needed on the team and not

7.5.6.3.4. When it needs help resolving Impediments

7.5.6.3.5. Needed process improvements

7.5.6.3.6. Technology practices

7.5.6.3.7. Techniques

7.5.6.3.8. Who does what and when

7.5.6.3.9. Self-organizing rarely means self-managing

7.5.6.3.10. Intellectual workers, including development professionals, are most effective when they have a say in what work they do and how they do it.

7.5.6.3.11. "[...] study by Nonaka has shown that Japanese companies with a self-organizing characteristic tend to have higher performance records [...]" K. Imai, I.Nonaka, H. Takeuchi

7.5.6.3.12. "Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity." General George S. Patton

7.5.6.4. Self-aware (personalities/people)

7.5.6.4.1. Teams strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.

7.5.6.5. Self-sufficient

7.5.6.5.1. Having all the skills needed within the team to deliver and test products.

7.5.6.6. No hierarchy within the team

7.5.6.6.1. No bosses or managers.

7.5.6.7. Cross-functional

7.5.6.7.1. Without demarcation by role e.g. analyst, developer, tester, everybody is expected to perform any type of work needed to get the job done.

7.5.6.8. Small (7 +/- 2)

7.5.6.8.1. AgilePM® suggests that the optimum SDT size is 7 +/- 2 people - at this level, the team can communicate with one another with the minimum of formality, minimum of management overhead..

7.5.6.8.2. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"

7.5.6.9. Autonomical

7.5.6.9.1. Yet SDTs do not work in a vacuum.

7.5.6.9.2. Autonomy is the degree to which the execution of task offers freedom, independence and discretion in the scheduling of work and determination of how it is to be completed.

7.5.6.9.3. External Autonomy

7.5.6.9.4. Internal Autonomy

7.5.6.9.5. Individual Autonomy

7.5.6.10. Accountable

7.5.6.10.1. SDTs are accountable for fulfilling the goal(s) they have taken on.

7.5.6.11. Collaborative

7.5.6.11.1. Download: 17 Indisputable Laws of Teamwork by John Maxwell

7.5.6.11.2. Improved collaboration between peole correspondingly increases the opportunities for people to learn from one another.

7.5.6.12. Based on trust and respect

7.5.6.12.1. Trust but verify and then guide

7.5.6.13. Ideally static

7.5.6.13.1. Most successful with long-term, full-time membership.

7.5.6.13.2. Subject to re-structuring if team is not working.

7.5.6.14. Ideally collocated

7.5.6.14.1. Most successful when located in one team room (particularly for the first few Timeboxes).

7.5.6.14.2. Collocated mentally not only phisically.

7.5.6.14.3. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001

7.5.6.15. Skillful (craft)

7.5.6.16. Team means:

7.5.6.16.1. T - Together

7.5.6.16.2. E - Everyone

7.5.6.16.3. A - Achieves

7.5.6.16.4. M - More

7.5.7. Solution Development Team are similar to Development Team in Scrum but with more defined responsibilities

7.5.7.1. Agile Project Management and Scrum V2 pocketbook

7.5.7.1.1. ISBN-13: 978-0992872793

7.5.7.1.2. Pages: 62

7.5.7.1.3. http://dsdm.org/product/agile-project-management-and-scrum

7.5.8. Team Leader (TL)

7.5.8.1. The agile community has focused on project or team leadership over team management.

7.5.8.2. Leadership rather than management.

7.5.8.3. Person holding it will ideally be elected by his or her peers as the best person to lead.

7.5.8.4. Reporting to the PM.

7.5.8.5. Ensures that a SDT functions as a whole and meets its objectives.

7.5.8.6. Works with the team to plan and co-ordinate all aspects of product delivery at the detailed level.

7.5.8.7. A good team lead is sensitive to personalities (introvert vs extrovert) and encourages team members to be more extroverted and to communicate proactively in a non-judgmental environment.

7.5.8.7.1. e.g. Some technical people are introverted and not comfortable with proactively collaborating and communicating.

7.5.8.8. Mappings to other roles in other methods ...

7.5.8.8.1. PRINCE2®

7.5.9. Business Ambasador (BAMB)

7.5.9.1. A true “ambassador”.

7.5.9.2. Business role within the SDT.

7.5.9.3. Working closely with the rest of the SDT.

7.5.9.4. Responsible for the day-to-day communication between the project and the business.

7.5.9.5. Guides the evolution of the solution.

7.5.9.6. Generally comes from the business area being addressed.

7.5.9.7. Provides business-related information from the perspective of those who will ultimately make direct use of the solution.

7.5.9.8. Provides the business perspective for all decisions related to the way the solution's fitness for business purpose is defined and implemented.

7.5.9.9. Empowered to make immediate decisions for a wide range of business stakeholders.

7.5.9.9.1. The empowerment issue can be tough for organizations used to a command-and-control management strateg

7.5.9.10. Stress key nature of this role.

7.5.9.11. These are typically very busy people who the business struggle to spare.

7.5.9.11.1. Can quickly become a bottleneck for the team.

7.5.9.12. Responsibilities

7.5.9.12.1. Contributing to all requirements, design and review sessions

7.5.9.12.2. Providing the business perspective for all day-to-day project decisions

7.5.9.12.3. Providing the detail of business scenarios to help define and test the solution

7.5.9.12.4. Communicating with other users, involving them as needed and getting their agreement

7.5.9.12.5. Providing day-to-day assurance that the solution is evolving correctly

7.5.9.12.6. Organising and controlling business acceptance testing of the solution

7.5.9.12.7. Developing business user documentation for the ultimate solution

7.5.9.12.8. Ensuring user training is adequately carried out

7.5.9.12.9. Attending the daily team meetings

7.5.10. Business Analyst (BA)

7.5.10.1. Fully integrated with SDT.

7.5.10.1.1. Not an intermediary between Business Ambassador and team.

7.5.10.1.2. Supports communication between the business and the SDT.

7.5.10.2. Focuses on the relationship between the business and technical roles

7.5.10.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.

7.5.10.4. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.

7.5.10.5. Responsibilities

7.5.10.5.1. Managing development, distribution and baseline approval of all documentation and products related to business requirements and their interpretation

7.5.10.5.2. Ensuring that the business implications of all day-to-day decisions are properly thought through

7.5.10.6. The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team.

7.5.10.6.1. This allows the Business Analyst to, for example, help the business to formulate the Business Case, and also to be involved in assisting the business in defining their requirements during feasibility and foundations, sometimes before the full Solution Development Team. is assigned.

7.5.10.7. see AgileBA® mind map

7.5.11. Solution Developer (SD)

7.5.11.1. Interprets business requirements and translates them into a deployable solution that meets functional and non-functional needs.

7.5.11.2. Should ideally be allocated full time to the project.

7.5.11.3. Where they are not full time, the project ought to be their first priority - if this cannot be achieved, significant risk is introduced with regard to timeboxing.

7.5.11.4. DSDM® states that ideally we are looking for true Analyst and Developer in one person

7.5.11.4.1. Soft skills cannot be underestimated - especially communication, negotiation, selling, listening etc.

7.5.12. Solution Tester (ST)

7.5.12.1. Fully integrated with the SDT.

7.5.12.2. Performs testing in accordance with the Technical Testing Strategy.

7.5.12.3. Ensure quality solution.

7.5.12.4. Independence of testing is key

7.5.12.5. Typically the Solution Tester (ST) reports to the Technical Coordinator (TC) in terms of test results and quality. rather than to the Team Leader (TL).

7.5.12.6. Responsibilities

7.5.12.6.1. Works collaboratively with Business Ambassador (BAMB), Solution Developers (SD) and other Solution Testers (ST)

7.5.12.6.2. Carrying out all types of technical testing of the solution as a whole

7.5.12.6.3. Creating testing products, e.g. test cases, plans and logs

7.5.12.6.4. Reporting the results of testing activities to the Technical Coordinator (TC) for Quality Assurance purposes

7.5.12.6.5. Keeping the Team Leader (TL) informed of the results of testing activities

7.5.12.6.6. Assisting the Business Ambassador(s) (BAMB) and Business Advisor(s) (BADV) to ensure that they can plan and carry out their tests well enough to ensure that the important areas are covered

7.5.12.7. Mappings to other roles in other methods ...

7.5.12.7.1. eXtreme Programming (XP)

7.5.12.7.2. Disciplined Agile Delivery (DAD)

7.6. Supporting Roles

7.6.1. The Supporting roles are

7.6.1.1. Business Advisors (BADV), Technical Advisors (TADV), Workshop Facilitator (WF) and DSDM Coach (DC) provide assistance and guidance to the project on a more ad hoc basis throughout the lifecycle.

7.6.1.1.1. The Advisor roles may be filled by one or more subject matter experts.

7.6.1.2. The project may bring in subject matter experts as necessary for their specialist expertise.

7.6.2. Business Advisor (ADV)

7.6.2.1. Often a peer of the Business Ambassador.

7.6.2.2. Called upon to provide specific, and often, specialist input to solution development or solution testing.

7.6.2.3. Often user or beneficiary of the solution.

7.6.2.4. May, for example, simply provide legal or regulatory advice with which the solution must comply.

7.6.2.5. Responsibilities

7.6.2.5.1. Providing specialist advice on, or help with:

7.6.2.5.2. Providing specialist input into relevant:

7.6.2.6. Mappings to other roles in other methods ...

7.6.2.6.1. Disciplined Agile Delivery (DAD)

7.6.3. Technical Advisor (TADV)

7.6.3.1. Technical equivalent of a Business Advisor.

7.6.3.2. Supports SDT.

7.6.3.3. Provides specific and often specialist technical input and advice.

7.6.3.4. Working within boundaries of the technical vision definecd by the Technical Coordinator (TC), Tecnhical Advisors (TADVs) are responsible for helping the Business Ambassador (BAMB) shape the requirements in the PRL, providing depth and detail of the technical characteristics of the solution under development.

7.6.3.5. could be in real life for example ...

7.6.3.5.1. IT Security Expert

7.6.3.5.2. IT Security Consultatant

7.6.3.5.3. Business Continuity Expert

7.6.3.5.4. Risk Manager (from organization)

7.6.3.5.5. Support

7.6.3.6. Mappings to other roles in other methods ...

7.6.3.6.1. Disciplined Agile Delivery (DAD)

7.6.4. Workshop Facilitator (WF)

7.6.4.1. "A facilitator is someone who uses some level of intuitive or explicit knowledge of group process to formulate and deliver some form of formal or informal process design and interventions at a shallow or deep level to help a group achieve what they want or need to do or get where hey want or need to go" (Ned Ruete, International Association of Facilitators (IAF))

7.6.4.2. Independent from project team and client.

7.6.4.2.1. Independent of workshop outcome.

7.6.4.3. Managing the workshop process.

7.6.4.4. Responsible for the context of the workshop, not the content.

7.6.4.5. Catalyst for preparation and communication.

7.6.4.6. Responsibilities

7.6.4.6.1. For each workshop:

7.6.4.6.2. Engaging with participants to:

7.6.4.7. Download: What Do We Mean By Facilitation

7.6.5. DSDM Coach (DC)

7.6.5.1. Key to helping a team with limited experience of using DSDM® to get the most out of the approach within the context of the wider organisation in which they work.

7.6.5.2. Should ideally be independently to ensure competence to fulfil this role.

7.6.5.3. For teams new to agile, it often makes sense to have a part-time experienced coach working with the team for a few iterations for more.

7.6.5.4. In Scrum, this role is part of the Scrum Master role.

7.6.5.5. Responsibilities

7.6.5.5.1. Embedding the DSDM® framework.

7.6.5.5.2. Providing detailed knowledge and experience of DSDM® to inexperienced agile teams

7.6.5.5.3. Tailoring the DSDM® process to suit the individual needs of the project and the environment in which the project is operating

7.6.5.5.4. Helping the team use DSDM® techniques and practices and helping those outside the team appreciate the DSDM® philosophy and value set

7.6.5.5.5. Helping the team work in the collaborative and cooperative way demanded by DSDM® and all agile approaches

7.6.5.5.6. Building DSDM® capability within the team

7.7. Summary & Conclusion

7.7.1. DSDM® identifies roles in 3 categories / levels:

7.7.1.1. Project-level

7.7.1.2. Solution Development

7.7.1.3. Supporting / Other

7.7.2. The business interests are represented by

7.7.2.1. Business Sponsor (BS)

7.7.2.2. Business Visionary (BV)

7.7.2.3. Business Ambassador (BAMB)

7.7.2.4. Business Advisor (BADV)

7.7.3. The solution / technical interests are represented by

7.7.3.1. Technical Coordinator (TC)

7.7.3.2. Solution Developer (SD)

7.7.3.3. Solution Tester (ST)

7.7.3.4. Technical Advisor (TADV)

7.7.4. Management interests are represented

7.7.4.1. Project Manager (PM)

7.7.4.2. Team Leader (TL)

7.7.4.3. Business Analyst (BA)

7.7.5. Supporting interests are represented

7.7.5.1. DSDM Coach (DC)

7.7.5.2. Workshop Facilitator (WF)

7.7.6. One role may be taken by several people

7.7.7. One person may take several roles

8. DSDM® Products (a.k.a. Artifacts) (for simplicity documentation) (14)

8.1. Introduction

8.1.1. DSDM® identifies deliverables associated with each phase of the project lifecycle.

8.1.1.1. These are referred to as Products.

8.1.1.1.1. Could be documentation (Word, Excel), could be model (software for PPM) etc.

8.1.2. Not all products are required for every project.

8.1.2.1. Enables the product set for a particular project to be kept to a minimum.

8.1.3. Product represent an information (not files)

8.1.3.1. Product is not one to one equivalent of separate Word, Excel or any other file

8.1.4. Formality associated with each product will vary from project to project and from organisation to organisation.

8.1.4.1. a.k.a. 'Adopt and Adapt'

8.1.5. Some products are specific to a particular phase in the lifecycle, others may continue to evolve through subsequent phases. (see diagram)

8.1.6. The level of documentation required depends on the ease of communication of team members

8.1.6.1. Colocated Agile teams need less detail when writing down User Stories than distributed teams

8.1.7. Formal products definitions specifies:

8.1.7.1. When the product is produced, used, updated and archived. This gives a clear view of the transience of a given product and therefore enables appropriate levels of quality control to be applied.

8.1.7.2. The roles that could be responsible for producing, contributing to, accepting and approving the product.

8.1.7.2.1. These are only suggestions but give an indication of what product responsibilities could be allocated to the people in each role.

8.1.7.3. The product's Quality Criteria, i.e. the set of questions that should be answered positively if the product has fulfilled its purpose satisfactorily.

8.1.8. Documentation in an Agile project should be sufficient for purpose, and only that. The two golden rules of Agile documentation are

8.1.8.1. Do not document unless it is useful to someone specific (a 50 page document that no-one actually reads is not proving useful to anyone)

8.1.8.2. Document in a way that is useful to the recipient (ask how this will be used, and by whom)

8.2. For people coming from non corporate environment these products may be a bit overwhelming (e.g. small projects combining only several people).

8.2.1. Remember - product is just a set a information, how you store and update this information is up to you

8.2.2. Products information can be stored in a classic Word, Excel, Powerpoint style, as a model built in PPM software or even with no storage at all - it is up to you and your organisation how AgilePM will be tailored.

8.3. For people coming from corporate environment these products are already used in most of their projects.

8.3.1. Products can have different names but information provided by these products are similar to those which are already used and maintained by corporate governance systems or Qualiy Assuarence (QA) systems internally developed project management method)

8.4. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001

8.5. Legend

8.5.1. Icon

8.5.1.1. This means that selected products are Gateway Products, which can be used for Yes / No decision if project should be continued

8.5.2. Orange

8.5.2.1. Business focused products

8.5.3. Green

8.5.3.1. Solution focused products

8.5.4. Blue

8.5.4.1. Management focused products

8.5.5. Evolutionary products

8.5.5.1. They typically, but not always, span a number of project phases and may be baselined more than once during that time.

8.5.6. Milestone products

8.5.6.1. Typically fulfil a specific purpose within that phase as a checkpoint or to facilitate governance processes

8.6. Pre-Project phase

8.6.1. Terms of Reference (ToR)

8.6.1.1. In real life corporate environments this product is often called Project Kick-off

8.6.1.2. Defines at a very high level the objectives and business drivers for the proposed project.

8.6.1.2.1. high-level definition of the over-arching business driver for, and top-level objectives of, the project.

8.6.1.2.2. Outlines the rationale for the project (e.g., business drivers)

8.6.1.3. The primary aim of the Terms of Reference is to scope and justify the Feasibility phase.

8.6.1.3.1. Not the whole project.

8.6.1.4. Very short document (one or two pages).

8.6.1.4.1. Can be less formal - email, verbal agreement.

8.6.1.5. Recommeded content

8.6.1.5.1. A brief outline of the business need and the objectives and scope for the project to meet that need.

8.6.1.6. Recommeded responsibilities

8.6.1.6.1. Produced by

8.6.1.6.2. Approved by

8.6.1.6.3. Produced for

8.7. Feasibility phase

8.7.1. Business Case

8.7.1.1. Describes essential business considerations that justify the project, and then are used to assess the viability of the project moving forwards.

8.7.1.2. Contains the business vision and justification for the project and requires revalidation throughout the project.

8.7.1.2.1. The business vision describes a changed business as it is expected to be, incrementally and at the end of the project.

8.7.1.3. Ought to quantify the costs and value of a project.

8.7.1.3.1. Explain how this value is delivered on an incremental basis and how this is likely to impact existing business processes and organisation.

8.7.1.4. Likely to describe constraints, assumptions, dependencies and risks.

8.7.1.5. Baselines of the Business Case are typically created first as an outline by the end of Feasibility.

8.7.1.5.1. Then as a basis for approval of development by the end of Foundations.

8.7.1.5.2. It is formally reviewed at the end of each Project Increment in order to determine whether further work is justified.

8.7.1.6. Recommeded responsibilities

8.7.1.6.1. Produced by

8.7.1.6.2. Approved by

8.7.1.6.3. Produced for

8.7.2. Prioritised Requirements List (PRL)

8.7.2.1. Describes, at a high level, the requirements that the project needs to address if the Business Case is to be met

8.7.2.1.1. Prioritized backlog of all requirements as derived during Feasibility and Foundations.

8.7.2.2. Baselined at a high level at the end of the Foundations phase

8.7.2.2.1. Consideration of requirements begins in Feasibility and a baseline of the PRL demarcates the scope of the project as at the end of Foundations.

8.7.2.2.2. Change to the breadth (adding, removing or significantly changing high-level requirements) needs to be formally controlled in order to ensure ongoing alignment with the business vision for the project and to keep control of the scope.

8.7.2.2.3. Refined for detail as the project proceeds through project reflecting changes to depth and detail drawn out by the Iterative Development process.

8.7.2.3. PRL is Progressively Refined.

8.7.2.4. There is one PRL for project but each Increment or Timebox can haw it's own PRL (a.k.a. Sprint Backlog from Scrum).

8.7.2.5. Requirements formulated during Feasibility have the character of epics (i.e., outcome based high-level statements that clarify scope).

8.7.2.6. During the Foundations phase the first key non-functionals make their appearance.

8.7.2.7. PRL contains both:

8.7.2.7.1. Functional Requirements (FR)

8.7.2.7.2. Non-Functional Requirements (NFR)

8.7.2.7.3. any related job to be done

8.7.2.8. Recommeded content

8.7.2.8.1. A list of high-level requirements to be addressed.

8.7.2.8.2. A business driven prioritisation of the requirements in accordance with the MoSCoW prioritisation process.

8.7.2.9. Recommeded responsibilities

8.7.2.9.1. Produced by

8.7.2.9.2. Approved by

8.7.2.9.3. Produced for

8.7.3. Solution Architecture Definition (SAD)

8.7.3.1. Provides an overview and architectural framework for both business and technical aspects of the potential solution. This will evolve as the project proceeds.

8.7.3.1.1. High-level solution design from both business and technical viewpoints.

8.7.3.1.2. Primary purpose to establish the scope for evolutionary development including desired maintainability levels.

8.7.3.2. The Solution Architecture Definition (SAD) should be created for any project where there is a systems aspect to the solution.

8.7.3.3. Defines the technical framework within which the solution will be developed and provides a high-level description of the architecture of that solution.

8.7.3.4. Recommeded responsibilities

8.7.3.4.1. Produced by

8.7.3.4.2. Approved by

8.7.3.4.3. Produced for

8.7.4. Development Approach Definition (DAD)

8.7.4.1. The Development Approach Definition (DAD) defines how the SDT will develop and how they, and associated technical experts and stakeholders, will assess the fitness for purpose of the solution as it evolves against business and technical acceptance criteria.

8.7.4.1.1. This element of the Solution Foundations may be omitted if the PM and TC agree the required practices and standards are already fully embedded as custom and practice for the organisation as a whole.

8.7.4.2. Defines the standards and practices to be adhered to and provides guidance on how the solution should be evolved as the project proceeds. It includes the ‘Defintion of Done’.

8.7.4.2.1. Overview of tools, practices and standards that are to be adopted in the project.

8.7.4.3. Recommeded content

8.7.4.3.1. A definition of development practices that SDT are expected to follow.

8.7.4.3.2. All practices should be defined but as a minimum these must include:

8.7.4.3.3. A definition of any specific standards to be applied to development including, where applicable:

8.7.4.4. Recommeded responsibilities

8.7.4.4.1. Produced by

8.7.4.4.2. Approved by

8.7.4.4.3. Produced for

8.7.5. Delivery Plan

8.7.5.1. a.k.a. Release Plan

8.7.5.2. Provides an initial high-level schedule of Increments and Timeboxes and other activities for development, testing and deployment of the solution.

8.7.5.2.1. For larger projects a single high-level Delivery Plan will deal with coordination of the efforts of multiple SDT teams.

8.7.5.2.2. On smaller simpler projects the Delivery/Release Plan may be integrated with the PRL with User Stories identified as belonging to a particular planned release.

8.7.5.3. This plan is constantly reviewed and revised as the project progresses to reflect the latest business demands and predicted outcomes in terms of timescales and delivered scope

8.7.5.4. The Delivery Plan refines and elaborates on the schedule.

8.7.5.5. Consists of 1 components

8.7.5.5.1. Schedule of Timeboxes

8.7.5.6. Recommeded content

8.7.5.6.1. The incremental nature of the project

8.7.5.6.2. The dates associated with the increments and other key milestones.

8.7.5.6.3. The dates for deployment of the solution and, where applicable, subsets of it

8.7.5.6.4. An indication of the focus of each Development Timebox

8.7.5.6.5. The timing and dependencies of any activities not planned within the Development Timeboxes

8.7.5.6.6. The allocation of resources to timeboxes and other activities

8.7.5.6.7. An identification of the contingency associated with one or more of the key constraints of time, resource/cost or, preferably, scope

8.7.5.7. Recommeded responsibilities

8.7.5.7.1. Produced by

8.7.5.7.2. Approved by

8.7.5.7.3. Produced for

8.7.6. Management Approach Definition (MAD)

8.7.6.1. The Management Approach Definition (MAD) product describes essential governance and organisational aspects of the project and describes precisely how the project will be managed.

8.7.6.1.1. It also describes how the DSDM® practices and techniques will be applied to ensure management of the project through to a successful conclusion.

8.7.6.1.2. Organisational and planning aspects of the project as well as the engagement of stakeholders.

8.7.6.1.3. It reflects the approach to the management of the project as a whole and considers, from a management perspective, how the project will be organised and planned, how stakeholders will be engaged in the project and how progress will be demonstrated and, if necessary, reported.

8.7.6.2. Note: it is important that the Project Approach Questionnaire (PAQ) responses created in Feasibility are reviewed at this point and that any changes to responses are considered when defining how the project will be managed from here on.

8.7.6.3. Describes the approach to the set-up and management of various aspects of the project, including how the project will be organised and governed.

8.7.6.3.1. It also describes the approach to managing Change, Configuration, Communication and Risk.

8.7.6.4. Management Approach Definition (MAD) is outlined in Feasibility and baselined at the end of Foundations and will only evolve beyond that when circumstances change or if review of the approach identifies areas for improvement.

8.7.6.5. Recommeded content

8.7.6.5.1. A validation of the Objectives and Success Criteria for the project

8.7.6.5.2. The project approach - based on analysis of the latest responses to the Project Approach Questionnaire (PAQ) and also including the processes required for governance and, where applicable, contact management

8.7.6.5.3. The project organisation, including roles and responsibilities, empowerment of teams and reporting lines and governance

8.7.6.5.4. Project Management controls for Monitoring and Reporting, Change Control and Risk Management

8.7.6.5.5. An overview of the key deliverables, milestones and incremental staging of product delivery

8.7.6.5.6. An analysis of major project dependencies

8.7.6.6. Recommeded responsibilities

8.7.6.6.1. Produced by

8.7.6.6.2. Approved by

8.7.6.6.3. Produced for

8.7.7. Feasibility Assessment

8.7.7.1. The Feasibility Assessment provides a snapshot of the evolving business, solution and management products described above as they exist at the end of the Feasibility phase.

8.7.7.2. Where created, each of the products should be mature enough to make a sensible contribution to the decision as to whether the project is likely to be feasible or not.

8.7.7.3. The Feasibility Assessment may be expressed as a baselined collection of the products described or as an executive summary covering the key aspects of each of them.

8.7.7.4. Assessing the feasibility of the project both from a business and a technical perspective.

8.7.7.5. Addresses main risks, by providing a description and a mitigation strategy for any risks significant enough to influence the viability of the project.

8.7.7.6. Recommeded content

8.7.7.6.1. The business vision of success.

8.7.7.6.2. The scope and objectives of the proposed project.

8.7.7.6.3. High-level assumptions, dependencies and risk that may impact project viability.

8.7.7.6.4. Any alternatives that were considered and rejected.

8.7.7.6.5. The major deliverables of the proposed project.

8.7.7.6.6. A high-level description of a solution to support the Business Case.

8.7.7.6.7. An initial identification of any technical constraints to which the solution must adhere.

8.7.7.6.8. (optional) A disposable 'candidate' of the solution (or key elements of it), demonstrating how it will eventually work and / or demonstrating the technical feasibility of its more risky or complex elements.

8.7.7.7. Recommeded responsibilities

8.7.7.7.1. Produced by

8.7.7.7.2. Approved by

8.7.7.7.3. Produced for

8.8. Foundations phase

8.8.1. Foundations Summary

8.8.1.1. The Foundations Summary provides a snapshot of the evolving business, solution and management products described above as they exist at the end of the Foundations phase.

8.8.1.2. Where created, each of the products should be mature enough to make a sensible contribution to the decision as to whether the project is likely to deliver the required return on investment.

8.8.1.3. The Foundations Summary may be expressed as a baselined collection of the products described or as an executive summary covering the key aspects of each of them.

8.8.1.4. Recommeded responsibilities

8.8.1.4.1. Produced by

8.8.1.4.2. Approved by

8.8.1.4.3. Produced for

8.9. Evolutionary Development

8.9.1. Evolving Solution

8.9.1.1. The Evolving Solution is made up of all appropriate components of the final solution together with any intermediate deliverables necessary to explore the detail of requirements and the solution under construction.

8.9.1.1.1. Not only of the solution (be it partial or complete) but also the supporting artefacts produced during its creation (e.g., models, prototypes, tests, reviews).

8.9.1.2. At any given time, such components may be either complete, a baseline of a partial solution, or a work in progress.

8.9.1.2.1. They include, where valuable: models, prototypes, supporting materials and testing and review artefacts.

8.9.1.3. The precise nature and composition of the Evolving Solution is entirely dependent on the objectives of the project and the current position in the project timeline.

8.9.1.3.1. At one extreme, at the beginning of a project it could be a preliminary sketch of a new business process on a flip chart.

8.9.1.3.2. Towards the end of a project it may be a fully evolved and documented business process supported by a software application and all documentation to use, support and maintain it. It is simply a convenient term to describe a 'work in progress'.

8.9.1.4. At the end of each Project Increment the Solution Increment is deployed into live use and becomes the Deployed Solution.

8.9.1.5. Recommeded responsibilities

8.9.1.5.1. Produced by

8.9.1.5.2. Approved by

8.9.1.5.3. Produced for

8.9.2. Timebox Plan

8.9.2.1. The Timebox Plan elaborates on the objectives provided for each Development Timebox in the Delivery Plan.

8.9.2.1.1. Plan elaborates in greater detail those elements of the Prioritized Requirements List (PRL) as defined by the schedule found in the Delivery Plan that are to be tackled during the Timebox.

8.9.2.2. Recommeded content

8.9.2.2.1. A definition of the product(s) of an individual Development Timebox

8.9.2.2.2. An identification of key milestones, e.g. technical or user review dates, within a timebox

8.9.2.2.3. An agreed MoSCoW prioritisation of products and activities within a Development Timebox

8.9.2.2.4. An identification of all the resources (human and otherwise) required for successful completion of all work

8.9.2.3. Recommeded responsibilities

8.9.2.3.1. Produced by

8.9.2.3.2. Approved by

8.9.2.3.3. Produced for

8.9.3. Timebox Review Record

8.9.3.1. The formality of this record will vary from official, signed documents to informal notes or emails depending on the project and the organisation.

8.9.3.1.1. However the information encompassed by the Timebox Review Record should always exist in some physical form.

8.9.3.2. The Timebox Review Record is produced / updated at the review points in the Development Timebox.

8.9.3.2.1. They describe what has been achieved and any feedback which may influence plans moving forwards.

8.9.3.2.2. After the timebox has completed any outstanding issues are considered in the context of the Delivery Plan and future Timebox Plans.

8.9.3.3. This is a running review of what has been achieved, feedback, outstanding issues and key decisions and could be constructed to be used for auditing purposes if necessary.

8.9.3.4. Recommeded content

8.9.3.4.1. A record of the success of delivery, against the Timebox Plan, specifically describing what has been delivered and what has not.

8.9.3.4.2. A record of the formal acceptance of the completed deliverables by the business representatives identified to accept them.

8.9.3.4.3. An assessment of the priority of any work not completed and a plan to show whether and when it will be, either as part of the current timebox or at some point in the future.

8.9.3.4.4. An assessment of the effectiveness of the timebox control processes and the Iterative Development techniques in line with the principles of Atern.

8.9.3.5. Recommeded responsibilities

8.9.3.5.1. Produced by

8.9.3.5.2. Approved by

8.9.3.5.3. Produced for

8.10. Deployment phase

8.10.1. Project Review Report

8.10.1.1. Consists of 3 components

8.10.1.1.1. End of Project Assessment

8.10.1.1.2. Benefits Enablement Summary (one or more)

8.10.1.1.3. Increment Review (one or more)

8.10.1.2. Recommeded responsibilities

8.10.1.2.1. Produced by

8.10.1.2.2. Approved by

8.10.1.2.3. Produced for

8.11. Post Project phase

8.11.1. Benefits Assessment

8.11.1.1. The Benefits Assessment describes how the benefits have actually accrued, as the Deployed Solution has been used.

8.11.1.1.1. For projects where benefits in the Business Case are expected to accrue over a prolonged period, it is likely that Benefits Assessments will be produced on a periodic basis.

8.11.1.2. Recommeded content

8.11.1.2.1. A quantitative description of how the benefits of using the Deployed Solution have been achieved.

8.11.1.2.2. An analysis of any discrepancies between what has been achieved and what was predicted in the Business Case for the project.

8.11.1.3. Recommeded responsibilities

8.11.1.3.1. Produced by

8.11.1.3.2. Approved by

8.11.1.3.3. Produced for

8.12. Summary & Conclusion

8.12.1. DSDM® is a product-based approach

8.12.1.1. This is a more effective way than simple reports, that's way DSDM® doesn't have massive number of reports.

8.12.2. Projects use delivery of the appropriate products to demonstrate progress.

9. DSDM® key techniques (7)

9.1. MoSCoW Priritisation

9.1.1. One type of relative prioritisation

9.1.2. Helps in discovering customer / users needs priorities

9.1.3. Used as a tool for always hitting deadlines (Timeboxs / Increments), by dropping requirements of lower lever priority.

9.1.4. The MoSCoW Rules

9.1.4.1. The 60:20:20 ‘rule of thumb’

9.1.4.1.1. It is just a guide – not to be taken literally

9.1.4.1.2. Less than 60% is very important

9.1.4.1.3. Understand the Minimum Usable SubseT

9.1.4.2. Must Have

9.1.4.2.1. Cannot deliver on target date without this.

9.1.4.2.2. Core requirements.

9.1.4.2.3. No point in delivering on target date without this.

9.1.4.2.4. Delivered sollution is unusable without this.

9.1.4.2.5. Not legal without it.

9.1.4.2.6. Cannot deliver the Business Case without it.

9.1.4.2.7. No more than 60% effort

9.1.4.3. Should Have

9.1.4.3.1. Important but not vital.

9.1.4.3.2. Not critical.

9.1.4.3.3. May be painful to leave out, but the solution is still viable.

9.1.4.3.4. May need some kind of workaround e.g. management of expectations, some inefficiency, an existing solution, paperwork etc.

9.1.4.3.5. Normally classed as mandatory when more time is available, but without them the business objective will still be met.

9.1.4.3.6. @ 20% effort

9.1.4.4. Could Have

9.1.4.4.1. Wanted or desirable but less important.

9.1.4.4.2. Less impact if left out (compared with a Should Have).

9.1.4.4.3. Work arounds easy/cheap

9.1.4.4.4. @ 20% effort

9.1.4.5. Won't Have (this time / maybe next time, next Timebox, next Increment)

9.1.4.5.1. These are requirements which the project team (not only SDT) has agreed it will not deliver.

9.1.4.5.2. Won’t Haves are excluded from plans for the current delivery MoSCoW Prioritisation is the key AgilePM® technique which provides the basis for decision making about project team activity at all levels.

9.1.4.5.3. They are recorded in the Prioritised Requirements List (PRL) where they help clarify the scope of the project and to avoid being reintroduced 'via the back door' at a later date.

9.1.4.5.4. Requirements are still in scope of project.

9.1.4.5.5. Out of Scope for this timeframe / Timebox / Increment.

9.1.5. DSDM® MoSCoW recommendations

9.1.5.1. Use all the priorities.

9.1.5.2. Challenge Must Haves.

9.1.5.3. By default, at beginning, everything is Won't Have.

9.1.5.3.1. Start small with Enough Design Up Front (EDUF)

9.1.5.4. Agree what the priorities mean early in the project

9.1.5.5. Control the percentage of Must Haves - the target of 60% is to assure predictability. As the percentage of Must Haves increases above 60%, the predictability of the project decreases and the risk of failure increases

9.1.5.6. Agree how priorities will work

9.1.5.6.1. Prior to requirements capture, the definitions of Must Have, Should Have, Could Have and Won't Have need to be agreed with the business.

9.1.5.6.2. Must Have definition is not negotiable.

9.1.5.6.3. Must Have will have a critical impact on the success of the project.

9.1.5.6.4. Agree escalation or decision-making processes, e.g. Business Ambassador to Business Visionary to Business Sponsor, and agree the level of empowerment around decision-making at each level.

9.1.5.6.5. At the end of an increment, all unsatisfied requirements are reprioritised in the light of the needs of the next increment.

9.1.5.7. The Business Sponsor's perspective

9.1.5.7.1. The MoSCoW rules have been cast in a way that allows the delivery of the Minimum Usable Subset of requirements to be guaranteed.

9.1.5.7.2. A rule of thumb often used is that Must Have requirements do not exceed 60% of the effort. If this rule is followed, then that ensures contingency represents at least 40% of the total effort.

9.1.5.7.3. Whilst understanding that there is a real difference between a guarantee and an expectation, the Business Sponsor can reasonably expect more than this to be delivered except under the most challenging of circumstances. This is where the split between Should Haves and Could Haves comes into play.

9.1.5.7.4. If the Should Haves and Could Haves are split evenly with 20% of the total effort associated with each then the Musts and Shoulds, in combination, will represent no more than 80% of the total effort. The remaining 20% of effort associated with the Could Haves is now the contingency available to protect the more important requirements.

9.1.5.7.5. Sensible prioritisation, combined with timeboxing leads to predictability of delivery and therefore greater confidence

9.1.5.7.6. Keeping project metrics to show the percentage of Should Haves and Could Haves delivered on each increment or timebox will either re-enforce this confidence, if things are going well, or provide an early warning that some important (but not critical) requirements may not be met if problems arise.

9.1.5.8. MoSCoW and the Business Case

9.1.5.8.1. The best way to address prioritisation initially is with a quantified Business Case. This should support Feasibility and be revisited during Foundations.

9.1.5.8.2. If a Business Case does not exist, the Business Sponsor and Business Visionary need to articulate the business drivers, preferably in a quantified form.

9.1.5.8.3. A final consideration with regards to MoSCoW and the Business Case relates to the overall viability of the project.

9.1.5.8.4. Where there are very few Must Haves there may be a need to specify that a proportion of the Should Haves need to be delivered if the project is to remain viable. It is better to do this rather than to artificially raise specific Should Have requirements to Must Have status as it allows the best decision on precisely what requirement to work on to be deferred until later when its relative benefit may be more readily assessed.

9.1.6. Levels of priority

9.1.6.1. A Must Have requirement for the project as a whole may not be a Must Have for the first increment.

9.1.6.1.1. For example, even if a Must Have requirement for a computer system is the facility to archive old data, it is very likely that the solution could be used effectively for a few months without this facility being in place.

9.1.6.1.2. In this case, it is sensible to make the archive facility a Should or a Could Have for the first increment even though delivery of this facility is a Must Have before the end of the project.

9.1.6.2. Many consider this approach to be sensible as it allows the more important requirements to be addressed earlier rather than later but, if taking this approach, beware the risk of confusion.

9.1.6.3. Each deliverable effectively has two or even three priorities in different timeframes and the Project Manager needs to ensure that the team do not lose sight of the real business priorities.

9.1.6.4. The best way to deal with this is to create a Timebox PRL, a subset of the Project PRL that is specifically associated with a timebox and leave the priorities unchanged on the main PRL for the project.

9.1.6.5. The priority for the project may be different to that of an increment or timebox

9.1.6.6. Understand YAGNI, KISS

9.1.6.6.1. YAGNI

9.1.6.6.2. KISS

9.1.7. What to prioritise

9.1.7.1. Every item of work has a priority.

9.1.7.1.1. Priorities are set before work commences and kept under continual review as the work is done.

9.1.7.2. As new work arises either through introduction of a new requirement or through the exposure of unexpected work associated with existing requirements, the decision must be made as to how critical they are to the success of the current work using the MoSCoW rules.

9.1.7.3. All priorities should be reviewed throughout the project to ensure that they are still valid.

9.1.8. How many of each priority?

9.1.8.1. The aim is to get the percentage effort for Must Haves (in terms of effort to deliver) as low as possible and to be wary of anything above 60%, i.e. 60% Musts Haves, 40% Should Haves and Could Haves. Won't Haves are excluded from the calculation, as they won't be part of this project/increment/timebox.

9.1.8.2. Levels of effort above 60% for Must Haves introduce a risk of failure, unless the team are working in a project where estimates are known to be accurate, the approach is very well understood and the environment is understood and low-risk in terms of the potential for external factors to introduce delays.

9.1.9. Hierarchies of priorities

9.1.9.1. Requirements are identified at various levels of detail, from a high-level strategic viewpoint (typically at Feasibility) through to a more detailed, implementable level (typically during Exploration and Engineering).

9.1.9.2. High-level requirements can usually be decomposed and it is this decomposition that can help resolve one of the problems that often confront teams: that all requirements appear to be Must Haves.

9.1.9.3. If all requirements really were Must Haves, the flexibility derived from the MoSCoW prioritisation would no longer work. There would be no lower priority requirements to be dropped from the deliverables to keep a project on time and budget. In fact, this goes against the whole DSDM® ethos of fixing Time and Resources and flexing Features (the triangles diagram). Believing everything is a Must Have is often symptomatic of insufficient decomposition of requirements.

9.1.9.4. A high-level Must Have requirement frequently yields a mix of sub-requirements, each with a different priority.

9.1.9.4.1. Flexibility is once more restored and some of the detailed functionality can be dropped from the delivered solution so that the project deadline can be met.

9.1.9.5. Where a requirement has a Must Have below a Should Have for example, this would signify that if this requirement were to be delivered, it must have the lower level requirement to be acceptable.

9.1.10. Tips for assigning priorities

9.1.10.1. 1. Work closely with the Business Visionary to ensure they are fully up to speed as to why and how DSDM® prioritises requirements.

9.1.10.2. 2. Consider starting with all requirements as Won't Haves, and then justify why they need to be given a higher priority.

9.1.10.3. 3. For each requirement that is proposed as a Must Have, ask: 'What happens if this requirement is not met?'

9.1.10.3.1. If the answer is 'Cancel the project. There is no point in implementing a solution that does not meet this requirement', then it really is a Must Have. If not decide whether it is Should or a Could.

9.1.10.4. 4. Ask: 'If I come to you the night before deployment and tell you there is a problem with a Must Have requirement and that we can't deliver it - will you stop the deployment?'

9.1.10.4.1. If the answer is 'yes' then this is a Must Have requirement. If not decide whether it is Should or a Could.

9.1.10.5. 5. Is there a workaround, even if it is manual?

9.1.10.5.1. If there is, then it is not a Must Have requirement. Compare the cost of the workaround with the cost of delivering it, including the cost of any associated delays in determining whether it is a Should or a Could.

9.1.10.6. 6. Ask why is the requirement needed - for this project and this increment.

9.1.10.7. 7. If there is a Business Case in sufficient detail, can it be used to justify the intended priority?

9.1.10.7.1. If not, consider creating one.

9.1.10.8. 8. Is this requirement dependent on any others being fulfilled?

9.1.10.8.1. A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of it not being there.

9.1.10.9. 9. Allow different priorities for levels of acceptability of a requirement.

9.1.10.9.1. For example. 'The current back-up procedures will be followed to ensure that the service can be restored as quickly as possible.' How quick is that? Given enough time and money, that could be within seconds. They may say it Should happen within four hours, but it Must happen within 24 hours, for example.

9.1.10.10. 10. Can this requirement be decomposed? Is it necessary to deliver each of those components to fulfil the requirement? Are the decomposed elements of the same priority as each other?

9.1.10.11. 11. Tie the requirement to a project objective.

9.1.10.11.1. If the objective is not a Must Have, then probably neither is the requirement relating to it.

9.1.10.12. 12. Remember that team members may cause scope creep by working on the fun things rather than the important things. MoSCoW can help avoid this.

9.1.10.13. 13. Does the priority change with time?

9.1.10.13.1. For example, for an initial phase it is a Should Have but it will be a Must Have for the second increment.

9.1.10.14. 14. Prioritise defects / bugs, using MoSCoW.

9.1.10.15. 15. Prioritise testing, using MoSCoW.

9.1.10.16. 16. Use MoSCoW to prioritise your To Do list.

9.1.10.16.1. It can be used for activities as well as requirements.

9.1.11. Summary & Concusion

9.1.11.1. MoSCoW (Must Have, Should Have, Could Have, Won't Have this time) is primarily used to prioritise requirements, although the technique is also useful in many other areas.

9.1.11.2. DSDM® recommends no more than 60% effort for Must Haves for a project, with 40% Shoulds and Coulds.

9.1.11.2.1. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.

9.1.12. Watch: Master the art of MoSCoW prioritisation (by Keith Richards)

9.1.13. Watch: Agile in Practice: Prioritisation using MoSCoW

9.2. Daily Stand-Up

9.2.1. This is the Solution Development Team’s opportunity to share information with the whole team and to do any day-to-day re-planning and reorganising necessary when issues occur.

9.2.2. The Stand-Up usually takes place at the same time and same place each day (with the Timebox Plan visible), so that others who are not part of the SDT may listen in

9.2.3. Normally run by Team Leader, is opportunity to understand progress against objectives at detailed level and to expose issues and blockers that may be getting in the way.

9.2.3.1. Rather than writing reports and reading mails where text does not represents body language communication during F2F meetings

9.2.4. Recommended same time everyday at the same place

9.2.5. Often standing up at the Taskboard

9.2.6. Teleconference Stand-Ups (Dial-ins) may be necessary where the team is split across multiple sites.

9.2.7. Attended by all SDT members.

9.2.7.1. Possible to combine several SDTs on daily stand-up.

9.2.7.2. Has the following active participants:

9.2.7.2.1. all members of the SDT, including Business Ambassador(s)

9.2.7.2.2. any Business Advisors (BADV) actively involved in this Timebox

9.2.7.2.3. any Technical Advisors (TADV) actively involved in this Timebox

9.2.7.3. May be attended by other roles e.g.

9.2.7.3.1. The Business Visionary (BV) – in order to keep in touch with progress, to provide on-going visible support

9.2.7.3.2. The Project Manager (PM) – in order to observe progress and pick up escalated issues

9.2.7.3.3. The Technical Coordinator (TC) – in order to keep abreast of technical decisions and pick up escalated technical issues

9.2.8. Strict format

9.2.8.1. Each member describes what they’ve done since last standup.

9.2.8.1.1. Is ideally held with all participants standing in a circle by their team board

9.2.8.2. What they plan to do.

9.2.8.3. Any problems, Risks or Issues, slowing progress.

9.2.9. Short

9.2.9.1. No longer than 15 minutes (2 minutes per person).

9.2.9.2. 2 minutes per participant + 2 minutes is a good guide

9.2.10. GIFTS (goals of daily stand-ups)

9.2.10.1. Good Start

9.2.10.1.1. "Good standups are crisp and motivating. A lot of standups are bad. They have the enervating effect of an hour-plus weekly status meeting, only spread out over a week." Brian Marick, "Latour 3: Anthrax and standups"

9.2.10.1.2. Good Start means that the stand-up meeting should give energy, not take it.

9.2.10.1.3. Energy comes from instilling a sense of purpose and urgency; a clear sense of the purpose and a clear understanding what needs to be done to achieve it.

9.2.10.2. Improvement

9.2.10.2.1. "The purpose is not to meet... it is to improve." Joe Ely, "More on Daily Start-Up Meetings"

9.2.10.2.2. We can't fix problems we don't know about so a large part of stand-ups is about exposing problems to allow us to improve.

9.2.10.2.3. Improvement is not just about problem solving though.

9.2.10.2.4. Sharing better techniques and ideas is also important.

9.2.10.3. Focus

9.2.10.3.1. Focus on the baton, not the runners

9.2.10.3.2. The stand-up should encourage a focus on moving work through the system in order to achieve our objectives, not encourage pointless activity.

9.2.10.4. Team

9.2.10.4.1. Effective teams are built by regularly communicating, working, and helping each other.

9.2.10.4.2. This is also strongly tied with team members helping each other with shared obstacles.

9.2.10.4.3. The stand-up should be supporting the creation of an environment that encourages people to raise problems by constructing a narrative of other people helping when problems are raised.

9.2.10.5. Status

9.2.10.5.1. Status is about answering a couple questions:

9.3. Facilitated Workshops

9.3.1. Introduction

9.3.1.1. Facilitated Workshops are a specialised type of meeting, with a clear objective (product), a workshop owner, who needs the outcome of the workshop and is the driver for it to happen, a set of people (participants) who are chosen and empowered to produce the product and an independent person (facilitator) to enable the effective achievement of the objective.

9.3.1.2. Facilitated Workshops are a process in which a neutral facilitator, with no stake in the outcome of the workshop, enables a group to work together to achieve an agreed goal, whether that be solving a problem, building a plan, gathering requirements or making a decision.

9.3.1.3. Facilitated Workshops ensure a team-based approach to rich communication and collaboration and achieve results with speed and commitment and buy-in to the outcome.

9.3.1.4. Facilitated Workshops are an extremely efficient and effective way of achieving this enhanced communication.

9.3.2. Benefits

9.3.2.1. Rapid, high quality decision-making

9.3.2.1.1. Can reduce the elapsed time required to achieve objectives, such as the identification, agreement and sign-off of requirements.

9.3.2.2. Greater buy-in from all stakeholders

9.3.2.2.1. Lead to participants feeling more involved and committed to the end results due to having an opportunity to participate in, and contribute to.

9.3.2.3. Building team spirit

9.3.2.3.1. Output of the workshop benefits from the participants building on each other's ideas and gaining a better understanding of each other's viewpoints.

9.3.2.4. Building Consensus

9.3.2.4.1. Provides an opportunity for participants to discuss the relevant subject matter, including the major issues and problems, and reach a consensus on important.

9.3.2.5. Clarification of issues

9.3.2.5.1. Help to minimize ambiguities and misunderstandings, in the facilitated environment, participants can explore and model ideas, which in turn will simplify and accelerate the review and sign-off of the workshop deliverables.

9.3.3. CSFs for Facilitated Workshops

9.3.3.1. An effective, trained, independent Workshop Facilitator.

9.3.3.2. Workshop owner

9.3.3.2.1. Identify the workshop owner and ensure that they work with the facilitator to focus the workshop; Ensure time in the plans for preparation for the workshop in addition to the workshop itself

9.3.3.3. Flexibility in the format of different workshops, but clearly defined objectives.

9.3.3.3.1. Ensure that workshop participants are appropriately empowered

9.3.3.4. Thorough preparation before the workshop by Workshop Facilitator, Co-facilitator and Participants.

9.3.3.5. A mechanism for ensuring that the results of previous workshops are built in, where appropriate.

9.3.3.5.1. Keep metrics of the time taken to arrange, run and follow-up workshops and of the effectiveness of workshops in achieving their intended product

9.3.3.6. Decisions and agreements that are not forced.

9.3.3.6.1. If the workshop participants cannot agree on a point within the workshop (perhaps due to lack of information or time), the Workshop Facilitator should recognise this and elicit from the group the appropriate action to remedy the shortfall.

9.3.3.7. Participants receiving a workshop report, detailing decisions, actions and the product of the workshop, very soon after the workshop (ideally within 48 hours).

9.3.3.7.1. Monitor that workshop outputs are appropriately recorded and circulated.

9.3.4. Further reading (outside DSDM® exams scope)

9.3.4.1. see Facilitation (based on Process Iceberg®) mind map

9.3.4.2. Facilitation - An Art, Science, Skill or all three?: Build your expertise in Facilitation

9.3.4.2.1. ISBN-13: 978-0955643507

9.3.4.2.2. Pages: 235

9.3.4.2.3. http://resourceproductions.com/books

9.3.4.3. Facilitation - A Manual of Models, Tools and Techniques for Effective Group Working

9.3.4.3.1. ISBN-13: 978-0955643514

9.3.4.3.2. Pages: 269

9.3.4.3.3. http://resourceproductions.com/books

9.4. Timeboxing (a.k.a. Sprinting from Scrum)

9.4.1. Every Timebox begins with a Kick-Off and ends with a Close-Out. Beyond this, DSDM® recognises two styles of Timebox:-

9.4.1.1. Kick-Off

9.4.1.1.1. Short session for the Solution Development Team (SDT) to understand the Timebox objectives and accept them as realistic

9.4.1.1.2. Review the Timebox objectives, as outlined in the Delivery Plan

9.4.1.1.3. Ensure that it is still feasible within the Timebox to deliver what was initially expected at the Foundation phase (re-plan accordingly if this is no longer possible)

9.4.1.1.4. Review the availability of all members of the SDT

9.4.1.1.5. Highlight any known dependencies (internal or external) that may affect this Timebox.

9.4.1.1.6. Who

9.4.1.2. A DSDM® Structured Timebox

9.4.1.2.1. Comprises 3 main steps:

9.4.1.3. A Free Format Timebox

9.4.1.3.1. The Free Format Timebox reflects the style used by other popular Agile approaches

9.4.1.3.2. Comprises 1 step:

9.4.1.4. Close-Out

9.4.1.4.1. The primary aim of the Close-Out is to record formal sign-off or acceptance of all the products delivered from this Timebox.

9.4.1.4.2. An important secondary aim is to determine what is to be done about work that was initially part of the Timebox but was not completed.

9.4.1.4.3. Close-Out is followed by a short Timebox Retrospective Workshop, to learn from the Timebox and to take actions to improve future Timeboxes.

9.4.1.4.4. Who

9.4.1.5. Depending on the time needed for the Close-Out, it may be practical and sensible to run the Close-Out back-to-back with the Kick-Off session for the next Timebox

9.4.2. Summary & Comclusion

9.4.2.1. Timeboxing is one of DSDM®'s key Practices and is used in combination with the Practice of MoSCoW prioritisation to ensure on-time delivery.

9.4.2.2. At the lowest level, the Development Timebox maintains focus on delivery in the short term (weeks or even days).

9.4.2.3. If Development Timeboxes are delivering at least the Must Haves on time every time, then the estimating process is working, the team is working, the Delivery Plan is being validated and the risks should be reducing.

9.4.2.3.1. This low-level confidence feeds upwards to instil confidence at the increment and the project levels.

9.5. Iterative Development

9.5.1. Iterative Development is one of DSDM®'s key techniques.

9.5.1.1. It allows the high-level requirements established during Foundations phase to be explored and evolved in more detail during Development Timeboxes of Exploration and Engineering.

9.5.1.2. It ensures that the cycles of iteration in the Development Timeboxes are controlled, and that a feedback loop is build into the way of working within these Timeboxes.

9.5.2. Iterative Development cycles are typically 1 - 2 days.

9.5.3. It enables a growing understanding of the requirement and convergence on an accurate solution.

9.5.4. Focus

9.5.4.1. Requirement focus

9.5.4.1.1. Functional

9.5.4.1.2. Usability

9.5.4.1.3. Non-functional

9.5.4.2. Solution / Development focus

9.5.4.2.1. Horizontal

9.5.4.2.2. Vertical

9.5.4.2.3. Combined

9.6. Modelling

9.6.1. Modelling and Prototyping are closely linked cocepts.

9.6.1.1. A prototype is always a kind of a model.

9.6.1.1.1. In IT, prototype often refers to a funstional software but in ALPHA / BETA stage or some wireframing model

9.6.1.2. A model is not a necessary a prototype.

9.6.1.2.1. In IT, model often refers to a set of diagrams (but not a part of functional software)

9.6.2. A model is:

9.6.2.1. A simplified view of a complex reality or concept.

9.6.2.2. A description or analogy (to help visualise something that cannot be directly observed).

9.6.2.3. A small but exact copy of something.

9.6.2.4. A pattern or figure of something to be made.

9.6.2.5. Examples:

9.6.2.5.1. Storyboards

9.6.2.5.2. Storyboards

9.6.2.5.3. Flowcharts

9.6.2.5.4. Swim-lane diagrams

9.6.2.5.5. Process-models

9.6.2.5.6. UML / SysML diagrams (IT)

9.6.2.5.7. Archimate diagrams (IT)

9.6.2.5.8. OBASHI Business & IT (B&IT) diagrams

9.6.2.5.9. OBASHI Dataflow Analysis View (DAVs) diagrams

9.6.3. Models should help in determining (Viewpoints for Modelling):

9.6.3.1. Why

9.6.3.1.1. Rationale, ends and means

9.6.3.2. Where

9.6.3.2.1. Locations and Links

9.6.3.3. Who

9.6.3.3.1. People, Tasks & Responsibilities

9.6.3.4. What

9.6.3.4.1. Business procedures (Data & Relationships)

9.6.3.5. When

9.6.3.5.1. Business events, time & scheduling

9.6.3.6. How

9.6.3.6.1. Processes & Outputs

9.6.4. Modelling

9.6.4.1. Many industries benefit from the use of models, prototypes and mock-ups to establish requirements, confirm expectations and test the achievability of objectives.

9.6.4.1.1. Significant benefits in making ideas, situations and options visible.

9.6.4.2. Modelling can range from very informal models (post-it notes on a table) to very detailed, complex models using specific notations.

9.6.4.3. These can be as different as a storyboard to represent an advertisement or a scale model of a proposed hospital.

9.6.4.4. They can be temporary, transient or throwaway or may be a prototype which forms a part of the eventual solution.

9.6.4.5. AgilePM® advocates the use of models to improve communication and to create or challenge ideas by making developing products visible.

9.6.4.5.1. Emphasis on ensuring models enhance communication.

9.6.4.5.2. AgilePM® advocates clear and continuous communication, using rich communication techniques, of which the development of models and prototypes is a key element

9.6.5. Using models for the AgilePM® products

9.6.5.1. The AgilePM® framework has identified a number of products that may need to be generated by the end of each phase of the lifecycle.

9.6.5.1.1. Of necessity, these products are a combination of technical information, project objectives and constraints.

9.6.5.2. Models and prototypes will help to analyse and present some of the required technical information in manageable increments and to test the developing product.

9.7. Prototyping

9.7.1. Prototyping is one of the many ways by which AgilePM® ensures effective communication between stakeholders, whether from different parts of the business, different organisations or sometimes different cultures, languages and / or countries.

9.7.2. A prototype is something that serves to illustrate the typical qualities of the eventual solution

9.7.2.1. It may evolve into eventual solution (an evolutionary prototype) or may always be intended to be an experimental model (a disposable prototype)

9.7.3. A prototype in AgilePM® is a piece of work that demonstrates how a given objective can be or has been achieved

9.7.4. Disposable prototypes

9.7.4.1. Example is an IT-based solution such as Architectural Spike, a.k.a. Proof of Concept prototype, which is a thin, end-to-end mock-up of the pathway through a solution

9.7.4.1.1. DSDM® calls these Capability/Techniques prototypes

9.7.5. Evolutionary prototype

9.7.5.1. All Iterative Development on a particular deliverable, carried out in accordance with the Iterative Development cycle, can be considered to be prototyping, because elements are constantly being build, shown, modified and revisited.

9.7.5.1.1. Iterative Development technique is sometimes referred to as Prototyping

9.8. Other techniques used in Agile (not defined in DSDM® method, but can be easily implemented)

9.8.1. 10 Intristic Motivators

9.8.2. Burn-Down Chart

9.8.3. Burn-Up Chart

9.8.3.1. Watch: Agile in Practice: Burn_Up Charts

9.8.4. CHAMPFROGS

9.8.5. Circle

9.8.6. Circles of Concern and Influence

9.8.7. Facilitated Workshops

9.8.8. Feature Progress Report

9.8.9. Five dysfunctions of a team

9.8.10. Future Backwards

9.8.11. Hapiness Metric

9.8.12. Kanban wall

9.8.13. Mad, Sad, Glad

9.8.14. Perfection Game

9.8.15. Personas

9.8.16. Planning Poker

9.8.17. Predictability Measure

9.8.18. Problem -> Goal -> Advantage

9.8.19. Product / Release Burndown Chart

9.8.20. Relative Weighting

9.8.21. Run your ass off

9.8.22. Speed dating

9.8.23. Sprinting / Timeboxing

9.8.24. Starfish

9.8.25. The Sailboat

9.8.26. Theme Scoring

9.8.27. Theme Screening

9.8.28. Timeline / Emotion Graph

9.8.29. Value vs Effort Matrix

9.8.30. ...

9.9. http://retrospectivewiki.org/

9.10. http://tastycupcakes.org/

9.11. http://www.funretrospectives.com/

10. DSDM® Instrumental Success Factors (ISFs) (5)

10.1. When these factors are not met, they represent a significant risk to DSDM® approach.

10.1.1. It is important to identify these risks early and consider hot they could be mitigated.

10.2. 1. Embracing the DSDM® Approach

10.2.1. In order for DSDM® projects to be successful, project stakeholders and participants understand and accept the DSDM® project approach.

10.2.2. Best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.

10.3. 2. Effective Solution Development Team (SDT)

10.3.1. In order for DSDM® projects to be successful, it has to be recognized that people are at the heart of successful projects.

10.3.1.1. Solution Development Team is instrumental in ensuring the development of the right solution.

10.3.2. Building an effective team for successful delivery focuses on 4 elements:

10.3.2.1. Empowerment

10.3.2.1.1. Teams are empowerment to make decisions based on their expertise and team as a whole empowered to make decisions within the boundaries agreed during Foundation phase.

10.3.2.1.2. Business Sponsor and Visionary must agree to delegate day-to-day decision-making to Business Ambassador(s).

10.3.2.1.3. Without business empowerment team progress will slow down.

10.3.2.2. Stability

10.3.2.2.1. Solution Development Team brings together business and technical knowledge through the iterative development process.

10.3.2.2.2. Solution is a evolving product, it evolves dynamically and this places great emphasis on conversations between team members, rather than relying on documents (as a primary source and focus of communication).

10.3.2.3. Skills

10.3.2.3.1. Solution Development Teams are contains skilled people, both in terms of business knowledge and technical expertise.

10.3.2.3.2. Team should also have a good communication skills and the willingness to work with others.

10.3.2.4. Size

10.3.2.4.1. DSDM suggests that the optimum Solution Development Team size is 7 +/- 2 people.

10.3.2.4.2. With such small teams, teams can communicate with one another with:

10.3.2.4.3. Bigger or smaller teams of course are possible but they can introduce risks

10.4. 3. Business Engagement - Active and On-going

10.4.1. In order for DSDM® projects to be successful, it is vital that the business is actively engaged and commits to necessary amount of time at all levels, and that commitment is maintained through the project.

10.4.2. Ensuring active and on-going business engagement relies on 3 elements:

10.4.2.1. Commitment of business time throught

10.4.2.2. Day-to-Day collaboration involving business roles in the Iterative Development process

10.4.2.3. A supportive commercial (e.g. contractual) relationship (where appropriate)

10.5. 4. Iterative Development, Integrated Testing and Incremental Delivery

10.5.1. In order for DSDM® projects to be successful, testing has to be fully embedded as part of the iterative and incremental development approach is key both to reduction of project risk and to the success of the project,.

10.5.2. It has to be ensured that individual elements of the solution are technically fit for purpose and meet the business need, builds confidence in the direction and the quality of the Evolving Solution.

10.6. 5. Transparency

10.6.1. In order for DSDM® projects to be successful, building confidence is a key aspect of DSDM® projects.

10.6.1.1. DSDM® is all about building confidence in the Evolving Solution, and in this way reducing the risks of the unknown or the invisible.

10.6.2. Demonstrations of the Evolving Solution provide physical, objective and unquestionable proof of progress (compared with a progress report showing a subjective % complete).

10.6.3. "The great thing about fact-based decisions is that they can overrule the hierarchy." - Jeff Bezos, Amazon.com

10.6.4. "Transaprency is neither good or bad. Things and increments just are. They may not be what you want, but that means hard decisions are required. You have to have a firm grasp of the real facts to make solid decision.." - K. Schwaber, J. Sutherland

10.7. The Project Approach Questionnaire (PAQ) - Assessing Options and Risks

10.7.1. In order to set projects up front the best chance of success, it is important to take a realistic look at the working environment.

10.7.2. PAQ is a simple checklist assesses a number of key areas for DSDM® success, and start to identify potential risks to DSDM® success which need to be addressed.

10.7.3. PAQ is completed by Project Manager.

10.7.4. Download: DSDM® Project Approach Questionnaire (PAQ) (XLS)

11. DSDM® Process (1) with Phases (6)

11.1. Overview

11.1.1. In line with the 5 and 6 principles, the DSDM® lifecycle is both iterative and incremental.

11.1.1.1. Each phase has objectives and pre-conditions.

11.1.1.2. This configurability of DSDM® Lifecycle allows the project manager significant opportunity to deliver business value early and to demonstrate progress. The framework is highly configurable, depending on the size and formality of the project being delivered.

11.1.1.2.1. It is sequential for Pre-project, Feasibility and Foundations.

11.1.1.2.2. Can have many iterations of Evolutionary Development.

11.1.1.2.3. Can have many separate Deployments in one project!

11.1.1.2.4. Post Project will be sequential with the last Deployment.

11.1.1.3. Solution may not be delivered to the business in one go, but in a series of increments that increase the breadth and/or depth of the solution with each delivery.

11.1.1.3.1. Urgent business needs can be addressed early while less important features are delivered later.

11.1.1.4. Iterative nature of DSDM® enables business representatives to see work under construction, comment on it and request changes during the development of an increment of the solution.

11.1.1.5. Each lifecycle phase will deliver Products and, within DSDM®, delivery of Products (to the appropriate and agreed level of quality) is used to assess progress.

11.1.1.6. It is important to keep the phases of the lifecycle visible to the SDT during the project.

11.1.1.7. Typically, plan for Feasibility and Foundations phases to be shorter than would be the case for a traditional one-delivery project. Allow for just Enough Design Up Front (EDUF).

11.1.1.8. Project phases are 'building blocks' from which you are building project lifecycle. It is a framework.

11.2. DSDM® provides an iterative, incremental and adaptive framework, with 6 lifecycle phases.

11.2.1. DSDM® Project Lifecycle Phases with requirements

11.2.2. DSDM® Iterative development

11.2.3. DSDM® Project Lifecycle Phases with OGC Gated Reviews

11.2.3.1. 1. Permission to investigate an idea

11.2.3.2. 2. Permission to build a Business Case

11.2.3.3. 3. Business Case approval - go ahead

11.2.3.4. 4. Permission to test deliverables

11.2.3.5. 5. Permission to deliver

11.2.3.6. 6. Project closure

11.2.3.7. Business Case reviewed at every gate 5.

11.3. The DSDM® process model comprises a framework which shows the DSDM® phases and how they relate to one another

11.4. The process have 6 phases:

11.4.1. Pre-Project

11.4.1.1. Introduction

11.4.1.1.1. The work of the Pre-Project phase simply formalises a proposal for a project and places it in the context of other potential work to be, or already being, carried out by the organisation.

11.4.1.1.2. In most corporate environments projects exist as part of a portfolio of other projects and sometimes exist as part of a programme of projects with a shared business change objective.

11.4.1.2. Objectives

11.4.1.2.1. To describe the business problem to be addressed.

11.4.1.2.2. To identify a Business Sponsor (BS) and Business Visionary (BV).

11.4.1.2.3. To confirm that the project is in line with business vision, mission, strategy, corporate investment porfolio.

11.4.1.2.4. To scope, plan and resource the Feasibility phase (only Feasibility phase NOT the whole project).

11.4.1.2.5. To formulate a proposal for a project and priorities it in the context of other work being carried out by the organisation in line with its strategic goals.

11.4.1.3. Consider

11.4.1.3.1. The intended work of the Pre-Project phase should be short, sharp and ideally restricted to the creation of a short statement that has the purpose of justifying and prioritising a Feasibility investigation.

11.4.1.4. In real life corporate environments this phase is often called Project Kick-off

11.4.2. Feasibility

11.4.2.1. Introduction

11.4.2.1.1. Project management best practice dictates that the viability of the project should be continually assessed throughout the project, ensuring that the benefits predicted from the use of end products of the project outweigh the costs of delivering them.

11.4.2.1.2. The Feasibility phase provides the first opportunity for deciding whether a proposed project is viable from both a business (Business Sponsor (BS) and Visionary (BV)) and a technical (Technical Coordinator (TC)) perspective by means of a high level investigation of the potential solutions, costs and timeframes.

11.4.2.2. Preconditions

11.4.2.2.1. The Terms of Reference (ToR) for the project have been approved.

11.4.2.2.2. The required resources are available to carry out the feasibility investigation.

11.4.2.2.3. The Business Visionary (BV) has sufficient time available to help shape the project.

11.4.2.3. Objectives

11.4.2.3.1. To establish whether there is a feasible solution to the business problem described in the Terms of Reference (ToR) defined during Pre-Project.

11.4.2.3.2. To identify the benefits likely to arise from the delivery of the proposed solution.

11.4.2.3.3. To outline possible approaches for delivery, including strategies for sourcing the solution and project management.

11.4.2.3.4. To describe the organisation and governance aspects of the project.

11.4.2.3.5. To state first-cut estimate of timescale and costs for the project overall.

11.4.2.3.6. To plan and resource the Foundation phase.

11.4.2.4. Consider

11.4.2.4.1. If you are going to stop work on a project then it is important that you stop as early as possible.

11.4.2.4.2. The effort associated with Feasibility should be just enough to decide whether further investigation is justified, or whether the project should be stopped now, as it is unlikely to be viable.

11.4.2.4.3. The Feasibility phase should be kept as short and sharp as possible, remembering that its only purpose is to justify progressing to the Foundations phase.

11.4.3. Foundations

11.4.3.1. Introduction

11.4.3.1.1. The Foundations phase is aimed at establishing firm and enduring foundations for the project.

11.4.3.1.2. It is intended to establish a fundamental (but not detailed) understanding of the business rationale for the project, the potential solution that will be created by the project, and how development and deliver y of the solution will be managed.

11.4.3.1.3. To create solid foundations, it is vital that detail, particularly around the solution, is strictly limited so that it does not unnecessarily constrain the way the solution evolves but still clearly demonstrates how it will meet the needs of the business.

11.4.3.2. Preconditions

11.4.3.2.1. agreement of the Feasibility Assessment (if created)

11.4.3.3. Objectives

11.4.3.3.1. To baseline the high-level requirements for the project and describe their priority and relevance to the business need

11.4.3.3.2. To describe the business processes to be supported by the proposed solution

11.4.3.3.3. To identify information used, created and updated by the proposed solution

11.4.3.3.4. To describe the strategies for all aspects of solution deployment

11.4.3.3.5. To detail the Business Case for the project

11.4.3.3.6. To start designing the solution architecture and identifying the physical or infrastructural elements of solution

11.4.3.3.7. To define technical implementation standards

11.4.3.3.8. To decribe how quality will be assured

11.4.3.3.9. To establish appropriate governance and organisation for the project

11.4.3.3.10. To describe the solution development lifecycle for the project along with techniques to be applied in managing the project and for demonstrating and communicating progress

11.4.3.3.11. To baseline a schedule for development and deployment activities for the solution

11.4.3.3.12. To describe, assess and manage risk associated with the project

11.4.3.4. Consider

11.4.3.4.1. Significant business input will be required during the Foundations phase.

11.4.3.4.2. Set a time limit for the Foundations phase and try to stick to it.

11.4.3.4.3. The aim of this phase is to create a high-level but sound view of the business and technical aspects of the project.

11.4.3.4.4. For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase

11.4.3.5. It may sometimes be necessary to revisit Foundations after a Deployment phase.

11.4.3.5.1. The decision to revisit Foundations may be planned in from the star t of the project; for example, on a project where the business environment is sufficiently dynamic that the Foundations are expected to encounter significant change during the life of the project.

11.4.3.5.2. Alternatively, the decision to revisit Foundations may be taken after a Deployment has produced an unexpected outcome.

11.4.3.6. The Foundations phase also determines the project lifecycle by agreeing how the DSDM process will be applied to the specific needs of this project.

11.4.3.7. In case of smaller projects sometimes known as Sprint 0 in Scrum.

11.4.4. Evolutionary Development

11.4.4.1. Preconditions (for moving out of Foundations)

11.4.4.1.1. The Business, Solution and Management Foundations products have ben collectively accepted as provide an adequate foundation from which a solution can evolve

11.4.4.1.2. The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution

11.4.4.1.3. All required project personnel and stakeholders are engaged as necessary

11.4.4.2. The Evolutionary Development phase requires the Solution Development Team(s) to apply practices such as Iterative Development, timeboxing, and MoSCoW prioritisation, together with Modelling and Facilitated Workshops, to converge over time on an accurate solution that meets the business need and is also built in the right way from a technical viewpoint.

11.4.4.3. Working within Timeboxes, the Solution Development Team create Solution Increments, iteratively exploring the low-level detail of the requirements and testing continuously as they move forward.

11.4.5. Deployment

11.4.5.1. Introduction

11.4.5.1.1. The primary purpose of the Deployment phase is to get the solution into live use.

11.4.5.1.2. A secondary purpose is to act as a key review point prior to Deployment or future development work.

11.4.5.1.3. The number of passes through the Deployment phase will depend on whether it is sensible and feasible for the business to accept delivery of the overall solution incrementally.

11.4.5.2. Preconditions

11.4.5.2.1. The Deployable Solution has been approved for deployment

11.4.5.3. Objectives

11.4.5.3.1. A final ‘assembly point’ for the solution - bringing together the business and technical aspects of the change and, where applicable, the potentially shippable product increment outputs of multiple teams

11.4.5.3.2. A final check point for the integrity of the overall solution - which may include final testing in a controlled production-like environment (not a traditional UAT)

11.4.5.3.3. To confirm the ongoing performence and viability of the project and re-plan as required

11.4.5.3.4. To deploy the solution (or increment of it) into the live business environment

11.4.5.3.5. Training of end users and support staff

11.4.5.3.6. To assess whether the deployed solution is likely to enable the delivery of intended elements of business benefit described in the Business Case (where created)

11.4.5.3.7. An opportunity for retrospection - similar to a Sprint retrospective - but for a Release

11.4.5.3.8. A good deployment is:

11.4.5.3.9. After the final deployment:

11.4.5.4. Consider

11.4.5.4.1. If the solution is being deployed incrementally, it is usually appropriate to formally assess whether the project should continue after each interim deployment.

11.4.5.4.2. It therefore makes sense to check that investment in the rest of the planned project will provide a reasonable return.

11.4.5.4.3. Justification to continue is likely to reflect the cost of operating the solution as it stands against the cost of operating a more complete solution.

11.4.5.5. The release that is deployed may be the final solution, or a subset of the final solution.

11.4.5.6. Assemble

11.4.5.6.1. This requires the consolidation of all artefacts deemed relevant for the deployment of the solution. For example, the deployment of a business process may require a new software package, documentation for users and a communication to all stakeholders.

11.4.5.7. Review

11.4.5.7.1. This is essentially a quality gate that requires approval of the correctness and completeness of the assembled assets and offers an appropriate point for reflection on the project increment. Most organisations institutionalise such measures as checklists or more formal approval boards.

11.4.5.8. Deploy

11.4.5.8.1. This step concerns the actual act of transition of assets into operational use. For example this might entail installation and configuration of a software package, training of users and release of a communication.

11.4.6. Post-Project

11.4.6.1. Introduction

11.4.6.1.1. The Post-Project phase takes place after the last planned deployment of the solution. Its purpose is to reflect on the performance of the project in terms of the business value actually achieved.

11.4.6.2. Preconditions

11.4.6.2.1. The solution has been successfully deployed.

11.4.6.2.2. After the final Deployment for a project, the Post-Project phase checks how well the expected business benefits have been met.

11.4.6.3. Objectives

11.4.6.3.1. To assess whether the benefits described in the Business Case (where created) have actually been achieved through use of the Deployed Solution

11.4.6.3.2. Mostly, the project will have been closed prior to the start of the Post-Project phase.

11.4.6.3.3. In some projects where the overall solution is delivered incrementally, it is often appropriate to start the benefits realisation process before the final deployment.

11.4.6.3.4. The Business Sponsor (BS) and Business Visionary (BV) have an ongoing responsibility for ensuring that the benefits enabled by the project are actually realised through proper use of the solution provided.

11.4.6.4. The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case.

11.4.6.4.1. Benefits may be assessed for individual releases (in which case the assessment of benefit should star t before the Post-Project phase is reached), for the whole project or may be omitted completely, depending on the needs of the organisation.

11.5. DSDM® project lifecycle examples

11.6. Summary & Conclusion

11.6.1. DSDM® provides an iterative and incremental framework, with 6 lifecycle phases

11.6.2. Each phase has objectives and pre-conditions

11.6.3. Specifically, each lifecycle phase will deliver Products

11.6.4. The acceptance of products enables agreement that the project can move safely from one lifecycle phase to another

11.6.5. The framework is highly configurable, depending on the size and formality of the project being delivered

12. People, Teams and Interactions

13. Requirements and User Stories

14. This freeware, non-commercial mind map (aligned with the newest version of DSDM® AgilePF ) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the DSDM® AgilePF® method and as a learning tool for candidates wanting to gain DSDM® AgilePF® qualification. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

14.1. Questions / issues / errors? What do you think about my work? Your comments are highly appreciated. Feel free to visit my website: www.miroslawdabrowski.com

14.1.1. http://www.miroslawdabrowski.com

14.1.2. http://www.linkedin.com/in/miroslawdabrowski

14.1.3. https://www.google.com/+MiroslawDabrowski

14.1.4. https://play.spotify.com/user/miroslawdabrowski/

14.1.5. https://twitter.com/mirodabrowski

14.1.6. miroslaw_dabrowski

15. DSDM® AgilePF® method (6th version / 2014) consists of: 1 Philosophy, 8 Principles, 5 Instrumental Success Factors (ISFs), 1 Process (having 6 Phases), 13 Roles, 14 Management Products (a.k.a. documentation), 7 Techniques.

15.1. Download: DSDM® v6 - Project Health Check Questionnaire (PHCQ) (XLSX)

15.2. Download: DSDM® free assets

16. DSDM® Official publications

16.1. The DSDM® Agile Project Framework Handbook

16.1.1. ISBN-13: 978-0954483296

16.1.2. http://dsdm.org/product/dsdm-agile-project-framework-handbook

16.1.3. Pages: 176

16.1.4. The DSDM® Agile Project Framework Handbook is available online for FREE.

16.1.4.1. http://dsdm.org/dig-deeper/book/dsdm-agile-project-framework

16.2. Previous, 5th version was called DSDM® Atern®

16.2.1. DSDM® Atern® The Handbook

16.2.1.1. ISBN-13: 978-0954482220

16.2.1.2. ISBN-10: 0954482220

16.2.1.3. http://dsdm.org/product/dsdm-atern-handbook

16.2.1.4. Pages: 201

16.2.1.5. DSDM® Atern® The Handbook is available online for FREE.

16.2.1.5.1. http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook

16.2.2. The portmanteau Atern, is derived from the "Artic Tern" - a collaborative bird[citation needed] that can travel vast distances, whose characteristics reflect agile behaviour

17. Watch: Global Alignment: PRINCE2®:2009 & DSDM® (by Keith Richards) - video is based on previous version of DSDM® v5, yet it is still up to date in case of DSDM® v6

18. Watch: The Power of DSDM®! (by Keith Richards) - video is based on previous version of DSDM® v5, yet it is still up to date in case of DSDM® v6

19. Interactive DSDM® v6 Glossary

19.1. Interactive DSDM® v6 Glossary

20. Watch: What is DSDM®

21. Watch: How Does DSDM® Work