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. 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!)
3.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
3.1.1. http://www.miroslawdabrowski.com
3.1.2. http://www.linkedin.com/in/miroslawdabrowski
3.1.3. https://www.google.com/+MiroslawDabrowski
3.1.4. https://play.spotify.com/user/miroslawdabrowski/
3.1.5. https://twitter.com/mirodabrowski
3.1.6. miroslaw_dabrowski
4. 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.
4.1. Download: DSDM® v6 - Project Health Check Questionnaire (PHCQ) (XLSX)
4.2. Download: DSDM® free assets
5. DSDM® Official publications
5.1. The DSDM® Agile Project Framework Handbook
5.1.1. ISBN-13: 978-0954483296
5.1.2. http://dsdm.org/product/dsdm-agile-project-framework-handbook
5.1.3. Pages: 176
5.1.4. The DSDM® Agile Project Framework Handbook is available online for FREE.
5.1.4.1. http://dsdm.org/dig-deeper/book/dsdm-agile-project-framework
5.2. Previous, 5th version was called DSDM® Atern®
5.2.1. DSDM® Atern® The Handbook
5.2.1.1. ISBN-13: 978-0954482220
5.2.1.2. ISBN-10: 0954482220
5.2.1.3. http://dsdm.org/product/dsdm-atern-handbook
5.2.1.4. Pages: 201
5.2.1.5. DSDM® Atern® The Handbook is available online for FREE.
5.2.1.5.1. http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook
5.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
6. 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
7. 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
8. Watch: What is DSDM®
9. Watch: How Does DSDM® Work
10. DSDM® Fundamentals
10.1. What is DSDM®?
10.1.1. DSDM® project delivery framework and methodology that delivers the right solution at the right time.
10.1.2. An iterative, incremental and adaptive project management methodology.
10.1.2.1. Less sequential.
10.1.2.2. Different style than waterfall (no better or worst - just different).
10.1.3. DSDM® method was created in 1994.
10.1.4. DSDM® is a framework rather than a method.
10.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.
10.1.5. DSDM® integrates:
10.1.5.1. project management lifecycle
10.1.5.1.1. e.g. PRINCE2®, PMBOK5®
10.1.5.2. product development lifecycle
10.1.5.2.1. e.g. Scrum, FDD, TDD
10.1.5.3. which means that DSDM® can bee seen as a hybrid methodology
10.1.6. Right business solution is delivered because
10.1.6.1. The project team and other significant stakeholders remain focused on the business outcome.
10.1.6.2. Delivery is on time ensuring an early return on investment (ROI).
10.1.6.2.1. On time due to short time interval of Timeboxes
10.1.6.3. All people involved with the project work collaboratively to deliver the optimum solution.
10.1.6.3.1. Even lowest level them members like SDTs (developers, testers, graphics designers etc.)
10.1.6.4. Work is prioritised according to business need and the ability of users to accomodate changes in the agreed timescale.
10.1.6.5. DSDM® does not compromise on quality, i.e. the solution is not over- or under-engineered.
10.1.6.5.1. Solution is fit for purpose
10.1.7. DSDM® agility
10.1.7.1. Avoids cumbersone rigidity of "Big Design Up Front (BDUF)" with the inevitable risks of "no design" up front.
10.1.7.2. DSDM® advocates that projects should do just "Enough Design Up Front (EDUF)".
10.1.8. DSDM® flexibility
10.1.8.1. DSDM® can be used to complement other project management disciplines (PRINCE2®, PMBOK® Guide).
10.1.8.2. DSDM® can also incorporate other agile delivery approches (development techniques) such as eXtreme Programming (XP) and SCRUM.
10.2. How DSDM® addresses key project problems?
10.2.1. Ineffective communication
10.2.1.1. Poor communication is highlighted time after time as a major failing on projects.
10.2.1.2. How DSDM® helps?
10.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.
10.2.2. Late Delivery
10.2.2.1. Slippage of the completion date causes much frustration, as well as causing significant knock-on effects for a business.
10.2.2.2. How DSDM® helps?
10.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.
10.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.
10.2.3. The delivered solution does not meet the business needs (not just requirements)
10.2.3.1. Frustration is that when the solution is delivered, it doesn't meet the expectations of the business.
10.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.
10.2.3.2. How DSDM® helps?
10.2.3.2.1. In DSDM®, getting the correct understanding of the needs of the business is of paramount importance.
10.2.3.2.2. DSDM® encompasses practices which encourage collaboration and enable visual and verbal communication.
10.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.
10.2.4. Building the right thing - the business changing their mind
10.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.
10.2.4.1.1. In line with principle 1 - Focus on the business need.
10.2.4.2. How DSDM® helps?
10.2.4.2.1. DSDM® capitalises on the greater depth of understanding and so ensures that the Deployed Solution meets the true business need.
10.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.
10.2.5. Unused Features
10.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.
10.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.
10.2.5.2. How DSDM® helps?
10.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.
10.2.6. Over-engineering ("Gold plating")
10.2.6.1. There is normally a diminishing return (on value) when trying to make a deliverable 'perfect'.
10.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.
10.2.6.2. How DSDM® helps?
10.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.
10.2.7. Delayed or late Return on Investment (ROI)
10.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.
10.2.7.2. How DSDM® helps?
10.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.
10.2.8. "Fragile" Agile
10.2.8.1. Many organisations have adopted Agile behaviours and approaches but have done so in a very casual and disorganized manner.
10.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.
10.2.8.2. How DSDM® helps?
10.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.
10.2.9. Waterfall dressed up as Agile
10.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.
10.2.9.2. How DSDM® helps?
10.2.9.2.1. DSDM does just enough work up front to ensure clarity of objectives and to provide a foundation for solution development.
10.2.9.2.2. Active engagement of business roles in the detail of development ensures the right solution evolves.
10.3. Why using DSDM®?
10.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
10.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
10.3.3. DSDM® may also be used to supplement an existing in-house Agile approach, where this has proved to be lacking.
10.3.3.1. DSDM® is often used to provide the full "project" focus to complement Scrum's team focused product development process.
10.3.4. DSDM® takes pragmatic approach, recognising that is often needs to work alongside existing standards and approaches.
10.3.4.1. e.g. PRINCE2®, ITIL®, ISO, CMMI, PMO
10.3.5. Vendor-independent.
10.3.6. Independent of tools and techniques,
10.3.7. Higly scalable - for small and big projects.
10.3.8. Recognises that more projects fail because of people issues than technology,
10.3.9. Fundamental assumption of the DSDM® approach is that nothing is built perfectly first time
10.3.9.1. DSDM® team will constantly search for for better style of working.
10.3.10. DSDM® is a convergent approach, ensuring that basic foundations for the project are agreed at an early stage
10.3.11. Current step need be completed only enough to move to the next step, since it can be finished in a later iteration.
10.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.
10.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.
10.3.13. Solutions built using the DSDM® approach address the current and imminent needs of the business.
10.3.14. DSDM® is not only about developing new solutions.
10.3.14.1. Enhancements to existing solutions can be created using DSDM®.
10.3.15. Management
10.3.15.1. Management chooses DSDM® because it promises (and delivers) projects on time and on budget.
10.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.
10.3.15.2. Track record of On Time and In Budget delivery
10.3.15.3. “Corporate strength” agile
10.3.15.4. Highlights failing projects early
10.3.15.5. Provides a common language
10.3.16. Project Manager
10.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.
10.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.
10.3.16.2. Objectives-based
10.3.16.3. Clearly defined process with regular review points
10.3.16.4. Provides a common language
10.3.16.5. Effective planning
10.3.16.6. Appropriate formality
10.3.17. Business & Users
10.3.17.1. The users choose DSDM® because is allows them to control development while it is happening.
10.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.
10.3.17.2. Ownership of solution
10.3.17.3. Ability to drive direction of project for optimum business benefit
10.3.17.4. Delivery of a working solution on time, every time
10.3.17.5. Provides a common language
10.3.18. Developers
10.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.
10.3.18.1.1. This means wider responsibility, growth opportunities and a more rewarding job.
10.3.18.2. Responsibility
10.3.18.3. Growth opportunities
10.3.18.4. User involvement
10.3.18.5. Provides a common language
10.4. DSDM® vs Traditional Project Variables
10.4.1. Project Variables - Traditional and DSDM®.
10.4.1.1. Deliver on time.
10.4.1.2. Deliver on budget.
10.4.1.3. Guarantee to meet quality standards.
10.4.1.4. Focus on what business sees as important (not everything is important).
10.4.1.4.1. Agile projects will not necessarily deliver the full scope!
10.4.1.4.2. DSDM® is about delivering 80% functionality in 20% time.
10.4.2. DSDM® fixes Time, Cost and Quality at the early phases of a project.
10.4.2.1. Time is fixed e.g. due to short timescale of Timeboxes
10.4.3. According to DSDM®, most projects have four parameters - time, cost, features and quality.
10.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.
10.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.
10.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.
10.4.7. Quality is fixed in an DSDM® project because acceptance criteria are agreed and set before development commences
10.4.7.1. Each Timebox in DSDM® has the same level of quality set at the beginning.
10.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.
10.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.
10.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.
10.4.9. Deliver at the right time
10.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.
10.4.10. Delivering the right solution
10.4.10.1. The people team and other significant stakeholders remain focused on the business needs
10.4.10.2. All people involved with the project work collaboratively to achieve that outcome
10.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
10.4.10.4. A limited amount of early work ensures firm foundations to support the solution as it grows
10.4.10.5. Work is prioritised according to business need and the ability of the business to accommodate changes in the agreed timescale
10.4.10.6. An iterative and incremental approach to development and delivery of the solution assures alignment with business need
10.4.10.7. Quality is never allowed to become a variable
10.5. DSDM® rigour
10.5.1. Too much formality can slow progress down and even cause paralysis.
10.5.2. Too little formality can lead to a seat-of-the-pants approach.
10.5.3. DSDM® should be tailored to suit a project's individual needs within the organisation's governance needs.
10.5.4. The aim is to have adequate formality, so that waste is eliminated and all activities at each incremental level add value.
10.5.5. DSDM® project ensures that formality and rigour are there to help rather than hinder progress.
10.6. Download: Traditional vs DSDM® project variables (PDF)
11. Agile fundamentals (agile in general not DSDM® fundamentals)
11.1. Agile Manifesto
11.1.1. http://agilemanifesto.org/
11.1.2. 17 It industry veterans met at Snowbird Resort on February 11-13 2001 and created Agile Manifesto
11.1.2.1. Introduced 4 Values and 12 Principles defining Agile for Software Development
11.1.3. disciplines that gave rise to the Agile Manifesto
11.1.3.1. Extreme Programming, SCRUM, Dynamic Systems Development Method (DSDM), Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming.
11.2. Agile Alliance
11.2.1. http://www.agilealliance.org/
11.3. Agile currently is buzzword, a marketing term
11.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)
11.3.2. Agile as a word by it's own simply means - nothing more than merketing term.
11.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
11.3.2.1.1. see Agile World mind map
11.3.3. Agile is a generic description of a “Style of Working”.
11.3.3.1. Not only style of working on project but rather culture in ENTIRE organization
11.3.3.2. ‘Agile Project Management’ is perhaps an oxymoron
11.4. The Agile Mindset, Values and Principles
11.4.1. 4 Agile Value
11.4.1.1. 1. Individuals and interactions over processes and tools
11.4.1.2. 2. Working software over comprehensive documentation
11.4.1.3. 3. Customer collaboration over contract negotiation
11.4.1.4. 4. Responding to change over following a plan
11.4.2. 12 Agile Principles
11.4.2.1. 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
11.4.2.2. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
11.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.
11.4.2.4. 4. Business people and developers must work together daily throughout the project.
11.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.
11.4.2.6. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
11.4.2.7. 7. Working software is the primary measure of progress.
11.4.2.8. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
11.4.2.9. 9. Continuous attention to technical excellence and good design enhances agility.
11.4.2.10. 10. Simplicity - the art of maximizing the amount of work not done - is essential.
11.4.2.11. 11. The best architectures, requirements, and designs emerge from self-organizing teams.
11.4.2.12. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
11.4.3. The unlimited number of Agile Practices
11.4.3.1. The 'forest' of Agile Methods, Frameworks, Standards ...
11.4.3.1.1. see Agile World mind map
11.4.3.2. Being Agile vs Doing Agile
11.5. Agile is a umbrella term enclosing different methodologies, tools, techniques, practices and frameworks
11.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
11.5.2. SCRUM, Lean, KANBAN, XP are not ‘Agile Project Management’ practices but rather team level practices
11.5.2.1. No Project Manager role
11.5.2.2. No project definition and etablished project / programme governance
11.5.2.3. ...
11.5.3. see Agile World mind map
11.6. Plan-Driven Projects vs. Change-driven Project Projects
11.6.1. Traditional (waterfall or sequential) Project Management metaphor
11.6.1.1. Railway metaphor
11.6.1.1.1. Moving forward, based on delivering predicted upfront requirements in accepted tolerances with limited tolerance to change
11.6.1.1.2. Changing course of train based on requirements
11.6.1.2. a.k.a. Plan-driven
11.6.1.2.1. build around paradigm of process
11.6.1.3. defined process control model
11.6.1.3.1. All work is understood before execution
11.6.1.3.2. Given a well-defined set of inputs, the same outputs are generated every time
11.6.1.3.3. Follow the pre-determined steps to get known results
11.6.2. Agile (iterative + incremental + adaptive) Project Management metaphor
11.6.2.1. Sailing metaphor
11.6.2.1.1. Embracing change of requirements, finding TRUE value for stakeholders by experimenting, testing, changing status quo.
11.6.2.1.2. Adapting / changing course of sailing based on business TRUE business needs and priorities, which could be different than requirements
11.6.2.2. a.k.a. Change-driven
11.6.2.2.1. build around paradigm of change / adaptation
11.6.2.3. empirical (adaptive) process control model
11.6.2.3.1. Frequent inspection and adaptation occurs as work proceeds
11.6.2.3.2. Processes are accepted as imperfectly defined
11.6.2.3.3. Outputs are often unpredictable and unrepeatable
11.7. Agile is best for complex projects
11.7.1. Simple (straightforward)
11.7.1.1. Everything is known and predicatable
11.7.2. Complicated
11.7.2.1. More is known than unknown
11.7.3. Complex
11.7.3.1. More is unknown than known
11.7.4. Chaotic (unpredictable)
11.7.4.1. Very little is known
11.7.5. See also Cynefin framework (by Dan Snowden)
11.7.5.1. different view on Cynefin Framework
11.7.5.2. https://www.youtube.com/watch?v=N7oz366X0-8
11.8. Agile is about delivering Value
11.8.1. VALUE is NOT the same as BENEFIT
11.8.1.1. Benefits
11.8.1.1.1. Benefit is about outputs
11.8.1.1.2. Benefit is a objective
11.8.1.1.3. Benefit is an advantage to stakeholders (internal or external to the organization)
11.8.1.1.4. Benefit can be financial & non financial
11.8.1.1.5. Benefit can be ...
11.8.1.1.6. Benefit MUST be measurable and observable
11.8.1.1.7. Benefits are identifiable and quantifiable
11.8.1.1.8. Benefits SHOULD have baselines
11.8.1.1.9. Benefits SHOULD have priorities
11.8.1.1.10. Benefits types:
11.8.1.1.11. Benefit metaphore
11.8.1.1.12. in general benefit = delivered requirements
11.8.1.2. Value
11.8.1.2.1. Value is about outcomes
11.8.1.2.2. Value is subjective
11.8.1.2.3. Value can be measurable (if required but not natural to use such techniques in agile)
11.8.1.2.4. Value can be ...
11.8.1.2.5. Values SHOULD have priorities
11.8.1.2.6. Value metaphore
11.8.1.2.7. in general value = designed fit for purpose, as small as possible solution
11.9. Agile is about focusing on business value / outcome, not strictly project plan / output
11.9.1. Focusing on value delivery not on fixed product definition or strict adherence to plan
11.9.1.1. That's why most Agile approaches define Project Vision
11.10. Agile respects the urgency and importance of priorities conveyed by the customer / user, most prominently by incremental delivery and flexible sequencing
11.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.
11.11.1. “People don't know what they want until you show it to them“ (Steve Jobs)
11.12. Agile is about working closely and constantly (active two side collaboration) with customer throughout (including more than just feedback loops)
11.12.1. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
11.13. Agile is about change, constant change which leads to better value
11.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)
11.13.2. "Move Fast and Break Things" Mark Zuckerberg, Facebook
11.13.3. "Change is the only constant." Heraclitus, Greek philosopher
11.14. Agile thinking / approach often requires mind change
11.14.1. Not every organization is ready for that change!
11.15. Agile thinking / approach often requires cultural shift
11.15.1. Not every organization is ready for that change!
11.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
11.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
11.15.4. “We cannot become what we need by remaining what we are.” (John C. Maxwell)
11.16. Why Agile Works
11.16.1. 1. The customer's representative is in the driver's seat
11.16.2. 2. Quick reaction to the changing market and needs
11.16.3. 3. More visibility
11.16.4. 4. Ideal environment for development
11.16.5. 5. Self-manged teams
11.16.6. 6. Removes confusion and distraction
11.16.7. 7. No fortune tellers; Plan as you go
11.16.8. 8. Issues are less disruptive
11.16.9. 9. Continuous improvement
12. DSDM® Philosophy
12.1. The DSDM® philosophy
12.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."
12.2. 6P Model
12.2.1. Philosophy
12.2.2. Principles
12.2.2.1. Eight principles articulate the core elements of the philosophy
12.2.3. Process
12.2.3.1. A full project lifecycle model that describes the transitions through phases that enable iterative, incremental and adaptive practices
12.2.4. People
12.2.4.1. Facilitation of communication, support of collaboration and the composition and distribution of skills within project teams
12.2.5. Products
12.2.5.1. A set of evolutionary and milestone artefacts cater for different project perspectives
12.2.6. Practices
12.2.6.1. Structured techniques and activities
12.3. Philosophy is achieved when all stakeholders
12.3.1. Understands and buy into the business vision and objectives
12.3.2. Are empowered to make decisions within their area of expertise
12.3.3. Collaborate to deliver a fit for purpose business solution
12.3.4. Collaborate to deliver to agreed timescales in accorddance with business priorities
12.3.5. Accept that change is inevitable as the understanding of the solution grows over time
12.4. The DSDM® philosophy is supported by a set of 8 principles that build the mindset and behaviours necessary to bring the philosophy alive.
12.5. The 8 principles are themself supported by people, Agile process, clearly defined products and recommended practices
12.6. Common sense
12.6.1. "sound practical judgment independent of specialised knowledge or training; normal native intelligence"
12.7. Pragmatism
12.7.1. "action or policy dictated by consideration of the immediate practical consequences rather than by theory or dogma"
13. DSDM® Principles (8)
13.1. Principles are universally applicable statements.
13.1.1. Principles are universal, self-validating and empowering.
13.1.2. They provide guidance to organizations.
13.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.
13.2.1. A way of thinking and working.
13.3. If a team doesn't follow all the principles then they don't get the full benefit.
13.3.1. It increases risk.
13.4. Treat non-adherence to the principles as a risk.
13.4.1. Compromising any of the Principles undermines the philosophy of DSDM® and introduces risk to the successful outcome of the project.
13.5. The 10 Golden Rules for Successful Agile Projects (by Keith Richards)
13.5.1. https://www.youtube.com/watch?v=P84PqqJV7Es
13.5.2. No. 1: Define the project objective in less than 10 words
13.5.2.1. You must start with the end in mind
13.5.2.2. You need to know exactly where you are going
13.5.2.3. The business case is your best friend
13.5.2.4. This will take you a long time to do
13.5.2.5. It will help you to kill a project going nowhere
13.5.2.6. The scope of the project will map on to this.
13.5.2.7. TIP
13.5.2.7.1. Can you write the project objective on a Post-it note with a flip chart marker?
13.5.3. No. 2: Build a team with those who say ‘can’
13.5.3.1. A lot of being agile is about options
13.5.3.2. If you get the right people you are half way there
13.5.3.3. Choose the right person above the right skill set
13.5.3.4. “If you think you can’t, you’re right” – Carol Bartz
13.5.3.5. You need collaboration and team spirit.
13.5.3.6. TIP
13.5.3.6.1. Ask a team member this question: ‘can I ask a favour?’
13.5.4. No. 3: Go slow early to go fast later
13.5.4.1. This is counter intuitive
13.5.4.2. How much ‘DUF’ is enough? Answer EDUF!
13.5.4.3. Build from firm foundations
13.5.4.4. You must avoid analysis paralysis
13.5.4.5. Try and spot early solutioneering.
13.5.4.6. TIP
13.5.4.6.1. Ask yourself ‘is it safe to move on?’
13.5.5. No. 4: Look backwards to go forwards
13.5.5.1. Learn your lessons – both good and bad
13.5.5.2. Evolve the process – it has to evolve
13.5.5.3. If it doesn’t work – do something else!
13.5.5.4. Try this! - Review, Plan, Do
13.5.5.5. Share your experiences with other teams.
13.5.5.6. TIP
13.5.5.6.1. Ask yourself how many of your projects have ended with a project review.
13.5.6. No. 5: Change is great!
13.5.6.1. You need to anticipate change and embrace it
13.5.6.2. This allows a more accurate solution to result
13.5.6.3. Do not confuse the breadth of the scope with the depth
13.5.6.4. Evolve and converge on the solution with the right kind of change.
13.5.6.5. TIP
13.5.6.5.1. How do you feel when a customer says “I’ve changed my mind”?
13.5.7. No. 6: To be understood, seek first to understand.
13.5.7.1. Command and control may not work with Agile
13.5.7.2. Facilitation is a core competency
13.5.7.3. Big ears, big eyes, small mouth
13.5.7.4. You have to play with the cards you are dealt
13.5.7.5. This will give you ownership.
13.5.7.6. TIP
13.5.7.6.1. Try the 10 second silence when getting a progress update – nothing else can compete with it!
13.5.8. No. 7: Collect Actuals – this is the oxygen for your project
13.5.8.1. ‘You cannot control what you cannot measure’ – Tom de Marco
13.5.8.2. Meten is weten – to measure is to know
13.5.8.3. Start now – build a metrics database
13.5.8.4. Keep it simple to start with
13.5.8.5. Calibrate your estimates.
13.5.8.6. TIP
13.5.8.6.1. Do you know (to the nearest day) how much time was spent on testing during your last project?
13.5.9. No. 8: Use fat communication channels
13.5.9.1. Shift the communication traffic to bigger pipes
13.5.9.2. The written word is a silent killer
13.5.9.3. “Never write when you can talk. Never talk when you can nod. And never put anything in an email“ (Eliot Spitzer)
13.5.9.4. Go visual
13.5.9.5. Use workshops.
13.5.9.6. TIP
13.5.9.6.1. Try turning a document over and take a look at what is on the back
13.5.10. No. 9: Work hard at controlling what you can’t control
13.5.10.1. Continuously manage external risks
13.5.10.2. You may get your team right but what about 3rd parties?
13.5.10.3. Are they playing by the same rules as you?
13.5.10.4. Get the team involved
13.5.10.5. Be ‘a bit of a worrier’.
13.5.10.6. TIP
13.5.10.6.1. Actively manage your risk log – it is not a storage area
13.5.11. No. 10: One more day? NO! We’ll catch up? NO!
13.5.11.1. Time focus is your greatest weapon
13.5.11.2. Force the issue – understand your condition
13.5.11.3. Timeboxes not milestones
13.5.11.4. If you are going to fail – fail early
13.5.11.5. Prioritise with MoSCoW – it should be natural.
13.5.11.6. TIP
13.5.11.6.1. Set a deadline and hit it – never extend it, not even once!
13.6. 1 - Focus on the business need
13.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.
13.6.1.1. Project is a means to an end, not an end in itself.
13.6.1.1.1. Solution products are more important than documentation
13.6.2. Understand true business priorities
13.6.3. Establish valid business case
13.6.3.1. There is a formal document called Business Case
13.6.4. Ensure continuous business sponsorship and commitment
13.6.4.1. Business Sponsor (role) is responsible for finance decisions
13.6.4.2. Business Ambassador roles are representatives from client / user side available everyday (~min 15. minutes a day) to Solution Development Teams (SDTs)
13.6.4.2.1. Each Sollution Development Team (SDT) has it's own dedicated Business Ambassador
13.6.5. Guarantee delivery of the Minimum Usable Subset of requirements
13.6.5.1. Not all requirements must be delivered in DSDM® project, but as a minimum those having MUST priority
13.6.5.1.1. see MoSCoW prioritization
13.6.6. Deliver what the business needs when it needs it.
13.6.6.1. The true business priorities must be understood with a sound business case.
13.6.6.2. Discover and understand real client / user NEEDS not just requirements
13.6.6.2.1. Go back and ask WHY project is needed and WHY products are needed, what is the purpose
13.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
13.6.6.3.1. “There is nothing so useless as doing efficiently that which should not be done at all” (Peter F. Drucker)
13.6.7. Principle supported by:
13.6.7.1. Roles
13.6.7.1.1. Business Sponsor (BS)
13.6.7.1.2. Business Visionary (BV)
13.6.7.2. Products
13.6.7.2.1. Business products (documents) created in the Foundation phase
13.6.7.3. Techniques
13.6.7.3.1. MoSCoW
13.6.7.3.2. Timeboxing
13.7. 2 - Deliver on time
13.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.
13.7.1.1. Late delivery can often undermine the very rationale for a project, especially where market opportunities or legal deadlines are involved.
13.7.2. Timebox the work into manageable chunks of time.
13.7.2.1. Timeboxes are planned in advance and the timeframe set.
13.7.2.1.1. The dates never change and features are varied depending on business priorities, in order to achieve the deadline.
13.7.2.1.2. DO NOT EVER EXTEND TIMEBOX!
13.7.3. Focus on business priorities and needs (not just requirements)
13.7.3.1. Question each decision
13.7.4. Always hit deadlines
13.7.4.1. Time is only asset that you can't (directly) control in life!
13.7.4.1.1. You can increade / decrease quality
13.7.4.1.2. You can increase / decrease risk
13.7.4.1.3. You can increase / decrease benefits
13.7.4.1.4. You can add / remove resources
13.7.4.1.5. All of above can give you (indirectly) some time ... but you cannot directly control time.
13.7.4.2. Build confidence through predictable delivery and maintain reputation
13.7.4.2.1. QDOS - Quality Delivery of Service
13.7.4.3. You can only loose time but never gain ...
13.7.4.3.1. You may think that you gain time by changing other project variables
13.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.
13.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
13.7.5. Define the breadth (project scope) of your requirements without going into too much detail.
13.7.6. Estimate the relative size, priority and complexity of each requirement.
13.7.6.1. UTH rule (rule not law)
13.7.6.1.1. Units, Tens and Hundreds
13.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
13.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
13.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.
13.7.7. Principle supported by:
13.7.7.1. Roles
13.7.7.1.1. Project Manager (PM)
13.7.7.1.2. Team Leader (TL)
13.7.7.2. Techniques
13.7.7.2.1. MoSCoW
13.7.7.2.2. Timeboxing
13.8. 3 - Collaborate
13.8.1. Teams that work in a spirit of active cooperation and commitment will always outperform groups of individuals working only in loose association.
13.8.1.1. Collaboration cncourages increased understanding, greater speed & shared ownership
13.8.2. Involve the right stakeholders, at the right time, throughout the project
13.8.3. Encourage pro-active involvement from the business representatives
13.8.4. Ensure that all members of the team are empowered to take decisions on behalf of those they represent
13.8.4.1. Even at the lowest level (of course with boundaries)
13.8.4.1.1. Power to the people!
13.8.5. Build a one team culture (also between supplier and customer)
13.8.5.1. Deployment is more likely to go smoothly, because of the cooperation of all parties concerned throughout development
13.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
13.8.6. Actively involve business
13.8.6.1. Business involvment in every day
13.8.6.2. Done by Business Ambassador (BAMB) role
13.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
13.8.8. The Solution Development Team (SDT) brings together business and technical roles in a single team.
13.8.9. Facilitated workshops technique enable stakeholders to share knowledge with the project team
13.8.9.1. "A well-constructed project management workshop should give people a solid foundation to build on." Bentley & Borman, 2001
13.8.10. The risk of building the wrong solution is greatly reduced
13.8.10.1. a.k.a. "fatware"
13.8.10.2. a.k.a. "shelfware"
13.8.10.3. a.k.a. "zombieware"
13.8.10.4. ...
13.8.11. The final solution is more likely to meet the users' real business requirements
13.8.12. People want to be part of something
13.8.13. Recommended co-location
13.8.14. Solution Development Teams are:
13.8.14.1. Empowered
13.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
13.8.14.1.2. "Worker are knowledge workers if they know more about the work they perform than their bosses." Peter Drucker
13.8.14.2. Self-directed / Self-disciplined
13.8.14.2.1. Teams commit only to the work they can accomplish and then perform that work as effectively as possible.
13.8.14.2.2. Fully and exclusively responsible for working out how the Timebox products will be developed.
13.8.14.3. Self-organizing
13.8.14.3.1. Teams estimate and plan their own work and then proceed to collaborate iteratively to do so.
13.8.14.3.2. Style of working
13.8.14.3.3. Who is needed on the team and not
13.8.14.3.4. When it needs help resolving Impediments
13.8.14.3.5. Needed process improvements
13.8.14.3.6. Technology practices
13.8.14.3.7. Techniques
13.8.14.3.8. Who does what and when
13.8.14.3.9. Self-organizing rarely means self-managing
13.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
13.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
13.8.14.4. Self-aware
13.8.14.4.1. Teams strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.
13.8.14.5. Self-sufficient
13.8.14.5.1. Having all the skills needed within the team to deliver and test products.
13.8.14.6. No hierarchy within the team
13.8.14.6.1. No bosses or managers.
13.8.14.7. Cross-functional
13.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.
13.8.14.8. Small (7 +/- 2)
13.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..
13.8.14.8.2. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"
13.8.14.9. Autonomical
13.8.14.9.1. Yet SDTs do not work in a vacuum.
13.8.14.10. Accountable
13.8.14.10.1. SDTs are accountable for fulfilling the goal(s) they have taken on.
13.8.14.11. Collaborative
13.8.14.11.1. Download: 17 Indisputable Laws of Teamwork by John Maxwell
13.8.14.11.2. Improved collaboration between peole correspondingly increases the opportunities for people to learn from one another.
13.8.14.12. Based on trust and respect
13.8.14.13. Ideally static
13.8.14.13.1. Most successful with long-term, full-time membership.
13.8.14.13.2. Subject to re-structuring if team is not working.
13.8.14.14. Ideally collocated
13.8.14.14.1. Most successful when located in one team room (particularly for the first few Timeboxes).
13.8.14.14.2. Collocated mentally not only phisically.
13.8.14.14.3. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001
13.8.15. Principle supported by:
13.8.15.1. Roles
13.8.15.1.1. Business Sponsor (BS)
13.8.15.1.2. Business Visionary (BV)
13.8.15.1.3. Business Ambassador (BAMB)
13.8.15.1.4. Solution Development Teams (SDTs)
13.8.15.1.5. Workshop Facilitator (WF)
13.8.15.2. Techniques
13.8.15.2.1. Facilitated Workshops
13.8.15.2.2. Daily Stand-ups (a.k.a. Scrum meetings)
13.9. 4 - Never compromise quality
13.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.
13.9.2. Agree the level of quality from the outset, before development starts
13.9.2.1. Level of quality is agreed at the start at Foundations phase.
13.9.2.2. Quality level is set upfront and never changes through entire project and all Timeboxes
13.9.2.2.1. All increments have the same level of quality
13.9.3. Ensure that quality does not become a variable
13.9.3.1. A solution has to be “good enough”.
13.9.3.1.1. right-engineering (no under-engineering or over-engineering)
13.9.3.1.2. no "gold plating"
13.9.4. Projects must test early and continuously and review constantly.
13.9.4.1. Everything is tested as early as possible.
13.9.4.2. Test early, test continuously and test to the appropriate level
13.9.4.2.1. MoSCoW and timeboxing ensure testing is appropriate, without introducing unnecessary risks
13.9.4.2.2. "Bad programmers have all the answers. Good testers have all the questions.", Gil Zilberfeld
13.9.4.3. Build in quality by constant review
13.9.4.4. MoSCoW and timeboxing techniques ensure testing is appropriate, without introducing unnecessary risks
13.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.
13.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.
13.9.6. Fail fast.
13.9.6.1. "fail fast, learn fast"
13.9.6.2. Do tests every day, not only before formal sign-off
13.9.6.2.1. Solution Tester (ST) role is responsible for everyday tests
13.9.6.3. User Acceptance Testing (UAT) testes are not enough
13.9.6.3.1. e.g. in IT - use black box testing / Unit testing every day even on unfinished product
13.9.6.4. "I have not failed. I’ve just found 10,000 ways that won’t work", Thomas Edison
13.9.6.5. "Failure is simply the opportunity to begin again, this time more intelligently", Henry Ford
13.9.6.6. "Testing is more than testing (and should start before testing)" (Dorothy Graham)
13.9.7. If the business agrees features in Minimum Usable Subset have been provided, then the solution should be acceptable
13.9.8. Principle supported by:
13.9.8.1. Roles
13.9.8.1.1. Solution Tester (ST)
13.9.8.2. Products
13.9.8.2.1. Testing products
13.9.8.3. Techniques
13.9.8.3.1. MoSCoW
13.9.8.3.2. Timeboxing
13.9.8.3.3. Daily Stand-ups
13.9.8.4. Early and integrated testing
13.9.8.5. Regular reviews throughout lifecycle
13.10. 5 - Build incrementally from firm foundation
13.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.
13.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.
13.10.1.2. DSDM® advocates incremental delivery of the solution in order to deliver real business benefit as early as is practical.
13.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.
13.10.2. Carry-out appropriate analysis and enough design up front (EDUF) to create strong foundations
13.10.3. Formally re-assess priorities and informally re-assess ongoing project viability with each delivered increment.
13.10.4. Incremental delivery (of value to production / live environment)
13.10.4.1. Increments allow the business to take advantage of work before the final product is complete, encouraging stakeholder confidence and feedback.
13.10.4.1.1. This is based on doing just enough upfront analysis to proceed and accepting that detail emerges later.
13.10.4.2. Deliver functionality in stages by focusing on ‘quick-wins’ to gain early confidence and early business support.
13.10.4.2.1. Momentum is built.
13.10.4.2.2. Solution should be delivered in increments that provide the greatest value to the customer.
13.10.5. Increments deployed into operational use for early ROI
13.10.6. Strive for early delivery of business benefit where possible.
13.10.7. Continually confirm the correct solution is being built.
13.10.8. Implement this principle using DSDM® lifecycle
13.10.9. "The increment must be completed, meaning the increment must be a complete piece of usable software." K. Schwager, J. Suterland
13.10.10. Principle supported by:
13.10.10.1. Techniques
13.10.10.1.1. Iterative Development
13.10.10.2. DSDM® Lifecycle
13.11. 6 - Develop iteratively
13.11.1. DSDM® uses a combination of Iterative Development, frequent demonstrations and comprehensive review to encourage timely feedback.
13.11.1.1. Embracing change as a part of this evolutionary process allows the team to converge on an accurate business solution.
13.11.1.2. The concept of iteration is at the heart of everything developed as part of the DSDM® approach.
13.11.2. Do enough design up front (EDUF) to create strong foundations.
13.11.3. Accept that work is not always right first time.
13.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.
13.11.3.2. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.
13.11.3.2.1. Iterative approach on all projects
13.11.3.2.2. Previous steps can be revisited as part of its iterative approach.
13.11.3.2.3. This means that DSDM® project lifecycle is iterative
13.11.4. Build business / customer / user feedback into each iteration
13.11.4.1. This means that DSDM® project lifecycle is adaptive to new business requirements gathered after feedback
13.11.5. Accept that work is not always right first time.
13.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.
13.11.5.2. Use Timeboxes to allow for change yet continuously confirm that the solution is the right one.
13.11.6. Accept most detail emerges later rather than sooner.
13.11.6.1. Often end users / clients doesn't know what then need and think they know what they want!
13.11.7. Embrace change, the right solution will not emerge without it.
13.11.7.1. “People don’t know what they want until you show it to them” (Steve Jobs, 1955 - 2011)
13.11.8. Be creative, experiment, innovate, test, learn, evolve.
13.11.9. Previous steps can be revisited as part of its iterative approach.
13.11.10. Principle supported by:
13.11.10.1. Techniques
13.11.10.1.1. Iterative Development
13.11.10.1.2. Timeboxing
13.11.10.1.3. Prototyping
13.11.10.1.4. Modelling
13.11.10.2. Iteration and constant review
13.12. 7 - Communicate continuously and clearly
13.12.1. Poor communication is often cited as the biggest single cause of project failure.
13.12.1.1. DSDM practices are specifically designed to improve communication effectiveness for both teams and individuals.
13.12.2. Encourage informal, face-to-face communication at all levels
13.12.3. Run daily stand-ups sessions
13.12.3.1. Same like Daily Scrum Meetings in Scrum framework. Agile daily team stand-up session are exactly the same.
13.12.4. Use workshops, with a facilitator where appropriate
13.12.5. Use rich, visual communication (best interactive) communication techniques such as Modelling and Prototyping
13.12.6. Demonstrate the Evolving Solution early and often
13.12.7. Keep documentation lean and timely.
13.12.8. Manage the expectations of the stakeholder at all levels throughout the project.
13.12.9. Always aim for honesty and transparency in all communication
13.12.10. DSDM® emphasises the value of human interaction through Stand-ups, Workshops, clearly defined role and active business involvement.
13.12.11. Modelling and Prototyping make early instances of the solution available for scrutiny.
13.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.
13.12.11.2. Present instances of the evolving solution (not perceptions hidden behind PowerPoint presentations) early and often.
13.12.12. Communication, Conversation, Collaboration, Community, Culture (5C).
13.12.13. Principle supported by:
13.12.13.1. Roles
13.12.13.1.1. Workshop Facilitator (WF)
13.12.13.2. Techniques
13.12.13.2.1. Facilitated workshops
13.12.13.2.2. Daily Stand-ups
13.12.13.3. Clearly defined roles
13.12.13.4. User and business involvement
13.12.13.5. Team empowerment
13.12.13.6. Models and prototypes
13.13. 8 - Demonstrate control
13.13.1. Demostrate control - for customer and users to show that everything is under control
13.13.1.1. “If everything seems under control, you're not going fast enough.“ (Mario Andretti, Italian American world champion racing driver)
13.13.2. In many environments it is not enough simply to be in control, it needs to be able to prove it
13.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.
13.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.
13.13.2.1.2. It is also vital to ensure transparency of all work being performed be the team.
13.13.3. Make plans and progress visible to all.
13.13.3.1. Even to lowest level team members.
13.13.4. Measure progress through focus on delivery of products rather than completed activities.
13.13.5. Manage proactively
13.13.6. Evaluate continuing project viability based on the business objectives.
13.13.7. Use an appropriate level of formality for tracking and reporting.
13.13.8. The team needs to be proactive when monitoring and controlling progress in line with Foundations Phase.
13.13.8.1. They need to constantly evaluate the project viability based on the business objectives.
13.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.
13.13.10. Principle supported by:
13.13.10.1. Roles
13.13.10.1.1. Project Manager (PM)
13.13.10.1.2. Team Leader (TL)
13.13.10.2. Products
13.13.10.2.1. Management Foundations
13.13.10.2.2. Timebox Plans
13.13.10.3. Techniques
13.13.10.3.1. Timeboxing
13.13.10.4. Constant review with client and users
13.14. Summary & Conclusion
13.14.1. DSDM® is an Agile Project Delivery Framework that delivers the right solution at the right time
13.14.1.1. Iterative
13.14.1.2. Incremental
13.14.1.3. Adaptive
13.14.1.4. Empirical
13.14.1.5. Change-driven
13.14.2. The right business solution is delivers because
13.14.2.1. The Project Team and others significant stakeholders remain focused on the business outcome
13.14.2.2. Delivery is on time providing an early ROI and reduced risk
13.14.2.3. All people involved with the project work collaboratively to deliver the optimum solution
13.14.2.4. Work is prioritized according to business need and the ability of users to accommodate changes
13.14.2.5. DSDM® does not compromise quality
14. DSDM® Roles (13)
14.1. Introduction
14.1.1. Roles are not positions, nor are they meant to be.
14.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.
14.1.2. The Project-level roles are
14.1.2.1. Business Sponsor (BS), Business Visionary (BV), Technical Coordinator (TC), Project Manager (PM) and Business Analyst (BA)
14.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.
14.1.3. The Business Visionary (BV) and the Technical Coordinator (TC) hold the customer and supplier visions of solution excellence.
14.1.4. The Project Manager (PM) ensures that the funding supplied is used effectively to create the envisaged solution.
14.1.5. The Development roles are
14.1.5.1. Team Leader (TL), Business Ambassador (BAMB), Business Analyst (BA), Solution Developer (SD) and Solution Tester (ST).
14.1.5.2. Jointly these roles form the engine room of the project.
14.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.
14.1.7. The Supporting roles are
14.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.
14.1.7.2. The project may bring in subject matter experts as necessary for their specialist expertise.
14.1.7.2.1. Business Advisors (BADV)
14.1.7.2.2. Technical Advisors (TADV)
14.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.
14.1.8.1. SDTs are team with goals, not set of individuals forming a group of unrelated peoples having different personal goals.
14.1.8.1.1. Team means:
14.2. Legend
14.2.1. Orange
14.2.1.1. Business intrest roles representing the business view
14.2.1.2. Typically taken by business personnel
14.2.2. Blue
14.2.2.1. Management intrest roles representing the management / leadership view
14.2.2.2. Managing or facilitating the management / leadership aspects of the project
14.2.3. Green
14.2.3.1. Solution / technical intrest roles representing the solution / technical view
14.2.3.2. Contributing to technical consistency, design or development of the solution
14.2.4. Grey
14.2.4.1. Process intrest roles representing the process view
14.2.4.2. Facilitating the process aspects of the project
14.3. Role Combinations
14.3.1. Permissible Role Combinations
14.3.1.1. Combinations should not in general be considered transitive.
14.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
14.3.1.2. Business Sponsor + Business Visionary
14.3.1.3. Business Visionary + Business Ambassador
14.3.1.4. Team Leader + Solution Developer
14.3.1.5. Team Leader + Solution Tester
14.3.1.6. Business Advisor + Soluton Tester
14.3.2. Non Permissible Role Combinations
14.3.2.1. Business Sponsor + Project Manager
14.3.2.2. Business Visionary + Project Manager
14.3.2.3. Business Visionary + Technical Coordinator
14.3.2.4. Business Analyst + Business Ambassador
14.3.2.5. Project Manager + Team Leader
14.3.2.6. Solution Developer + Solution Tester
14.3.2.7. Workshop Facilitator + any Project level role
14.3.2.8. DSDM Coach + any SDT role
14.4. Project-level roles
14.4.1. The Project-level roles are
14.4.1.1. Business Sponsor (BS), Business Visionary (BV), Technical Coordinator (TC), Project Manager (PM) and Business Analyst (BA)
14.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.
14.4.2. Business Sponsor (BS)
14.4.2.1. Project Champion.
14.4.2.2. Most senior project-level business role.
14.4.2.3. Provides the overall strategic direction and funding.
14.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.
14.4.2.5. Has a crucial responsibility to ensure and enable fast progress throughout the project.
14.4.2.6. There should be only one person responsible for this role.
14.4.2.7. Prime concern is in the value and benefit of the project, rather than details
14.4.2.8. Responsibilities
14.4.2.8.1. Owns the Business Case.
14.4.2.8.2. Ensuring ongoing viability of the project in line with the Business Case.
14.4.2.8.3. Ensuring that funds and other resources are made available as needed.
14.4.2.8.4. Ensuring the decision-making process for escalated project issues is effective and rapid.
14.4.2.8.5. Responding rapidly to escalated issues.
14.4.2.9. Mappings to other roles in other methods ...
14.4.2.9.1. PRINCE2®
14.4.3. Business Visionary (BV)
14.4.3.1. Senior project-level business role.
14.4.3.2. Provides the “big picture” and the context for the project.
14.4.3.3. More actively involved than the Business Sponsor.
14.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.
14.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.
14.4.3.6. Remains involved throughout the project.
14.4.3.7. Providing the team with strategic direction.
14.4.3.8. Ensuring that the solution delivered will enable the benefits described in the Business Case to be achieved.
14.4.3.9. Responsibilities
14.4.3.9.1. Owning the wider implications of any business change from an organisational perspective.
14.4.3.9.2. Defining the business vision for the project.
14.4.3.9.3. Communicating and promoting the business vision to all interested parties.
14.4.3.9.4. Monitoring progress of the project in line with the business vision.
14.4.3.9.5. Contributing to key requirements, design and review sessions.
14.4.3.9.6. Approving changes to the high-level requirements in the Prioritised Requirements List.
14.4.3.9.7. Ensuring collaboration across stakeholder business areas.
14.4.3.9.8. Ensuring business resources are available as needed.
14.4.3.9.9. Promoting the translation of the business vision into working practice.
14.4.3.9.10. Acting as a final arbiter of any disagreements between team members.
14.4.3.9.11. ... in general governing WHAT
14.4.3.10. Mappings to other roles in other methods ...
14.4.3.10.1. PRINCE2®
14.4.4. Technical Coordinator (TC)
14.4.4.1. Technical design authority for the project.
14.4.4.2. Technical architecture design authority.
14.4.4.3. Ensures technical consistency and coherence across SDTs.
14.4.4.4. Ensures adherence to agreed standards.
14.4.4.5. The “glue” that holds the project together for technology and innovation.
14.4.4.6. Equivalent to the Business Visionary (BV), ensuring the solution is technically sound and cohesive.
14.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.
14.4.4.7. Responsibilities
14.4.4.7.1. Agreeing and controlling the technical architecture.
14.4.4.7.2. Determining the technical environments.
14.4.4.7.3. Advising on and coordinating each team's technical activities.
14.4.4.7.4. Identifying and owning architectural and other technically based risk, escalating to the Project Manager as appropriate.
14.4.4.7.5. Ensuring the non-functional requirements (NFRs) are achievable and subsequently met.
14.4.4.7.6. Ensuring adherence to appropriate standards or best practice.
14.4.4.7.7. Controlling the technical configuration of the solution.
14.4.4.7.8. Managing technical aspects of the transition of the solution into live use.
14.4.4.7.9. Resolving technical differences between technical team members.
14.4.4.7.10. ... in general governing HOW
14.4.4.8. Mappings to other roles in other methods ...
14.4.4.8.1. PRINCE2®
14.4.4.8.2. Disciplined Agile Delivery (DAD)
14.4.5. Project Manager (PM)
14.4.5.1. Delivery focused.
14.4.5.2. Provides high level direction to SDTs
14.4.5.2.1. Multiple SDTs at once if project team is dividen on several SDTs.
14.4.5.3. Good communicator, with planning, management and co-ordination skills
14.4.5.4. Project Manager (PM) is a role - not necessarily the same as a job title that might be used in their organisation
14.4.5.5. Team Leaders (TL) often do DSDM® PM role in small projects.
14.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.
14.4.5.6. There is usually only one PM, or at least a single person is ultimately accountable for delivery of the project.
14.4.5.7. Responsibilities
14.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.
14.4.5.7.2. High-level project planning and scheduling, but not detailed task planning.
14.4.5.7.3. Monitoring progress against the baselined project plans.
14.4.5.7.4. Managing risk and any issues as they arise, escalating to senior business or technical roles as required.
14.4.5.7.5. Managing the overall configuration of the project.
14.4.5.7.6. Motivating the teams to meet their objectives.
14.4.5.7.7. Managing business involvement within the SDTs.
14.4.5.7.8. Resourcing Specialist Roles as required.
14.4.5.7.9. Handling problems escalated from the Solution Development Teams.
14.4.5.7.10. Coaching the SDTs when handling difficult situations.
14.4.5.8. Mappings to other roles in other methods ...
14.4.5.8.1. PRINCE2®
14.4.6. Business Analyst (BA)
14.4.6.1. Fully integrated with SDT.
14.4.6.1.1. Not an intermediary between Business Ambassador and team.
14.4.6.1.2. Supports communication between the business and the SDT.
14.4.6.2. Focuses on the relationship between the business and technical roles
14.4.6.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.
14.4.6.4. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.
14.4.6.5. Responsibilities
14.4.6.5.1. Managing development, distribution and baseline approval of all documentation and products related to business requirements and their interpretation
14.4.6.5.2. Ensuring that the business implications of all day-to-day decisions are properly thought through
14.4.6.6. The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team.
14.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.
14.4.6.7. see AgileBA® mind map
14.5. Solution Development Team (SDT) (project can have multiple SDTs)
14.5.1. The Development roles are
14.5.1.1. Team Leader (TL), Business Ambassador (BAMB), Business Analyst (BA), Solution Developer (SD) and Solution Tester (ST).
14.5.1.2. Jointly these roles form the "engine room" of the project.
14.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.
14.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.
14.5.2.1. They do not have to formally agree each and every decision with the PM.
14.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.
14.5.3. The SDT has every competency it needs to deliver a done Timebox / Increment.
14.5.4. The majority of team members should be “generalizing specialists”
14.5.4.1. Also known as “T-Shaped” people
14.5.5. We should allow them to create an environment in which they will thrive as a team.
14.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.
14.5.6. Solution Development Teams are:
14.5.6.1. Empowered
14.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
14.5.6.1.2. "Worker are knowledge workers if they know more about the work they perform than their bosses." Peter Drucker
14.5.6.2. Self-directed / Self-disciplined
14.5.6.2.1. Teams commit only to the work they can accomplish and then perform that work as effectively as possible.
14.5.6.2.2. Fully and exclusively responsible for working out how the Timebox products will be developed.
14.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.
14.5.6.3. Self-organizing
14.5.6.3.1. Teams estimate and plan their own work and then proceed to collaborate iteratively to do so.
14.5.6.3.2. Style of working
14.5.6.3.3. Who is needed on the team and not
14.5.6.3.4. When it needs help resolving Impediments
14.5.6.3.5. Needed process improvements
14.5.6.3.6. Technology practices
14.5.6.3.7. Techniques
14.5.6.3.8. Who does what and when
14.5.6.3.9. Self-organizing rarely means self-managing
14.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.
14.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
14.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
14.5.6.4. Self-aware (personalities/people)
14.5.6.4.1. Teams strive to identify what works well for them, what doesn’t, and then learn and adjust accordingly.
14.5.6.5. Self-sufficient
14.5.6.5.1. Having all the skills needed within the team to deliver and test products.
14.5.6.6. No hierarchy within the team
14.5.6.6.1. No bosses or managers.
14.5.6.7. Cross-functional
14.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.
14.5.6.8. Small (7 +/- 2)
14.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..
14.5.6.8.2. see George A. Miller: "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information"
14.5.6.9. Autonomical
14.5.6.9.1. Yet SDTs do not work in a vacuum.
14.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.
14.5.6.9.3. External Autonomy
14.5.6.9.4. Internal Autonomy
14.5.6.9.5. Individual Autonomy
14.5.6.10. Accountable
14.5.6.10.1. SDTs are accountable for fulfilling the goal(s) they have taken on.
14.5.6.11. Collaborative
14.5.6.11.1. Download: 17 Indisputable Laws of Teamwork by John Maxwell
14.5.6.11.2. Improved collaboration between peole correspondingly increases the opportunities for people to learn from one another.
14.5.6.12. Based on trust and respect
14.5.6.12.1. Trust but verify and then guide
14.5.6.13. Ideally static
14.5.6.13.1. Most successful with long-term, full-time membership.
14.5.6.13.2. Subject to re-structuring if team is not working.
14.5.6.14. Ideally collocated
14.5.6.14.1. Most successful when located in one team room (particularly for the first few Timeboxes).
14.5.6.14.2. Collocated mentally not only phisically.
14.5.6.14.3. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001
14.5.6.15. Skillful (craft)
14.5.6.16. Team means:
14.5.6.16.1. T - Together
14.5.6.16.2. E - Everyone
14.5.6.16.3. A - Achieves
14.5.6.16.4. M - More
14.5.7. Solution Development Team are similar to Development Team in Scrum but with more defined responsibilities
14.5.7.1. Agile Project Management and Scrum V2 pocketbook
14.5.7.1.1. ISBN-13: 978-0992872793
14.5.7.1.2. Pages: 62
14.5.7.1.3. http://dsdm.org/product/agile-project-management-and-scrum
14.5.8. Team Leader (TL)
14.5.8.1. The agile community has focused on project or team leadership over team management.
14.5.8.2. Leadership rather than management.
14.5.8.3. Person holding it will ideally be elected by his or her peers as the best person to lead.
14.5.8.4. Reporting to the PM.
14.5.8.5. Ensures that a SDT functions as a whole and meets its objectives.
14.5.8.6. Works with the team to plan and co-ordinate all aspects of product delivery at the detailed level.
14.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.
14.5.8.7.1. e.g. Some technical people are introverted and not comfortable with proactively collaborating and communicating.
14.5.8.8. Mappings to other roles in other methods ...
14.5.8.8.1. PRINCE2®
14.5.9. Business Ambasador (BAMB)
14.5.9.1. A true “ambassador”.
14.5.9.2. Business role within the SDT.
14.5.9.3. Working closely with the rest of the SDT.
14.5.9.4. Responsible for the day-to-day communication between the project and the business.
14.5.9.5. Guides the evolution of the solution.
14.5.9.6. Generally comes from the business area being addressed.
14.5.9.7. Provides business-related information from the perspective of those who will ultimately make direct use of the solution.
14.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.
14.5.9.9. Empowered to make immediate decisions for a wide range of business stakeholders.
14.5.9.9.1. The empowerment issue can be tough for organizations used to a command-and-control management strateg
14.5.9.10. Stress key nature of this role.
14.5.9.11. These are typically very busy people who the business struggle to spare.
14.5.9.11.1. Can quickly become a bottleneck for the team.
14.5.9.12. Responsibilities
14.5.9.12.1. Contributing to all requirements, design and review sessions
14.5.9.12.2. Providing the business perspective for all day-to-day project decisions
14.5.9.12.3. Providing the detail of business scenarios to help define and test the solution
14.5.9.12.4. Communicating with other users, involving them as needed and getting their agreement
14.5.9.12.5. Providing day-to-day assurance that the solution is evolving correctly
14.5.9.12.6. Organising and controlling business acceptance testing of the solution
14.5.9.12.7. Developing business user documentation for the ultimate solution
14.5.9.12.8. Ensuring user training is adequately carried out
14.5.9.12.9. Attending the daily team meetings
14.5.10. Business Analyst (BA)
14.5.10.1. Fully integrated with SDT.
14.5.10.1.1. Not an intermediary between Business Ambassador and team.
14.5.10.1.2. Supports communication between the business and the SDT.
14.5.10.2. Focuses on the relationship between the business and technical roles
14.5.10.3. Ensures accurate and decisive direction is provided to the SDT on a day-to-day basis.
14.5.10.4. Ensures that the business needs are properly analysed and are correctly reflected in the guidance the team.
14.5.10.5. Responsibilities
14.5.10.5.1. Managing development, distribution and baseline approval of all documentation and products related to business requirements and their interpretation
14.5.10.5.2. Ensuring that the business implications of all day-to-day decisions are properly thought through
14.5.10.6. The Business Analyst is intentionally positioned as part of the project level as well as part of the Solution Development Team.
14.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.
14.5.10.7. see AgileBA® mind map
14.5.11. Solution Developer (SD)
14.5.11.1. Interprets business requirements and translates them into a deployable solution that meets functional and non-functional needs.
14.5.11.2. Should ideally be allocated full time to the project.
14.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.
14.5.11.4. DSDM® states that ideally we are looking for true Analyst and Developer in one person
14.5.11.4.1. Soft skills cannot be underestimated - especially communication, negotiation, selling, listening etc.
14.5.12. Solution Tester (ST)
14.5.12.1. Fully integrated with the SDT.
14.5.12.2. Performs testing in accordance with the Technical Testing Strategy.
14.5.12.3. Ensure quality solution.
14.5.12.4. Independence of testing is key
14.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).
14.5.12.6. Responsibilities
14.5.12.6.1. Works collaboratively with Business Ambassador (BAMB), Solution Developers (SD) and other Solution Testers (ST)
14.5.12.6.2. Carrying out all types of technical testing of the solution as a whole
14.5.12.6.3. Creating testing products, e.g. test cases, plans and logs
14.5.12.6.4. Reporting the results of testing activities to the Technical Coordinator (TC) for Quality Assurance purposes
14.5.12.6.5. Keeping the Team Leader (TL) informed of the results of testing activities
14.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
14.5.12.7. Mappings to other roles in other methods ...
14.5.12.7.1. eXtreme Programming (XP)
14.5.12.7.2. Disciplined Agile Delivery (DAD)
14.6. Supporting Roles
14.6.1. The Supporting roles are
14.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.
14.6.1.1.1. The Advisor roles may be filled by one or more subject matter experts.
14.6.1.2. The project may bring in subject matter experts as necessary for their specialist expertise.
14.6.2. Business Advisor (ADV)
14.6.2.1. Often a peer of the Business Ambassador.
14.6.2.2. Called upon to provide specific, and often, specialist input to solution development or solution testing.
14.6.2.3. Often user or beneficiary of the solution.
14.6.2.4. May, for example, simply provide legal or regulatory advice with which the solution must comply.
14.6.2.5. Responsibilities
14.6.2.5.1. Providing specialist advice on, or help with:
14.6.2.5.2. Providing specialist input into relevant:
14.6.2.6. Mappings to other roles in other methods ...
14.6.2.6.1. Disciplined Agile Delivery (DAD)
14.6.3. Technical Advisor (TADV)
14.6.3.1. Technical equivalent of a Business Advisor.
14.6.3.2. Supports SDT.
14.6.3.3. Provides specific and often specialist technical input and advice.
14.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.
14.6.3.5. could be in real life for example ...
14.6.3.5.1. IT Security Expert
14.6.3.5.2. IT Security Consultatant
14.6.3.5.3. Business Continuity Expert
14.6.3.5.4. Risk Manager (from organization)
14.6.3.5.5. Support
14.6.3.6. Mappings to other roles in other methods ...
14.6.3.6.1. Disciplined Agile Delivery (DAD)
14.6.4. Workshop Facilitator (WF)
14.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))
14.6.4.2. Independent from project team and client.
14.6.4.2.1. Independent of workshop outcome.
14.6.4.3. Managing the workshop process.
14.6.4.4. Responsible for the context of the workshop, not the content.
14.6.4.5. Catalyst for preparation and communication.
14.6.4.6. Responsibilities
14.6.4.6.1. For each workshop:
14.6.4.6.2. Engaging with participants to:
14.6.4.7. Download: What Do We Mean By Facilitation
14.6.5. DSDM Coach (DC)
14.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.
14.6.5.2. Should ideally be independently to ensure competence to fulfil this role.
14.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.
14.6.5.4. In Scrum, this role is part of the Scrum Master role.
14.6.5.5. Responsibilities
14.6.5.5.1. Embedding the DSDM® framework.
14.6.5.5.2. Providing detailed knowledge and experience of DSDM® to inexperienced agile teams
14.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
14.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
14.6.5.5.5. Helping the team work in the collaborative and cooperative way demanded by DSDM® and all agile approaches
14.6.5.5.6. Building DSDM® capability within the team
14.7. Summary & Conclusion
14.7.1. DSDM® identifies roles in 3 categories / levels:
14.7.1.1. Project-level
14.7.1.2. Solution Development
14.7.1.3. Supporting / Other
14.7.2. The business interests are represented by
14.7.2.1. Business Sponsor (BS)
14.7.2.2. Business Visionary (BV)
14.7.2.3. Business Ambassador (BAMB)
14.7.2.4. Business Advisor (BADV)
14.7.3. The solution / technical interests are represented by
14.7.3.1. Technical Coordinator (TC)
14.7.3.2. Solution Developer (SD)
14.7.3.3. Solution Tester (ST)
14.7.3.4. Technical Advisor (TADV)
14.7.4. Management interests are represented
14.7.4.1. Project Manager (PM)
14.7.4.2. Team Leader (TL)
14.7.4.3. Business Analyst (BA)
14.7.5. Supporting interests are represented
14.7.5.1. DSDM Coach (DC)
14.7.5.2. Workshop Facilitator (WF)
14.7.6. One role may be taken by several people
14.7.7. One person may take several roles
15. DSDM® Products (a.k.a. Artifacts) (for simplicity documentation) (14)
15.1. Introduction
15.1.1. DSDM® identifies deliverables associated with each phase of the project lifecycle.
15.1.1.1. These are referred to as Products.
15.1.1.1.1. Could be documentation (Word, Excel), could be model (software for PPM) etc.
15.1.2. Not all products are required for every project.
15.1.2.1. Enables the product set for a particular project to be kept to a minimum.
15.1.3. Product represent an information (not files)
15.1.3.1. Product is not one to one equivalent of separate Word, Excel or any other file
15.1.4. Formality associated with each product will vary from project to project and from organisation to organisation.
15.1.4.1. a.k.a. 'Adopt and Adapt'
15.1.5. Some products are specific to a particular phase in the lifecycle, others may continue to evolve through subsequent phases. (see diagram)
15.1.6. The level of documentation required depends on the ease of communication of team members
15.1.6.1. Colocated Agile teams need less detail when writing down User Stories than distributed teams
15.1.7. Formal products definitions specifies:
15.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.
15.1.7.2. The roles that could be responsible for producing, contributing to, accepting and approving the product.
15.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.
15.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.
15.1.8. Documentation in an Agile project should be sufficient for purpose, and only that. The two golden rules of Agile documentation are
15.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)
15.1.8.2. Document in a way that is useful to the recipient (ask how this will be used, and by whom)
15.2. For people coming from non corporate environment these products may be a bit overwhelming (e.g. small projects combining only several people).
15.2.1. Remember - product is just a set a information, how you store and update this information is up to you
15.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.
15.3. For people coming from corporate environment these products are already used in most of their projects.
15.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)
15.4. "Ensure your documentation is short and sharp and make much more use of people-to-people communication." Bentley & Borman, 2001
15.5. Legend
15.5.1. Icon
15.5.1.1. This means that selected products are Gateway Products, which can be used for Yes / No decision if project should be continued
15.5.2. Orange
15.5.2.1. Business focused products
15.5.3. Green
15.5.3.1. Solution focused products
15.5.4. Blue
15.5.4.1. Management focused products
15.5.5. Evolutionary products
15.5.5.1. They typically, but not always, span a number of project phases and may be baselined more than once during that time.
15.5.6. Milestone products
15.5.6.1. Typically fulfil a specific purpose within that phase as a checkpoint or to facilitate governance processes
15.6. Pre-Project phase
15.6.1. Terms of Reference (ToR)
15.6.1.1. In real life corporate environments this product is often called Project Kick-off
15.6.1.2. Defines at a very high level the objectives and business drivers for the proposed project.
15.6.1.2.1. high-level definition of the over-arching business driver for, and top-level objectives of, the project.
15.6.1.2.2. Outlines the rationale for the project (e.g., business drivers)
15.6.1.3. The primary aim of the Terms of Reference is to scope and justify the Feasibility phase.
15.6.1.3.1. Not the whole project.
15.6.1.4. Very short document (one or two pages).
15.6.1.4.1. Can be less formal - email, verbal agreement.
15.6.1.5. Recommeded content
15.6.1.5.1. A brief outline of the business need and the objectives and scope for the project to meet that need.
15.6.1.6. Recommeded responsibilities
15.6.1.6.1. Produced by
15.6.1.6.2. Approved by
15.6.1.6.3. Produced for
15.7. Feasibility phase
15.7.1. Business Case
15.7.1.1. Describes essential business considerations that justify the project, and then are used to assess the viability of the project moving forwards.
15.7.1.2. Contains the business vision and justification for the project and requires revalidation throughout the project.
15.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.
15.7.1.3. Ought to quantify the costs and value of a project.
15.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.
15.7.1.4. Likely to describe constraints, assumptions, dependencies and risks.
15.7.1.5. Baselines of the Business Case are typically created first as an outline by the end of Feasibility.
15.7.1.5.1. Then as a basis for approval of development by the end of Foundations.
15.7.1.5.2. It is formally reviewed at the end of each Project Increment in order to determine whether further work is justified.
15.7.1.6. Recommeded responsibilities
15.7.1.6.1. Produced by
15.7.1.6.2. Approved by
15.7.1.6.3. Produced for
15.7.2. Prioritised Requirements List (PRL)
15.7.2.1. Describes, at a high level, the requirements that the project needs to address if the Business Case is to be met
15.7.2.1.1. Prioritized backlog of all requirements as derived during Feasibility and Foundations.
15.7.2.2. Baselined at a high level at the end of the Foundations phase
15.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.
15.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.
15.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.
15.7.2.3. PRL is Progressively Refined.
15.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).
15.7.2.5. Requirements formulated during Feasibility have the character of epics (i.e., outcome based high-level statements that clarify scope).
15.7.2.6. During the Foundations phase the first key non-functionals make their appearance.
15.7.2.7. PRL contains both:
15.7.2.7.1. Functional Requirements (FR)
15.7.2.7.2. Non-Functional Requirements (NFR)
15.7.2.7.3. any related job to be done
15.7.2.8. Recommeded content
15.7.2.8.1. A list of high-level requirements to be addressed.
15.7.2.8.2. A business driven prioritisation of the requirements in accordance with the MoSCoW prioritisation process.
15.7.2.9. Recommeded responsibilities
15.7.2.9.1. Produced by
15.7.2.9.2. Approved by
15.7.2.9.3. Produced for
15.7.3. Solution Architecture Definition (SAD)
15.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.
15.7.3.1.1. High-level solution design from both business and technical viewpoints.
15.7.3.1.2. Primary purpose to establish the scope for evolutionary development including desired maintainability levels.
15.7.3.2. The Solution Architecture Definition (SAD) should be created for any project where there is a systems aspect to the solution.
15.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.
15.7.3.4. Recommeded responsibilities
15.7.3.4.1. Produced by
15.7.3.4.2. Approved by
15.7.3.4.3. Produced for
15.7.4. Development Approach Definition (DAD)
15.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.
15.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.
15.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’.
15.7.4.2.1. Overview of tools, practices and standards that are to be adopted in the project.
15.7.4.3. Recommeded content
15.7.4.3.1. A definition of development practices that SDT are expected to follow.
15.7.4.3.2. All practices should be defined but as a minimum these must include:
15.7.4.3.3. A definition of any specific standards to be applied to development including, where applicable:
15.7.4.4. Recommeded responsibilities
15.7.4.4.1. Produced by
15.7.4.4.2. Approved by
15.7.4.4.3. Produced for
15.7.5. Delivery Plan
15.7.5.1. a.k.a. Release Plan
15.7.5.2. Provides an initial high-level schedule of Increments and Timeboxes and other activities for development, testing and deployment of the solution.
15.7.5.2.1. For larger projects a single high-level Delivery Plan will deal with coordination of the efforts of multiple SDT teams.
15.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.
15.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
15.7.5.4. The Delivery Plan refines and elaborates on the schedule.
15.7.5.5. Consists of 1 components
15.7.5.5.1. Schedule of Timeboxes
15.7.5.6. Recommeded content
15.7.5.6.1. The incremental nature of the project
15.7.5.6.2. The dates associated with the increments and other key milestones.
15.7.5.6.3. The dates for deployment of the solution and, where applicable, subsets of it
15.7.5.6.4. An indication of the focus of each Development Timebox
15.7.5.6.5. The timing and dependencies of any activities not planned within the Development Timeboxes
15.7.5.6.6. The allocation of resources to timeboxes and other activities
15.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
15.7.5.7. Recommeded responsibilities
15.7.5.7.1. Produced by
15.7.5.7.2. Approved by
15.7.5.7.3. Produced for
15.7.6. Management Approach Definition (MAD)
15.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.
15.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.
15.7.6.1.2. Organisational and planning aspects of the project as well as the engagement of stakeholders.
15.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.
15.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.
15.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.
15.7.6.3.1. It also describes the approach to managing Change, Configuration, Communication and Risk.
15.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.
15.7.6.5. Recommeded content
15.7.6.5.1. A validation of the Objectives and Success Criteria for the project
15.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
15.7.6.5.3. The project organisation, including roles and responsibilities, empowerment of teams and reporting lines and governance
15.7.6.5.4. Project Management controls for Monitoring and Reporting, Change Control and Risk Management
15.7.6.5.5. An overview of the key deliverables, milestones and incremental staging of product delivery
15.7.6.5.6. An analysis of major project dependencies
15.7.6.6. Recommeded responsibilities
15.7.6.6.1. Produced by
15.7.6.6.2. Approved by
15.7.6.6.3. Produced for
15.7.7. Feasibility Assessment
15.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.
15.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.
15.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.
15.7.7.4. Assessing the feasibility of the project both from a business and a technical perspective.
15.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.
15.7.7.6. Recommeded content
15.7.7.6.1. The business vision of success.
15.7.7.6.2. The scope and objectives of the proposed project.
15.7.7.6.3. High-level assumptions, dependencies and risk that may impact project viability.
15.7.7.6.4. Any alternatives that were considered and rejected.
15.7.7.6.5. The major deliverables of the proposed project.
15.7.7.6.6. A high-level description of a solution to support the Business Case.
15.7.7.6.7. An initial identification of any technical constraints to which the solution must adhere.
15.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.
15.7.7.7. Recommeded responsibilities
15.7.7.7.1. Produced by
15.7.7.7.2. Approved by
15.7.7.7.3. Produced for
15.8. Foundations phase
15.8.1. Foundations Summary
15.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.
15.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.
15.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.
15.8.1.4. Recommeded responsibilities
15.8.1.4.1. Produced by
15.8.1.4.2. Approved by
15.8.1.4.3. Produced for
15.9. Evolutionary Development
15.9.1. Evolving Solution
15.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.
15.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).
15.9.1.2. At any given time, such components may be either complete, a baseline of a partial solution, or a work in progress.
15.9.1.2.1. They include, where valuable: models, prototypes, supporting materials and testing and review artefacts.
15.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.
15.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.
15.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'.
15.9.1.4. At the end of each Project Increment the Solution Increment is deployed into live use and becomes the Deployed Solution.
15.9.1.5. Recommeded responsibilities
15.9.1.5.1. Produced by
15.9.1.5.2. Approved by
15.9.1.5.3. Produced for
15.9.2. Timebox Plan
15.9.2.1. The Timebox Plan elaborates on the objectives provided for each Development Timebox in the Delivery Plan.
15.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.
15.9.2.2. Recommeded content
15.9.2.2.1. A definition of the product(s) of an individual Development Timebox
15.9.2.2.2. An identification of key milestones, e.g. technical or user review dates, within a timebox
15.9.2.2.3. An agreed MoSCoW prioritisation of products and activities within a Development Timebox
15.9.2.2.4. An identification of all the resources (human and otherwise) required for successful completion of all work
15.9.2.3. Recommeded responsibilities
15.9.2.3.1. Produced by
15.9.2.3.2. Approved by
15.9.2.3.3. Produced for
15.9.3. Timebox Review Record
15.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.
15.9.3.1.1. However the information encompassed by the Timebox Review Record should always exist in some physical form.
15.9.3.2. The Timebox Review Record is produced / updated at the review points in the Development Timebox.
15.9.3.2.1. They describe what has been achieved and any feedback which may influence plans moving forwards.
15.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.
15.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.
15.9.3.4. Recommeded content
15.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.
15.9.3.4.2. A record of the formal acceptance of the completed deliverables by the business representatives identified to accept them.
15.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.
15.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.
15.9.3.5. Recommeded responsibilities
15.9.3.5.1. Produced by
15.9.3.5.2. Approved by
15.9.3.5.3. Produced for
15.10. Deployment phase
15.10.1. Project Review Report
15.10.1.1. Consists of 3 components
15.10.1.1.1. End of Project Assessment
15.10.1.1.2. Benefits Enablement Summary (one or more)
15.10.1.1.3. Increment Review (one or more)
15.10.1.2. Recommeded responsibilities
15.10.1.2.1. Produced by
15.10.1.2.2. Approved by
15.10.1.2.3. Produced for
15.11. Post Project phase
15.11.1. Benefits Assessment
15.11.1.1. The Benefits Assessment describes how the benefits have actually accrued, as the Deployed Solution has been used.
15.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.
15.11.1.2. Recommeded content
15.11.1.2.1. A quantitative description of how the benefits of using the Deployed Solution have been achieved.
15.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.
15.11.1.3. Recommeded responsibilities
15.11.1.3.1. Produced by
15.11.1.3.2. Approved by
15.11.1.3.3. Produced for
15.12. Summary & Conclusion
15.12.1. DSDM® is a product-based approach
15.12.1.1. This is a more effective way than simple reports, that's way DSDM® doesn't have massive number of reports.
15.12.2. Projects use delivery of the appropriate products to demonstrate progress.
16. DSDM® key techniques (7)
16.1. MoSCoW Priritisation
16.1.1. One type of relative prioritisation
16.1.2. Helps in discovering customer / users needs priorities
16.1.3. Used as a tool for always hitting deadlines (Timeboxs / Increments), by dropping requirements of lower lever priority.
16.1.4. The MoSCoW Rules
16.1.4.1. The 60:20:20 ‘rule of thumb’
16.1.4.1.1. It is just a guide – not to be taken literally
16.1.4.1.2. Less than 60% is very important
16.1.4.1.3. Understand the Minimum Usable SubseT
16.1.4.2. Must Have
16.1.4.2.1. Cannot deliver on target date without this.
16.1.4.2.2. Core requirements.
16.1.4.2.3. No point in delivering on target date without this.
16.1.4.2.4. Delivered sollution is unusable without this.
16.1.4.2.5. Not legal without it.
16.1.4.2.6. Cannot deliver the Business Case without it.
16.1.4.2.7. No more than 60% effort
16.1.4.3. Should Have
16.1.4.3.1. Important but not vital.
16.1.4.3.2. Not critical.
16.1.4.3.3. May be painful to leave out, but the solution is still viable.
16.1.4.3.4. May need some kind of workaround e.g. management of expectations, some inefficiency, an existing solution, paperwork etc.
16.1.4.3.5. Normally classed as mandatory when more time is available, but without them the business objective will still be met.
16.1.4.3.6. @ 20% effort
16.1.4.4. Could Have
16.1.4.4.1. Wanted or desirable but less important.
16.1.4.4.2. Less impact if left out (compared with a Should Have).
16.1.4.4.3. Work arounds easy/cheap
16.1.4.4.4. @ 20% effort
16.1.4.5. Won't Have (this time / maybe next time, next Timebox, next Increment)
16.1.4.5.1. These are requirements which the project team (not only SDT) has agreed it will not deliver.
16.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.
16.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.
16.1.4.5.4. Requirements are still in scope of project.
16.1.4.5.5. Out of Scope for this timeframe / Timebox / Increment.
16.1.5. DSDM® MoSCoW recommendations
16.1.5.1. Use all the priorities.
16.1.5.2. Challenge Must Haves.
16.1.5.3. By default, at beginning, everything is Won't Have.
16.1.5.3.1. Start small with Enough Design Up Front (EDUF)
16.1.5.4. Agree what the priorities mean early in the project
16.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
16.1.5.6. Agree how priorities will work
16.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.
16.1.5.6.2. Must Have definition is not negotiable.
16.1.5.6.3. Must Have will have a critical impact on the success of the project.
16.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.
16.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.
16.1.5.7. The Business Sponsor's perspective
16.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.
16.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.
16.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.
16.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.
16.1.5.7.5. Sensible prioritisation, combined with timeboxing leads to predictability of delivery and therefore greater confidence
16.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.
16.1.5.8. MoSCoW and the Business Case
16.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.
16.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.
16.1.5.8.3. A final consideration with regards to MoSCoW and the Business Case relates to the overall viability of the project.
16.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.
16.1.6. Levels of priority
16.1.6.1. A Must Have requirement for the project as a whole may not be a Must Have for the first increment.
16.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.
16.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.
16.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.
16.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.
16.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.
16.1.6.5. The priority for the project may be different to that of an increment or timebox
16.1.6.6. Understand YAGNI, KISS
16.1.6.6.1. YAGNI
16.1.6.6.2. KISS
16.1.7. What to prioritise
16.1.7.1. Every item of work has a priority.
16.1.7.1.1. Priorities are set before work commences and kept under continual review as the work is done.
16.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.
16.1.7.3. All priorities should be reviewed throughout the project to ensure that they are still valid.
16.1.8. How many of each priority?
16.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.
16.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.
16.1.9. Hierarchies of priorities
16.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).
16.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.
16.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.
16.1.9.4. A high-level Must Have requirement frequently yields a mix of sub-requirements, each with a different priority.
16.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.
16.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.
16.1.10. Tips for assigning priorities
16.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.
16.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.
16.1.10.3. 3. For each requirement that is proposed as a Must Have, ask: 'What happens if this requirement is not met?'
16.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.
16.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?'
16.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.
16.1.10.5. 5. Is there a workaround, even if it is manual?
16.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.
16.1.10.6. 6. Ask why is the requirement needed - for this project and this increment.
16.1.10.7. 7. If there is a Business Case in sufficient detail, can it be used to justify the intended priority?
16.1.10.7.1. If not, consider creating one.
16.1.10.8. 8. Is this requirement dependent on any others being fulfilled?
16.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.
16.1.10.9. 9. Allow different priorities for levels of acceptability of a requirement.
16.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.
16.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?
16.1.10.11. 11. Tie the requirement to a project objective.
16.1.10.11.1. If the objective is not a Must Have, then probably neither is the requirement relating to it.
16.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.
16.1.10.13. 13. Does the priority change with time?
16.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.
16.1.10.14. 14. Prioritise defects / bugs, using MoSCoW.
16.1.10.15. 15. Prioritise testing, using MoSCoW.
16.1.10.16. 16. Use MoSCoW to prioritise your To Do list.
16.1.10.16.1. It can be used for activities as well as requirements.
16.1.11. Summary & Concusion
16.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.
16.1.11.2. DSDM® recommends no more than 60% effort for Must Haves for a project, with 40% Shoulds and Coulds.
16.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.
16.1.12. Watch: Master the art of MoSCoW prioritisation (by Keith Richards)
16.1.13. Watch: Agile in Practice: Prioritisation using MoSCoW
16.2. Daily Stand-Up
16.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.
16.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
16.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.
16.2.3.1. Rather than writing reports and reading mails where text does not represents body language communication during F2F meetings
16.2.4. Recommended same time everyday at the same place
16.2.5. Often standing up at the Taskboard
16.2.6. Teleconference Stand-Ups (Dial-ins) may be necessary where the team is split across multiple sites.
16.2.7. Attended by all SDT members.
16.2.7.1. Possible to combine several SDTs on daily stand-up.
16.2.7.2. Has the following active participants:
16.2.7.2.1. all members of the SDT, including Business Ambassador(s)
16.2.7.2.2. any Business Advisors (BADV) actively involved in this Timebox
16.2.7.2.3. any Technical Advisors (TADV) actively involved in this Timebox
16.2.7.3. May be attended by other roles e.g.
16.2.7.3.1. The Business Visionary (BV) – in order to keep in touch with progress, to provide on-going visible support
16.2.7.3.2. The Project Manager (PM) – in order to observe progress and pick up escalated issues
16.2.7.3.3. The Technical Coordinator (TC) – in order to keep abreast of technical decisions and pick up escalated technical issues
16.2.8. Strict format
16.2.8.1. Each member describes what they’ve done since last standup.
16.2.8.1.1. Is ideally held with all participants standing in a circle by their team board
16.2.8.2. What they plan to do.
16.2.8.3. Any problems, Risks or Issues, slowing progress.
16.2.9. Short
16.2.9.1. No longer than 15 minutes (2 minutes per person).
16.2.9.2. 2 minutes per participant + 2 minutes is a good guide
16.2.10. GIFTS (goals of daily stand-ups)
16.2.10.1. Good Start
16.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"
16.2.10.1.2. Good Start means that the stand-up meeting should give energy, not take it.
16.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.
16.2.10.2. Improvement
16.2.10.2.1. "The purpose is not to meet... it is to improve." Joe Ely, "More on Daily Start-Up Meetings"
16.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.
16.2.10.2.3. Improvement is not just about problem solving though.
16.2.10.2.4. Sharing better techniques and ideas is also important.
16.2.10.3. Focus
16.2.10.3.1. Focus on the baton, not the runners
16.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.
16.2.10.4. Team
16.2.10.4.1. Effective teams are built by regularly communicating, working, and helping each other.
16.2.10.4.2. This is also strongly tied with team members helping each other with shared obstacles.
16.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.
16.2.10.5. Status
16.2.10.5.1. Status is about answering a couple questions:
16.3. Facilitated Workshops
16.3.1. Introduction
16.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.
16.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.
16.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.
16.3.1.4. Facilitated Workshops are an extremely efficient and effective way of achieving this enhanced communication.
16.3.2. Benefits
16.3.2.1. Rapid, high quality decision-making
16.3.2.1.1. Can reduce the elapsed time required to achieve objectives, such as the identification, agreement and sign-off of requirements.
16.3.2.2. Greater buy-in from all stakeholders
16.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.
16.3.2.3. Building team spirit
16.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.
16.3.2.4. Building Consensus
16.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.
16.3.2.5. Clarification of issues
16.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.
16.3.3. CSFs for Facilitated Workshops
16.3.3.1. An effective, trained, independent Workshop Facilitator.
16.3.3.2. Workshop owner
16.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
16.3.3.3. Flexibility in the format of different workshops, but clearly defined objectives.
16.3.3.3.1. Ensure that workshop participants are appropriately empowered
16.3.3.4. Thorough preparation before the workshop by Workshop Facilitator, Co-facilitator and Participants.
16.3.3.5. A mechanism for ensuring that the results of previous workshops are built in, where appropriate.
16.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
16.3.3.6. Decisions and agreements that are not forced.
16.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.
16.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).
16.3.3.7.1. Monitor that workshop outputs are appropriately recorded and circulated.
16.3.4. Further reading (outside DSDM® exams scope)
16.3.4.1. see Facilitation (based on Process Iceberg®) mind map
16.3.4.2. Facilitation - An Art, Science, Skill or all three?: Build your expertise in Facilitation
16.3.4.2.1. ISBN-13: 978-0955643507
16.3.4.2.2. Pages: 235
16.3.4.2.3. http://resourceproductions.com/books
16.3.4.3. Facilitation - A Manual of Models, Tools and Techniques for Effective Group Working
16.3.4.3.1. ISBN-13: 978-0955643514
16.3.4.3.2. Pages: 269
16.3.4.3.3. http://resourceproductions.com/books
16.4. Timeboxing (a.k.a. Sprinting from Scrum)
16.4.1. Every Timebox begins with a Kick-Off and ends with a Close-Out. Beyond this, DSDM® recognises two styles of Timebox:-
16.4.1.1. Kick-Off
16.4.1.1.1. Short session for the Solution Development Team (SDT) to understand the Timebox objectives and accept them as realistic
16.4.1.1.2. Review the Timebox objectives, as outlined in the Delivery Plan
16.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)
16.4.1.1.4. Review the availability of all members of the SDT
16.4.1.1.5. Highlight any known dependencies (internal or external) that may affect this Timebox.
16.4.1.1.6. Who
16.4.1.2. A DSDM® Structured Timebox
16.4.1.2.1. Comprises 3 main steps:
16.4.1.3. A Free Format Timebox
16.4.1.3.1. The Free Format Timebox reflects the style used by other popular Agile approaches
16.4.1.3.2. Comprises 1 step:
16.4.1.4. Close-Out
16.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.
16.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.
16.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.
16.4.1.4.4. Who
16.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
16.4.2. Summary & Comclusion
16.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.
16.4.2.2. At the lowest level, the Development Timebox maintains focus on delivery in the short term (weeks or even days).
16.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.
16.4.2.3.1. This low-level confidence feeds upwards to instil confidence at the increment and the project levels.
16.5. Iterative Development
16.5.1. Iterative Development is one of DSDM®'s key techniques.
16.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.
16.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.
16.5.2. Iterative Development cycles are typically 1 - 2 days.
16.5.3. It enables a growing understanding of the requirement and convergence on an accurate solution.
16.5.4. Focus
16.5.4.1. Requirement focus
16.5.4.1.1. Functional
16.5.4.1.2. Usability
16.5.4.1.3. Non-functional
16.5.4.2. Solution / Development focus
16.5.4.2.1. Horizontal
16.5.4.2.2. Vertical
16.5.4.2.3. Combined
16.6. Modelling
16.6.1. Modelling and Prototyping are closely linked cocepts.
16.6.1.1. A prototype is always a kind of a model.
16.6.1.1.1. In IT, prototype often refers to a funstional software but in ALPHA / BETA stage or some wireframing model
16.6.1.2. A model is not a necessary a prototype.
16.6.1.2.1. In IT, model often refers to a set of diagrams (but not a part of functional software)
16.6.2. A model is:
16.6.2.1. A simplified view of a complex reality or concept.
16.6.2.2. A description or analogy (to help visualise something that cannot be directly observed).
16.6.2.3. A small but exact copy of something.
16.6.2.4. A pattern or figure of something to be made.
16.6.2.5. Examples:
16.6.2.5.1. Storyboards
16.6.2.5.2. Storyboards
16.6.2.5.3. Flowcharts
16.6.2.5.4. Swim-lane diagrams
16.6.2.5.5. Process-models
16.6.2.5.6. UML / SysML diagrams (IT)
16.6.2.5.7. Archimate diagrams (IT)
16.6.2.5.8. OBASHI Business & IT (B&IT) diagrams
16.6.2.5.9. OBASHI Dataflow Analysis View (DAVs) diagrams
16.6.3. Models should help in determining (Viewpoints for Modelling):
16.6.3.1. Why
16.6.3.1.1. Rationale, ends and means
16.6.3.2. Where
16.6.3.2.1. Locations and Links
16.6.3.3. Who
16.6.3.3.1. People, Tasks & Responsibilities
16.6.3.4. What
16.6.3.4.1. Business procedures (Data & Relationships)
16.6.3.5. When
16.6.3.5.1. Business events, time & scheduling
16.6.3.6. How
16.6.3.6.1. Processes & Outputs
16.6.4. Modelling
16.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.
16.6.4.1.1. Significant benefits in making ideas, situations and options visible.
16.6.4.2. Modelling can range from very informal models (post-it notes on a table) to very detailed, complex models using specific notations.
16.6.4.3. These can be as different as a storyboard to represent an advertisement or a scale model of a proposed hospital.
16.6.4.4. They can be temporary, transient or throwaway or may be a prototype which forms a part of the eventual solution.
16.6.4.5. AgilePM® advocates the use of models to improve communication and to create or challenge ideas by making developing products visible.
16.6.4.5.1. Emphasis on ensuring models enhance communication.
16.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
16.6.5. Using models for the AgilePM® products
16.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.
16.6.5.1.1. Of necessity, these products are a combination of technical information, project objectives and constraints.
16.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.
16.7. Prototyping
16.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.
16.7.2. A prototype is something that serves to illustrate the typical qualities of the eventual solution
16.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)
16.7.3. A prototype in AgilePM® is a piece of work that demonstrates how a given objective can be or has been achieved
16.7.4. Disposable prototypes
16.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
16.7.4.1.1. DSDM® calls these Capability/Techniques prototypes
16.7.5. Evolutionary prototype
16.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.
16.7.5.1.1. Iterative Development technique is sometimes referred to as Prototyping
16.8. Other techniques used in Agile (not defined in DSDM® method, but can be easily implemented)
16.8.1. 10 Intristic Motivators
16.8.2. Burn-Down Chart
16.8.3. Burn-Up Chart
16.8.3.1. Watch: Agile in Practice: Burn_Up Charts
16.8.4. CHAMPFROGS
16.8.5. Circle
16.8.6. Circles of Concern and Influence
16.8.7. Facilitated Workshops
16.8.8. Feature Progress Report
16.8.9. Five dysfunctions of a team
16.8.10. Future Backwards
16.8.11. Hapiness Metric
16.8.12. Kanban wall
16.8.13. Mad, Sad, Glad
16.8.14. Perfection Game
16.8.15. Personas
16.8.16. Planning Poker
16.8.17. Predictability Measure
16.8.18. Problem -> Goal -> Advantage
16.8.19. Product / Release Burndown Chart
16.8.20. Relative Weighting
16.8.21. Run your ass off
16.8.22. Speed dating
16.8.23. Sprinting / Timeboxing
16.8.24. Starfish
16.8.25. The Sailboat
16.8.26. Theme Scoring
16.8.27. Theme Screening
16.8.28. Timeline / Emotion Graph
16.8.29. Value vs Effort Matrix
16.8.30. ...
16.9. http://retrospectivewiki.org/
16.10. http://tastycupcakes.org/
16.11. http://www.funretrospectives.com/
17. DSDM® Instrumental Success Factors (ISFs) (5)
17.1. When these factors are not met, they represent a significant risk to DSDM® approach.
17.1.1. It is important to identify these risks early and consider hot they could be mitigated.
17.2. 1. Embracing the DSDM® Approach
17.2.1. In order for DSDM® projects to be successful, project stakeholders and participants understand and accept the DSDM® project approach.
17.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.
17.3. 2. Effective Solution Development Team (SDT)
17.3.1. In order for DSDM® projects to be successful, it has to be recognized that people are at the heart of successful projects.
17.3.1.1. Solution Development Team is instrumental in ensuring the development of the right solution.
17.3.2. Building an effective team for successful delivery focuses on 4 elements:
17.3.2.1. Empowerment
17.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.
17.3.2.1.2. Business Sponsor and Visionary must agree to delegate day-to-day decision-making to Business Ambassador(s).
17.3.2.1.3. Without business empowerment team progress will slow down.
17.3.2.2. Stability
17.3.2.2.1. Solution Development Team brings together business and technical knowledge through the iterative development process.
17.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).
17.3.2.3. Skills
17.3.2.3.1. Solution Development Teams are contains skilled people, both in terms of business knowledge and technical expertise.
17.3.2.3.2. Team should also have a good communication skills and the willingness to work with others.
17.3.2.4. Size
17.3.2.4.1. DSDM suggests that the optimum Solution Development Team size is 7 +/- 2 people.
17.3.2.4.2. With such small teams, teams can communicate with one another with:
17.3.2.4.3. Bigger or smaller teams of course are possible but they can introduce risks
17.4. 3. Business Engagement - Active and On-going
17.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.
17.4.2. Ensuring active and on-going business engagement relies on 3 elements:
17.4.2.1. Commitment of business time throught
17.4.2.2. Day-to-Day collaboration involving business roles in the Iterative Development process
17.4.2.3. A supportive commercial (e.g. contractual) relationship (where appropriate)
17.5. 4. Iterative Development, Integrated Testing and Incremental Delivery
17.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,.
17.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.
17.6. 5. Transparency
17.6.1. In order for DSDM® projects to be successful, building confidence is a key aspect of DSDM® projects.
17.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.
17.6.2. Demonstrations of the Evolving Solution provide physical, objective and unquestionable proof of progress (compared with a progress report showing a subjective % complete).
17.6.3. "The great thing about fact-based decisions is that they can overrule the hierarchy." - Jeff Bezos, Amazon.com
17.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
17.7. The Project Approach Questionnaire (PAQ) - Assessing Options and Risks
17.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.
17.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.
17.7.3. PAQ is completed by Project Manager.
17.7.4. Download: DSDM® Project Approach Questionnaire (PAQ) (XLS)
18. DSDM® Process (1) with Phases (6)
18.1. Overview
18.1.1. In line with the 5 and 6 principles, the DSDM® lifecycle is both iterative and incremental.
18.1.1.1. Each phase has objectives and pre-conditions.
18.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.
18.1.1.2.1. It is sequential for Pre-project, Feasibility and Foundations.
18.1.1.2.2. Can have many iterations of Evolutionary Development.
18.1.1.2.3. Can have many separate Deployments in one project!
18.1.1.2.4. Post Project will be sequential with the last Deployment.
18.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.
18.1.1.3.1. Urgent business needs can be addressed early while less important features are delivered later.
18.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.
18.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.
18.1.1.6. It is important to keep the phases of the lifecycle visible to the SDT during the project.
18.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).
18.1.1.8. Project phases are 'building blocks' from which you are building project lifecycle. It is a framework.
18.2. DSDM® provides an iterative, incremental and adaptive framework, with 6 lifecycle phases.
18.2.1. DSDM® Project Lifecycle Phases with requirements
18.2.2. DSDM® Iterative development
18.2.3. DSDM® Project Lifecycle Phases with OGC Gated Reviews
18.2.3.1. 1. Permission to investigate an idea
18.2.3.2. 2. Permission to build a Business Case
18.2.3.3. 3. Business Case approval - go ahead
18.2.3.4. 4. Permission to test deliverables
18.2.3.5. 5. Permission to deliver
18.2.3.6. 6. Project closure
18.2.3.7. Business Case reviewed at every gate 5.
18.3. The DSDM® process model comprises a framework which shows the DSDM® phases and how they relate to one another
18.4. The process have 6 phases:
18.4.1. Pre-Project
18.4.1.1. Introduction
18.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.
18.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.
18.4.1.2. Objectives
18.4.1.2.1. To describe the business problem to be addressed.
18.4.1.2.2. To identify a Business Sponsor (BS) and Business Visionary (BV).
18.4.1.2.3. To confirm that the project is in line with business vision, mission, strategy, corporate investment porfolio.
18.4.1.2.4. To scope, plan and resource the Feasibility phase (only Feasibility phase NOT the whole project).
18.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.
18.4.1.3. Consider
18.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.
18.4.1.4. In real life corporate environments this phase is often called Project Kick-off
18.4.2. Feasibility
18.4.2.1. Introduction
18.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.
18.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.
18.4.2.2. Preconditions
18.4.2.2.1. The Terms of Reference (ToR) for the project have been approved.
18.4.2.2.2. The required resources are available to carry out the feasibility investigation.
18.4.2.2.3. The Business Visionary (BV) has sufficient time available to help shape the project.
18.4.2.3. Objectives
18.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.
18.4.2.3.2. To identify the benefits likely to arise from the delivery of the proposed solution.
18.4.2.3.3. To outline possible approaches for delivery, including strategies for sourcing the solution and project management.
18.4.2.3.4. To describe the organisation and governance aspects of the project.
18.4.2.3.5. To state first-cut estimate of timescale and costs for the project overall.
18.4.2.3.6. To plan and resource the Foundation phase.
18.4.2.4. Consider
18.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.
18.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.
18.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.
18.4.3. Foundations
18.4.3.1. Introduction
18.4.3.1.1. The Foundations phase is aimed at establishing firm and enduring foundations for the project.
18.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.
18.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.
18.4.3.2. Preconditions
18.4.3.2.1. agreement of the Feasibility Assessment (if created)
18.4.3.3. Objectives
18.4.3.3.1. To baseline the high-level requirements for the project and describe their priority and relevance to the business need
18.4.3.3.2. To describe the business processes to be supported by the proposed solution
18.4.3.3.3. To identify information used, created and updated by the proposed solution
18.4.3.3.4. To describe the strategies for all aspects of solution deployment
18.4.3.3.5. To detail the Business Case for the project
18.4.3.3.6. To start designing the solution architecture and identifying the physical or infrastructural elements of solution
18.4.3.3.7. To define technical implementation standards
18.4.3.3.8. To decribe how quality will be assured
18.4.3.3.9. To establish appropriate governance and organisation for the project
18.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
18.4.3.3.11. To baseline a schedule for development and deployment activities for the solution
18.4.3.3.12. To describe, assess and manage risk associated with the project
18.4.3.4. Consider
18.4.3.4.1. Significant business input will be required during the Foundations phase.
18.4.3.4.2. Set a time limit for the Foundations phase and try to stick to it.
18.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.
18.4.3.4.4. For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase
18.4.3.5. It may sometimes be necessary to revisit Foundations after a Deployment phase.
18.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.
18.4.3.5.2. Alternatively, the decision to revisit Foundations may be taken after a Deployment has produced an unexpected outcome.
18.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.
18.4.3.7. In case of smaller projects sometimes known as Sprint 0 in Scrum.
18.4.4. Evolutionary Development
18.4.4.1. Preconditions (for moving out of Foundations)
18.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
18.4.4.1.2. The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution
18.4.4.1.3. All required project personnel and stakeholders are engaged as necessary
18.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.
18.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.
18.4.5. Deployment
18.4.5.1. Introduction
18.4.5.1.1. The primary purpose of the Deployment phase is to get the solution into live use.
18.4.5.1.2. A secondary purpose is to act as a key review point prior to Deployment or future development work.
18.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.
18.4.5.2. Preconditions
18.4.5.2.1. The Deployable Solution has been approved for deployment
18.4.5.3. Objectives
18.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
18.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)
18.4.5.3.3. To confirm the ongoing performence and viability of the project and re-plan as required
18.4.5.3.4. To deploy the solution (or increment of it) into the live business environment
18.4.5.3.5. Training of end users and support staff
18.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)
18.4.5.3.7. An opportunity for retrospection - similar to a Sprint retrospective - but for a Release
18.4.5.3.8. A good deployment is:
18.4.5.3.9. After the final deployment:
18.4.5.4. Consider
18.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.
18.4.5.4.2. It therefore makes sense to check that investment in the rest of the planned project will provide a reasonable return.
18.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.
18.4.5.5. The release that is deployed may be the final solution, or a subset of the final solution.
18.4.5.6. Assemble
18.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.
18.4.5.7. Review
18.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.
18.4.5.8. Deploy
18.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.
18.4.6. Post-Project
18.4.6.1. Introduction
18.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.
18.4.6.2. Preconditions
18.4.6.2.1. The solution has been successfully deployed.
18.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.
18.4.6.3. Objectives
18.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
18.4.6.3.2. Mostly, the project will have been closed prior to the start of the Post-Project phase.
18.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.
18.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.
18.4.6.4. The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case.
18.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.
18.5. DSDM® project lifecycle examples
18.6. Summary & Conclusion
18.6.1. DSDM® provides an iterative and incremental framework, with 6 lifecycle phases
18.6.2. Each phase has objectives and pre-conditions
18.6.3. Specifically, each lifecycle phase will deliver Products
18.6.4. The acceptance of products enables agreement that the project can move safely from one lifecycle phase to another
18.6.5. The framework is highly configurable, depending on the size and formality of the project being delivered