Agile Business Analysis (AgileBA®) study guide mind map

1. The release that is deployed may be the final solution, or a subset of the final solution.

2. Current DSDM® Consortium products family

2.1. DSDM® Consortium products history in a nutshell

2.1.1. positioning AgileBA® in comparision to other Agile approaches

3. Phases in the DSDM® (v6) AgilePF® process (6)

3.1. Overview

3.1.1. In line with the 5 and 6 principles, the DSDM® lifecycle is both iterative and incremental.

3.1.1.1. Each phase has objectives and pre-conditions.

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

3.1.1.2.1. It is sequential for Pre-project, Feasibility and Foundations.

3.1.1.2.2. Can have many iterations of Evolutionary Development.

3.1.1.2.3. Can have many separate Deployments in one project!

3.1.1.2.4. Post Project will be sequential with the last Deployment.

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

3.1.1.3.1. Urgent business needs can be addressed early while less important features are delivered later.

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

3.1.1.5. Each lifecycle phase will deliver Products and, within AgilePM®, delivery of Products (to the appropriate and agreed level of quality) is used to assess progress.

3.1.1.6. It is important to keep the phases of the lifecycle visible to the SDT during the project.

3.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).

3.1.1.8. Project phases are 'building blocks' from which you are building project lifecycle. It is a framework.

3.2. DSDM® provides an iterative, incremental and adaptive framework, with 6 lifecycle phases.

3.2.1. DSDM® Project Lifecycle Phases with requirements

3.2.2. DSDM® Iterative development

3.3. 1. Pre-Project

3.3.1. Introduction

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

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

3.3.1.2.1. Regardless, projects need to be set up correctly from the outset to ensure success.

3.3.2. Objectives

3.3.2.1. To describe the business problem to be addressed.

3.3.2.2. To identify a Business Sponsor (BS) and Business Visionary (BV).

3.3.2.3. To confirm that the project is in line with business vision, mission, strategy, corporate investment porfolio.

3.3.2.4. To scope, plan and resource the Feasibility phase (only Feasibility phase NOT the whole project).

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

3.3.3. Consider

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

3.3.4. In real life corporate environments this phase is often called Project Kick-off

3.4. 2. Feasibility

3.4.1. Introduction

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

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

3.4.1.2.1. The Feasibility phase is intended primarily to establish whether the proposed project is likely to be feasible from a technical perspective and whether it appears cost-effective from a business perspective.

3.4.2. Preconditions

3.4.2.1. The Terms of Reference (ToR) for the project have been approved.

3.4.2.2. The required resources are available to carry out the feasibility investigation.

3.4.2.3. The Business Visionary (BV) has sufficient time available to help shape the project.

3.4.3. Objectives

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

3.4.3.2. To identify the benefits likely to arise from the delivery of the proposed solution.

3.4.3.3. To outline possible approaches for delivery, including strategies for sourcing the solution and project management.

3.4.3.4. To describe the organisation and governance aspects of the project.

3.4.3.5. To state first-cut estimate of timescale and costs for the project overall.

3.4.3.6. To plan and resource the Foundation phase.

3.4.4. Consider

3.4.4.1. If you are going to stop work on a project then it is important that you stop as early as possible.

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

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

3.4.4.3.1. The detail of the investigation happens in the Foundations phase.

3.5. 3. Foundations

3.5.1. Introduction

3.5.1.1. The Foundations phase is aimed at establishing firm and enduring foundations for the project.

3.5.1.1.1. The Foundations phase takes the preliminary investigation from Feasibility to the next level.

3.5.1.1.2. In establishing the foundations, the three essential perspectives need to be combined to provide a clear project focus that is both robust and flexible.

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

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

3.5.1.3.1. The aim of Foundations is to understand the scope of work, how it will be carried out, by whom, when and where.

3.5.2. Preconditions

3.5.2.1. agreement of the Feasibility Assessment (if created)

3.5.3. Objectives

3.5.3.1. To baseline the high-level requirements for the project and describe their priority and relevance to the business need

3.5.3.2. To describe the business processes to be supported by the proposed solution

3.5.3.3. To identify information used, created and updated by the proposed solution

3.5.3.4. To describe the strategies for all aspects of solution deployment

3.5.3.5. To detail the Business Case for the project

3.5.3.6. To start designing the solution architecture and identifying the physical or infrastructural elements of solution

3.5.3.7. To define technical implementation standards

3.5.3.8. To decribe how quality will be assured

3.5.3.9. To establish appropriate governance and organisation for the project

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

3.5.3.11. To baseline a schedule for development and deployment activities for the solution

3.5.3.12. To describe, assess and manage risk associated with the project

3.5.4. Consider

3.5.4.1. Significant business input will be required during the Foundations phase.

3.5.4.1.1. The relevant business representatives must be identified early and their level of involvement agreed.

3.5.4.2. Set a time limit for the Foundations phase and try to stick to it.

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

3.5.4.3.1. Only produce the Foundation products to the level that allows the project to move into the first exploratory development phase.

3.5.4.4. For smaller, simpler projects, the Feasibility and Foundations phases can often be merged into a single phase

3.5.5. It may sometimes be necessary to revisit Foundations after a Deployment phase.

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

3.5.5.2. Alternatively, the decision to revisit Foundations may be taken after a Deployment has produced an unexpected outcome.

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

3.5.7. In case of smaller projects sometimes known as Sprint 0 in Scrum.

3.6. 4. Evolutionary Development

3.6.1. Preconditions (for moving out of Foundations)

3.6.1.1. The Business, Solution and Management Foundations products have ben collectively accepted as provide an adequate foundation from which a solution can evolve

3.6.1.2. The environments (physical and, where appropriate, technical) are in plase and adequately set up to support the development of solution

3.6.1.3. All required project personnel and stakeholders are engaged as necessary

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

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

3.7. 5. Deployment

3.7.1. Introduction

3.7.1.1. The primary purpose of the Deployment phase is to get the solution into live use.

3.7.1.1.1. Where the end-products of the project are to be sold or distributed outside of the organisation creating it, the Deployment phase is used to get the products ready to ship.

3.7.1.2. A secondary purpose is to act as a key review point prior to Deployment or future development work.

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

3.7.2. Preconditions

3.7.2.1. The Deployable Solution has been approved for deployment

3.7.3. Objectives

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

3.7.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)

3.7.3.3. To confirm the ongoing performence and viability of the project and re-plan as required

3.7.3.3.1. The essential go/no go’ governance decision point

3.7.3.4. To deploy the solution (or increment of it) into the live business environment

3.7.3.4.1. Formal handover of the solution to operational support staff.

3.7.3.5. Training of end users and support staff

3.7.3.5.1. Where applicable, to train the end users of the solution and/or provide necessary documentation to support the live operation of the solution in the business environment

3.7.3.5.2. To train and/or provide documentation for operations and support staff who will responsible for supporting and maintaining technical aspects of the solution

3.7.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)

3.7.3.7. An opportunity for retrospection - similar to a Sprint retrospective - but for a Release

3.7.3.8. A good deployment is:

3.7.3.8.1. Predictable

3.7.3.8.2. Repeatable

3.7.3.8.3. Automatable

3.7.3.8.4. Reversable

3.7.3.8.5. Extendable

3.7.3.9. After the final deployment:

3.7.3.9.1. To formally bring the project to a close.

3.7.3.9.2. To review overall project performance from a technical and/or process perspective.

3.7.3.9.3. To review overall project performance from a business perspective.

3.7.4. Consider

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

3.7.4.1.1. The Pareto Principle (or 80:20 rule) implies that it is possible that the vast majority of the benefit might be enabled by an early interim delivery.

3.7.4.2. It therefore makes sense to check that investment in the rest of the planned project will provide a reasonable return.

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

3.7.5. The release that is deployed may be the final solution, or a subset of the final solution.

3.7.6. Assemble

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

3.7.7. Review

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

3.7.8. Deploy

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

3.8. 6. Post-Project

3.8.1. Introduction

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

3.8.1.1.1. Assessment should start as soon as the value can be measured.

3.8.2. Preconditions

3.8.2.1. The solution has been successfully deployed.

3.8.2.1.1. Phase commences after the final increment has been deployed and is chiefly concerned with an assessment over time of the benefits accrued.

3.8.2.2. After the final Deployment for a project, the Post-Project phase checks how well the expected business benefits have been met.

3.8.2.2.1. Although it may be possible to highlight immediate benefits, most benefits will accrue over a pre-defined period of live use of the solution.

3.8.3. Objectives

3.8.3.1. To assess whether the benefits described in the Business Case (where created) have actually been achieved through use of the Deployed Solution

3.8.3.2. Mostly, the project will have been closed prior to the start of the Post-Project phase.

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

3.8.3.3.1. Under such circumstances it may be appropriate to feed any proposals for change or enhancement back into the ongoing project.

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

3.8.4. The Post-Project phase produces one or more Benefits Assessments for these realised benefits in relation to the business case.

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

4. AgileBA® - a set of best prctices and guidelines for business analysts (not system analysts) working in Agile projects (especially projects running using DSDM® AgilePF® or AgilePM® methods). AgileBA® provides general (not industry specific e.g. IT or Engineering) agile business analysis gudlines. AgileBA® was created by DSDM® Consortium - www.dsdm.org

4.1. Agile Business Analysis (AgileBA™) 1st version was published in 06.2015 (with training and accreditation scheme).

5. This freeware, non-commercial mind map (aligned with the newest version of AgileBA®) was carefully hand crafted with passion and love for learning and constant improvement as well for promotion the AgileBA® best practices and as a learning tool. (please share, like and give feedback - your feedback and comments are my main motivation for further elaboration. THX!)

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

5.1.1. http://www.miroslawdabrowski.com

5.1.2. http://www.linkedin.com/in/miroslawdabrowski

5.1.3. https://www.google.com/+MiroslawDabrowski

5.1.4. https://play.spotify.com/user/miroslawdabrowski/

5.1.5. https://twitter.com/mirodabrowski

5.1.6. miroslaw_dabrowski

6. Requirements

6.1. A requirement may begin life as an idea, a need, or a statement of a problem to be addressed.

6.1.1. simply saying...

6.1.1.1. ”a service, function or feature that someone needs”

6.2. The first requirement of the project is its objective, expressed in outline in the Terms of Reference (ToR) and clarified during Feasibility.

6.2.1. Major Themes, to Epic Stories (High-level Requirements) of the Prioritised Requirements List (PRL) and down to the detailed User Stories elaborated during Exploration and Engineering.

6.3. The role of the Agile BA is to be the guardian and champion of the requirements.

6.3.1. They do not “own” the requirements (it is important that “ownership” is accepted by the business representatives).

6.4. Every requirement passes through the following stages:

6.4.1. Elicitation

6.4.1.1. Elicitation is the identification, extraction and capture of the requirement.

6.4.2. Analysis

6.4.2.1. Each requirement needs to be analysed to clarify its meaning

6.4.3. Validation

6.4.3.1. Validation applies to both the individual requirement and to the whole set of requirements for the increment and for the project.

6.4.4. Management and Documentation

6.4.5. Elicitation and Analysis run together iteratively, overlapping with Validation as the requirements become more mature.

6.5. Requirements are often classified into four categories:

6.5.1. General Business Requirements (GBRs)

6.5.1.1. The rules that all projects must adhere to e.g. business policies, legal constraints, regulatory guidelines.

6.5.2. Technical Policy Requirements (TPRs)

6.5.2.1. The technical and infrastructure policies and standards that any solution proposed must adhere to e.g. hardware and software platform, network conventions, service strategy and design.

6.5.3. Functional Requirements (FRs)

6.5.3.1. Express function or feature and define what is required. The requirements do not state how a solution will be physically achieved.

6.5.4. Non-functional Requirements (NFRs)

6.5.4.1. Define how well, or to what level, performance needs to be provided. They describe solution attributes such as security, reliability, maintainability, availability (and many other “...ilities”), performance and response time.

6.6. User Stories

6.6.1. The User Story is brief and intended to be so.

6.6.1.1. It is a placeholder for a more detailed discussion later – the Conversation.

6.6.2. In DSDM projects, User Stories are recorded in a Prioritised Requirements List (PRL).

6.6.2.1. This is the equivalent of a Product Backlog in other Agile approaches.

6.6.3. User Story – Story Card (Front)

6.6.3.1. User Stories are often deemed to comprise 3 elements – The 3 C’s.

6.6.3.1.1. Card

6.6.3.1.2. Conversation

6.6.3.1.3. Confirmation

6.6.4. User Story – Story Card (Back)

6.6.4.1. Acceptance Criteria

6.6.4.2. These are used, after development, to check that the requirement represented by the User Story has been completed satisfactorily.

6.6.4.3. They are not intended to be full test scripts but will be used to expand into the appropriate test scenarios and test scripts during Timeboxes, as necessary.

6.6.5. Well-Constructed User Stories - INVEST

6.6.5.1. Independent - User Stories should be as independent as possible from other stories, to allow them to be moved around with minimal impact.

6.6.6. Supporting acronyms

6.6.6.1. SMART (goals)

6.6.6.1.1. S - Specific

6.6.6.1.2. M - Measurable

6.6.6.1.3. A - Achievable

6.6.6.1.4. R - Realistic

6.6.6.1.5. T - Timely

6.6.6.2. INVEST (user stories)

6.6.6.2.1. by Bill Wake

6.6.6.2.2. I - Independent

6.6.6.2.3. N - Negotiable

6.6.6.2.4. V - Valuabe

6.6.6.2.5. E - Estimateable

6.6.6.2.6. S - Small / Sized appropriately

6.6.6.2.7. T - Testable

6.6.6.3. FURPS (requirements categorization)

6.6.6.3.1. by Grady and Caswell (at HP)

6.6.6.3.2. FURPS reminds you that stories can represent more than just the immediate goals a user wants to accomplish by interacting with the system - the functionality.

6.6.6.3.3. Stories technically are not requirements, they are informal expressions of customer need.

6.6.6.3.4. More than with Functionality stories, you must vet -URPS (excuse us!) candidates against INVEST characteristics of a good story

6.6.6.3.5. F - Functionality

6.6.6.3.6. U - Usability

6.6.6.3.7. R - Reliability

6.6.6.3.8. P - Performance

6.6.6.3.9. S - Supportability

6.6.6.4. 3C (user stories)

6.6.6.4.1. by Ron Jeffries

6.6.6.4.2. Card

6.6.6.4.3. Conversation

6.6.6.4.4. Confirmation

7. 5 Top Tips for Agile Business Analysts

7.1. 1. Clarify project objectives at the outset, and check alignment with organisation’s strategy

7.2. 2. Lead prioritisation, always within a timeframe and in light of the objective

7.3. 3. Assist incremental planning by asking, “What small, useful piece can we deliver early?”

7.4. 4. Respect the customer (the BA is not the customer, even by proxy!)

7.5. 5. Draw diagrams! Have a high level blueprint for the project, to enable dependencies to be seen

8. Techniques

8.1. KANO model

8.1.1. by Noriaki Kano (1984)

8.1.2. Three distinct types of customer need

8.1.2.1. Expected (which we shall refer to as “Will”)

8.1.2.2. Normal (things people just “Want”)

8.1.2.3. Exciters (which give the “Wow” factor)

8.2. Facilitated Workshops

8.2.1. Introduction

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

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

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

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

8.2.2. Benefits

8.2.2.1. Rapid, high quality decision-making

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

8.2.2.2. Greater buy-in from all stakeholders

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

8.2.2.3. Building team spirit

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

8.2.2.4. Building Consensus

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

8.2.2.5. Clarification of issues

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

8.2.3. CSFs for Facilitated Workshops

8.2.3.1. An effective, trained, independent Workshop Facilitator.

8.2.3.2. Workshop owner

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

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

8.2.3.3.1. Ensure that workshop participants are appropriately empowered

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

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

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

8.2.3.6. Decisions and agreements that are not forced.

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

8.2.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).

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

8.2.4. Workshops Roles

8.2.4.1. Owner

8.2.4.1.1. owns/sets the objectives and deliverables of the Workshop

8.2.4.1.2. budget holder for Workshop

8.2.4.1.3. could be any of the project or Solution Development Team roles

8.2.4.2. Facilitator

8.2.4.2.1. manages the process

8.2.4.2.2. neutral, impartial leader and enabler

8.2.4.3. Scribe

8.2.4.3.1. may be more than one in a Workshop

8.2.4.3.2. support the Facilitator and record results and actions, decision and/or issues

8.2.4.3.3. may be the Facilitator themselves

8.2.4.4. Participants

8.2.4.4.1. must add value

8.2.4.4.2. have knowledge, skills and experience

8.2.4.4.3. empowered to make decisions

8.2.4.5. Observer

8.2.4.5.1. optional

8.2.4.5.2. management, audit, trainee

8.2.4.5.3. non-contributing

8.2.4.5.4. must not distract the active participants

8.2.4.5.5. explain their presence to rest of the participants

8.2.5. Associated Activities

8.2.5.1. Plan the Workshop

8.2.5.1.1. Workshop Owner, with support from the Workshop Facilitator

8.2.5.2. Prepare the Workshop

8.2.5.2.1. Workshop Facilitator

8.2.5.2.2. Workshop Facilitator together with Co-facilitator(s)

8.2.5.3. Run the Workshop

8.2.5.3.1. Workshop Facilitator

8.2.5.4. Document the Workshop

8.2.5.4.1. Scribe

8.2.5.5. Follow-up

8.2.5.5.1. Workshop Owner and Participants

8.2.6. Further reading (outside AgileBA® exams scope)

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

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

8.2.6.2.1. ISBN-13: 978-0955643507

8.2.6.2.2. Pages: 235

8.2.6.2.3. http://resourceproductions.com/books

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

8.2.6.3.1. ISBN-13: 978-0955643514

8.2.6.3.2. Pages: 269

8.2.6.3.3. http://resourceproductions.com/books

8.3. Prototyping

8.4. Modelling (category)

8.4.1. Modelling and Prototyping are closely linked cocepts.

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

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

8.4.1.2. A model is not a necessary a prototype.

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

8.4.2. A model is:

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

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

8.4.2.3. A small but exact copy of something.

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

8.4.2.5. Examples:

8.4.2.5.1. Storyboards

8.4.2.5.2. Flowcharts

8.4.2.5.3. Swim-lane diagrams

8.4.2.5.4. Process-models

8.4.2.5.5. UML / SysML diagrams (IT)

8.4.2.5.6. Archimate diagrams (IT)

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

8.4.2.5.8. OBASHI Dataflow Analysis View (DAVs) diagrams

8.4.3. Models should help in determining (Viewpoints/Perspectives for Modelling):

8.4.3.1. Why

8.4.3.1.1. Rationale, ends and means

8.4.3.2. Where

8.4.3.2.1. Locations and Links

8.4.3.3. Who

8.4.3.3.1. People, Tasks & Responsibilities

8.4.3.4. What

8.4.3.4.1. Business procedures (Data & Relationships)

8.4.3.5. When

8.4.3.5.1. Business events, time & scheduling

8.4.3.6. How

8.4.3.6.1. Processes & Outputs

8.4.4. Modelling

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

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

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

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

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

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

8.4.4.5.1. Emphasis on ensuring models enhance communication.

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

8.4.5. Using models for the DSDM® products

8.4.5.1. The DSDM® framework has identified a number of products that may need to be generated by the end of each phase of the lifecycle.

8.4.5.1.1. Of necessity, these products are a combination of technical information, project objectives and constraints.

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

8.4.6. Modelling Techniques for the Agile BA

8.4.6.1. Business Canvas / Lean Canvas

8.4.6.2. Business Domain Model (Class Diagram)

8.4.6.3. Business Process Diagrams (using Swim Lanes)

8.4.6.4. Context (Scoping) Diagram

8.4.6.5. Customer Journey Mapping

8.4.6.6. Impact Mapping

8.4.6.7. Personas

8.4.6.8. Product Vision Box

8.4.6.9. Rich Picture

8.4.6.10. Specification by Example

8.4.6.11. Storyboards / Wireframes

8.4.6.12. Use Cases

8.4.6.13. User Story Mapping

8.4.6.14. Value Chain Mapping

8.5. MoSCoW

8.5.1. One type of relative prioritisation

8.5.2. Helps in discovering customer / users needs priorities

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

8.5.4. MoSCoW prioritisation is a powerful technique for helping stakeholders to understand and clearly define priorities, with a shared understanding of what the priorities mean.

8.5.5. The specific use of Must Have, Should Have, Could Have, Won’t Have this time provides a clear indication of the importance of an item and the expectations for its completion.

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

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

8.5.6.2. Less than 60% is very important

8.5.6.3. It relates to effort

8.5.6.4. Understand the Minimum Usable SubseT

8.5.6.4.1. It is guaranteed

8.5.6.4.2. Similar to minimum viable product (MVP)

8.5.6.4.3. Similar to minimum marketable feature set (MMFS)

8.5.7. Must Have

8.5.7.1. Describes a requirement that must be satisfied in the final solution for the solution to be considered a success. The assessment of business value against Must Have requirements is straightforward. By definition, they are “priceless” as far as the project is concerned. If they are omitted, the project fails.

8.5.7.2. Cannot deliver on target date without this.

8.5.7.2.1. Without these it will be unworkable and useless.

8.5.7.3. Core requirements.

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

8.5.7.4.1. Must Haves define the Minimum Usable Subset which an AgilePM® project guarantees to deliver.

8.5.7.5. Delivered sollution is unusable without this.

8.5.7.6. Not legal without it.

8.5.7.7. Cannot deliver the Business Case without it.

8.5.7.8. No more than 60% effort

8.5.8. Should Have

8.5.8.1. Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

8.5.8.2. Important but not vital.

8.5.8.3. Not critical.

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

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

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

8.5.8.7. Do not create complicated rules to define what a Should is.

8.5.8.8. @ 20% effort

8.5.9. Could Have

8.5.9.1. Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.

8.5.9.2. Wanted or desirable but less important.

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

8.5.9.4. Work arounds easy/cheap

8.5.9.5. @ 20% effort

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

8.5.10.1. Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Would" is substituted for "Won't" to give a clearer understanding of this choice).

8.5.10.2. This is not “Would like to have” nor is it “Won’t Have ever, ever, ever”

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

8.5.10.3.1. Are very difficult or costly to implement

8.5.10.3.2. Depend on external and/or uncertain factors

8.5.10.3.3. Are high risk

8.5.10.3.4. Are untested, haven’t been successfully delivered elsewhere

8.5.10.3.5. Are subject to external changes (e.g. revised legislation)

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

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

8.5.10.5.1. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.

8.5.10.6. Requirements are still in scope of project.

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

8.5.11. MoSCoW recommendations

8.5.11.1. Use all the priorities.

8.5.11.2. Challenge Must Haves.

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

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

8.5.11.4. Agree what the priorities mean early in the project

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

8.5.11.6. Agree how priorities will work

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

8.5.11.6.2. Must Have definition is not negotiable.

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

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

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

8.5.11.7. The Business Sponsor's perspective

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

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

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

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

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

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

8.5.11.8. MoSCoW and the Business Case

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

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

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

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

8.5.12. Levels of prioritisation (granularity)

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

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

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

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

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

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

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

8.5.12.6. Understand YAGNI, KISS

8.5.12.6.1. YAGNI

8.5.12.6.2. KISS

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

8.5.14. Watch: Agile in Practice: Prioritisation using MoSCoW

8.5.15. Other requirement prioritization techniques

8.5.15.1. https://en.wikipedia.org/wiki/Requirement_prioritization

8.6. INVEST

8.6.1. Attributed to Bill Wake

8.6.2. A well-written User Story will be clear, concise and complete. Some simple checks are:

8.6.2.1. It does not combine with, overlap nor conflict with other User Stories

8.6.2.2. It conforms to organisational and project standards and policies where applicable

8.6.2.3. It is traceable back to the business needs expressed in the Business Case and project objectives

8.6.3. Independent

8.6.3.1. - User Stories should be as independent as possible from other stories, to allow them to be moved around with minimal impact.

8.6.4.  Negotiable

8.6.4.1. User Stories are not a contract.

8.6.5. Valuable

8.6.5.1. User Stories should represent features which are of clear business value to the user or owner of the solution and should be written in user language. They should be features, not tasks

8.6.6. Estimable

8.6.6.1. User Stories need to be clear enough to estimate, without being too detailed

8.6.7. Small

8.6.7.1. User Stories should be small enough to be estimated.

8.6.8. Testable

8.6.8.1. User Stories need to be worded clearly and specifically enough to be testable

8.7. Stakeholder Analysis Techniques

8.7.1. RACI or RASCI Matrices

8.7.2. Power/Interest Grid

8.8. Other techniques used in Agile (not defined in AgileBA®, but can be easily implemented)

8.8.1. 10 Intristic Motivators

8.8.2. CHAMPFROGS

8.8.3. Circle

8.8.4. Circles of Concern and Influence

8.8.5. Facilitated Workshops

8.8.6. Feature Progress Report

8.8.7. Five dysfunctions of a team

8.8.8. Future Backwards

8.8.9. Hapiness Metric

8.8.10. Kanban wall

8.8.11. Mad, Sad, Glad

8.8.12. Perfection Game

8.8.13. Personas

8.8.14. Planning Poker

8.8.15. Predictability Measure

8.8.16. Problem -> Goal -> Advantage

8.8.17. Product / Release Burndown Chart

8.8.18. Relative Weighting

8.8.19. Run your ass off

8.8.20. Speed dating

8.8.21. Sprinting / Timeboxing

8.8.22. Starfish

8.8.23. The Sailboat

8.8.24. Theme Scoring

8.8.25. Theme Screening

8.8.26. Timeline / Emotion Graph

8.8.27. Value vs Effort Matrix

8.8.28. ...

9. DSDM® Team roles and responsibilities (13)

9.1. Introduction

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

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

9.1.2. The Project-level roles are

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

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

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

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

9.1.5. The Development roles are

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

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

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

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

9.1.7. The Supporting roles are

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

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

9.1.8. There may be one or more Solution Development Teams (SDTs): the membership of each team should be stable and cover all the responsibilities defined for the Development roles.

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

9.1.8.1.1. Team means:

9.2. Legend

9.2.1. Orange

9.2.1.1. Business intrest roles representing the business view

9.2.1.2. Typically taken by business personnel

9.2.2. Blue

9.2.2.1. Management intrest roles representing the management / leadership view

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

9.2.3. Green

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

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

9.2.4. Grey

9.2.4.1. Process intrest roles representing the process view

9.2.4.2. Facilitating the process aspects of the project

9.3. Role Combinations

9.3.1. Permissible Role Combinations

9.3.1.1. Combinations should not in general be considered transitive.

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

9.3.1.2. Business Sponsor + Business Visionary

9.3.1.3. Business Visionary + Business Ambassador

9.3.1.4. Team Leader + Solution Developer

9.3.1.5. Team Leader + Solution Tester

9.3.1.6. Business Advisor + Soluton Tester

9.3.2. Non Permissible Role Combinations

9.3.2.1. Business Sponsor + Project Manager

9.3.2.2. Business Visionary + Project Manager

9.3.2.3. Business Visionary + Technical Coordinator

9.3.2.4. Business Analyst + Business Ambassador

9.3.2.5. Project Manager + Team Leader

9.3.2.6. Solution Developer + Solution Tester

9.3.2.7. Workshop Facilitator + any Project level role

9.3.2.8. DSDM Coach + any SDT role

9.4. Project-level roles

9.4.1. The Project-level roles are

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

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

9.4.2. Business Sponsor (BS)

9.4.2.1. Most senior project-level role

9.4.2.1.1. the Project Champion

9.4.2.2. Project Champion who is committed to the project, to the proposed solution and the approach to delivering it.

9.4.2.2.1. This role should be committed, supportive and available for the duration of the project.

9.4.2.3. Committed to project and proposed solution

9.4.2.4. Committed to the approach for delivering the project

9.4.2.5. Provides the overall strategic direction and funding.

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

9.4.2.6.1. High enough in organisation to resolve business issues and make financial decisions

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

9.4.2.8. (ideally) There should be only one person responsible for this role.

9.4.2.8.1. On larger project or in complex organisations, the Business Sponsor's financial responsibility may be fulfilled by a higher authority such as an investment board or an executive committee.

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

9.4.2.10. Responsibilities

9.4.2.10.1. Owning the Business Case for the project

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

9.4.2.10.3. Holding the budget for the project

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

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

9.4.2.10.6. Responding rapidly to escalated issues and being the ultimate point for resolution of conflict within the project

9.4.2.10.7. Empowering the business roles within the project, to appropriate levels, within their responsibilities

9.4.2.10.8. Keeping themselves informed of progress and issues, e.g. by attending demonstrations at the end of Timeboxes and asking questions of other roles who are more actively engaged

9.4.2.11. Mappings to other roles in other methods ...

9.4.2.11.1. PRINCE2®

9.4.3. Business Visionary (BV)

9.4.3.1. Senior project-level business role.

9.4.3.2. Should be held by a single individual, since a project needs a single clear vision to avoid confusion and misdirection.

9.4.3.2.1. Single person actively involved to provide a clear vision and strategic direction.

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

9.4.3.4. More actively involved than the Business Sponsor (BS).

9.4.3.4.1. Interprets and communicates business needs of Business Sponsor (BS) and ensures these needs are represented in business case.

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

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

9.4.3.7. Remains involved throughout the project.

9.4.3.8. Providing the team with strategic direction.

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

9.4.3.10. In real life Business Visionary (BV) is often Product Manager

9.4.3.11. Responsibilities

9.4.3.11.1. Defining the business vision for the project.

9.4.3.11.2. Communicating and promoting the Business Vision to all interested and/or impacted parties

9.4.3.11.3. Monitoring progress of the project in line with the Business Vision

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

9.4.3.11.5. Contributing to key requirements, design and review sessions (in Timeboxes), particularly where aspects of the solution being considered address key elements of the business vision

9.4.3.11.6. Identifying and owning business-based risk

9.4.3.11.7. Defining, and approving changes to, the high level requirements in the Product Backlog; i.e. any change that affects the baselined scope or significantly alters the balance of priorities.

9.4.3.11.8. Ensuring collaboration across stakeholder business areas within the scope of the project

9.4.3.11.9. Ensuring business resources are available to the project as needed

9.4.3.11.10. Promoting the translation of the business vision into working practice, i.e. ensuring full business adoption of the solution created by the project.

9.4.3.11.11. Empowering the business roles within Solution Development Team, to appropriate levels, within their responsibilities.

9.4.3.11.12. Where the Solution Development Team cannot agree, acting as a arbiter of business differences related to the business need and the way this is addressed in the Evolving Solution.

9.4.3.11.13. ... in general governing WHAT

9.4.3.12. Mappings to other roles in other methods ...

9.4.3.12.1. PRINCE2®

9.4.4. Technical Coordinator (TC)

9.4.4.1. Technical authority for project, providing the technical vision.

9.4.4.2. Technical architecture design authority.

9.4.4.2.1. A good architecture should provide consistent guidelines to system development.

9.4.4.2.2. A good architecture should include all the high-level decisions made to address the systemic quality requirements / non functional requirements (NFR)

9.4.4.2.3. Characteristics of a Good Architecture

9.4.4.3. Ensures technical consistency and coherence across SDTs.

9.4.4.4. Ensures adherence to agreed standards.

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

9.4.4.5.1. Advising on technical decisions and innovation.

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

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

9.4.4.7. Responsibilities

9.4.4.7.1. Agreeing and controlling the technical architecture.

9.4.4.7.2. Determining the technical environments.

9.4.4.7.3. Advising on and co-ordinating each team's technical activities.

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

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

9.4.4.7.6. Ensuring adherence to appropriate standards or best practice.

9.4.4.7.7. Controlling the technical configuration of the solution.

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

9.4.4.7.9. Resolving technical differences between technical team members.

9.4.4.7.10. ... in general governing HOW

9.4.4.8. Mappings to other roles in other methods ...

9.4.4.8.1. PRINCE2®

9.4.4.8.2. Disciplined Agile Delivery (DAD)

9.4.5. Project Manager (PM)

9.4.5.1. Delivery focused

9.4.5.2. Provides high-level Agile-style leadership to Solution Development Team(s)

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

9.4.5.3. Focuses on managing the working environment for evolving the solution.

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

9.4.5.4.1. Coordinates high-level management aspects of project

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

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

9.4.5.7. Team Leaders (TL) often do AgilePM® PM role in small projects

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

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

9.4.5.9. Responsibilities

9.4.5.9.1. Project Managers (PM) with very strong personal control needs can also encounter difficulties in executing AgilePM® projects.

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

9.4.5.9.3. Performing high level project planning and scheduling, but not detailed / Timebox planning

9.4.5.9.4. Monitoring progress against the baselined project and increment plans

9.4.5.9.5. Managing risk and any issues as they arise, or are escalated from the Solution Development Team(s), collaborating with senior business and / or technical roles as required to ensure resolution

9.4.5.9.6. Attending Daily Stand-Ups, as an observer, to keep a current understanding of progress and issues

9.4.5.9.7. Managing the overall configuration of the project

9.4.5.9.8. Project Managers (PM) need to protect the development teams from external interruptions.

9.4.5.9.9. Motivating and ensuring empowerment of the Solution Development Team(s) to meet their objectives

9.4.5.9.10. Coaching the SDTs when handling difficult situations.

9.4.5.9.11. Managing business involvement within the SDTs.

9.4.5.9.12. Resourcing Specialist Roles as required.

9.4.5.10. Mappings to other roles in other methods ...

9.4.5.10.1. PRINCE2®

9.4.6. Business Analyst (BA)

9.4.6.1. Fully integrated with SDT.

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

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

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

9.4.6.5. Responsibilities

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

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

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

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

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

9.5.1. The Development roles are

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

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

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

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

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

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

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

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

9.5.4.1. Also known as “T-Shaped” people

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

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

9.5.6. Solution Development Teams are:

9.5.6.1. Empowered

9.5.6.1.1. A SDTs have to be empowered to make decisions if the rate of pace of development and delivery is to be kept high.

9.5.6.1.2. "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

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

9.5.6.2. Self-directed / Self-disciplined

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

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

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

9.5.6.3. Self-organizing

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

9.5.6.3.2. Style of working

9.5.6.3.3. Who is needed on the team and not

9.5.6.3.4. When it needs help resolving Impediments

9.5.6.3.5. Needed process improvements

9.5.6.3.6. Technology practices

9.5.6.3.7. Techniques

9.5.6.3.8. Who does what and when

9.5.6.3.9. Self-organizing rarely means self-managing

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

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

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

9.5.6.4. Self-aware

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

9.5.6.5. Self-sufficient

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

9.5.6.6. No hierarchy within the team

9.5.6.6.1. No bosses or managers.

9.5.6.7. Cross-functional

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

9.5.6.8. Small (7 +/- 2)

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

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

9.5.6.9. Autonomical

9.5.6.9.1. Yet SDTs do not work in a vacuum.

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

9.5.6.9.3. External Autonomy

9.5.6.9.4. Internal Autonomy

9.5.6.9.5. Individual Autonomy

9.5.6.10. Accountable

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

9.5.6.11. Collaborative

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

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

9.5.6.12. Based on trust and respect

9.5.6.12.1. Trust but verify and then guide

9.5.6.13. Ideally static

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

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

9.5.6.14. Ideally collocated

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

9.5.6.14.2. Collocated mentally not only phisically.

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

9.5.6.15. Team means:

9.5.6.15.1. T - Together

9.5.6.15.2. E - Everyone

9.5.6.15.3. A - Achieves

9.5.6.15.4. M - More

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

9.5.7.1. Agile Project Management and Scrum V2 pocketbook

9.5.7.1.1. ISBN-13: 978-0992872793

9.5.7.1.2. Pages: 62

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

9.5.8. Team Leader (TL)

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

9.5.8.2. Leadership rather than management.

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

9.5.8.4. Reporting to the Project Manager (PM).

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

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

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

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

9.5.8.8. Mappings to other roles in other methods ...

9.5.8.8.1. PRINCE2®

9.5.9. Business Ambasador (BAMB)

9.5.9.1. similar to Product Owner in Scrum

9.5.9.2. similar to Customer in XP

9.5.9.3. Key business representative within Solution Development Team

9.5.9.3.1. A true “ambassador”.

9.5.9.4. Business role within the SDT.

9.5.9.5. Working closely with the rest of the SDT.

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

9.5.9.7. Guides the evolution of the solution.

9.5.9.8. Generally comes from the business area being addressed.

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

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

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

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

9.5.9.12. Stress key nature of this role.

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

9.5.9.13.1. Can quickly become a bottleneck for the team.

9.5.9.14. During Foundations

9.5.9.14.1. Provides significant input into creation and prioritisation of requirements

9.5.9.15. During Evolutionary Development

9.5.9.15.1. Provides day-to-day detail

9.5.9.15.2. Main decision-maker to ensure Evolving Solution is fit-for-purpose to meet business need

9.5.9.16. Responsibilities

9.5.9.16.1. Contributing to all requirements, design and review sessions

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

9.5.9.16.3. Providing the detail of business scenarios to help define and test the solution being developed

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

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

9.5.9.16.6. Organising and controlling business acceptance testing of the solution

9.5.9.16.7. Developing business user documentation for the ultimate solution

9.5.9.16.8. Ensuring user training is adequately carried out

9.5.9.16.9. Attending the daily team meetings

9.5.10. Business Analyst (BA)

9.5.10.1. Fully integrated with SDT.

9.5.10.1.1. Not an intermediary between Business Ambassador (BAMB) and team

9.5.10.1.2. Supports communication between the business and the SDT

9.5.10.2. Facilitates relationship between business and technical roles

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

9.5.10.4. Ensures accurate, appropriate day-to-day decisions about the Evolving Solution

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

9.5.10.6. They do not “own” the requirements (it is important that “ownership” is accepted by the business representatives).

9.5.10.7. Responsibilities

9.5.10.7.1. Assisting the Business Visionary (BV) in the formulation and promotion of the Business Vision

9.5.10.7.2. Modelling the organisation’s current and future state in the area of the solution and identifying opportunities, risks and impacts

9.5.10.7.3. Working with the Business Visionary (BV) and the Business Ambassador (BAMB) to formulate and communicate solution options

9.5.10.7.4. Working with the Project-Team roles in formulating the Business Case, and organising Benefits Assessments

9.5.10.7.5. Supporting and facilitating unambiguous and timely communication between business and technical participants in the project

9.5.10.7.6. Ensuring the requirements are of good quality and are analysed and managed appropriately

9.5.10.7.7. Ensuring that the business and organisational implications of day-to-day evolution of the solution are properly modelled and thought through

9.5.10.7.8. Ensuring the impact of business decisions is reviewed in the context of the project

9.5.10.7.9. Ensuring the business and technical components of the solution collectively provide a cohesive whole for the business

9.5.10.7.10. Liaising with the Business Visionary in organising support for the solution through implementation into live use

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

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

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

9.5.10.9. see AgileBA® mind map

9.5.11. Solution Developer (SD)

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

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

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

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

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

9.5.11.5. Responsibilities

9.5.11.5.1. Works collaboratively with Business Ambassador and other Solution Developers and Testers

9.5.11.5.2. Undertakes Iterative Development of the deployable solution

9.5.11.5.3. Adheres to technical constraints laid out in the Solution Foundations

9.5.11.5.4. Participates in quality assurance work to ensure products are fit for purpose

9.5.11.5.5. Tests their own output prior to independent testing

9.5.12. Solution Tester (ST)

9.5.12.1. Fully integrated with the SDT.

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

9.5.12.3. Ensure quality solution.

9.5.12.4. Independence of testing is key.

9.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).

9.5.12.6. Responsibilities

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

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

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

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

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

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

9.5.12.7. Mappings to other roles in other methods ...

9.5.12.7.1. eXtreme Programming (XP)

9.5.12.7.2. Disciplined Agile Delivery (DAD)

9.6. Supporting Roles

9.6.1. The Supporting roles are

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

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

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

9.6.2. Business Advisor (BADV)

9.6.2.1. Often a peer of the Business Ambassador (BAMB).

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

9.6.2.3. Often user or beneficiary of the solution.

9.6.2.3.1. A potential user of a solution under development.

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

9.6.2.4.1. Expert knowledge of some aspect of legislation of business rules with which the solution must comply.

9.6.2.5. Working within boundaries of the business vision defined by the Business Visionary (BV), Business Advisors (BADVs) are responsible for helping the Business Ambassador shape the requirements in the PRL, providing depth and detail of the business need and expected characteristics of the solution under development.

9.6.2.6. Responsibilities

9.6.2.6.1. Providing specialist advice on, or help with:

9.6.2.6.2. Providing specialist input into relevant:

9.6.2.7. Mappings to other roles in other methods ...

9.6.2.7.1. Disciplined Agile Delivery (DAD)

9.6.3. Technical Advisor (TADV)

9.6.3.1. Technical equivalent of a Business Advisor (BADV).

9.6.3.2. Supports SDT.

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

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

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

9.6.3.5.1. IT Security Expert

9.6.3.5.2. IT Security Consultatant

9.6.3.5.3. Business Continuity Expert

9.6.3.5.4. Risk Manager (from organization)

9.6.3.5.5. Support

9.6.3.6. Responsibilities

9.6.3.6.1. Providing specialist advice on, or help with:

9.6.3.7. Mappings to other roles in other methods ...

9.6.3.7.1. Disciplined Agile Delivery (DAD)

9.6.4. Workshop Facilitator (WF)

9.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))

9.6.4.2. Independent from project team and client.

9.6.4.2.1. Independent of workshop outcome.

9.6.4.3. Managing the workshop process.

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

9.6.4.5. Catalyst for preparation and communication.

9.6.4.6. Responsibilities

9.6.4.6.1. For each workshop:

9.6.4.6.2. Engaging with participants to:

9.6.4.7. Download: What Do We Mean By Facilitation

9.6.5. DSDM Coach (DC)

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

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

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

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

9.6.5.5. Responsibilities

9.6.5.5.1. Providing detailed knowledge and experience of DSDM® / AgilePM® to inexperienced agile teams

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

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

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

9.6.5.5.5. Building DSDM® / AgilePM® capability within the team

10. DSDM® (v6) AgilePF® method Principles (8)

10.1. Principles are universally applicable statements.

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

10.1.2. They provide guidance to organizations.

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

10.2.1. A way of thinking and working.

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

10.3.1. It increases risk.

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

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

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

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

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

10.5.2.1. You must start with the end in mind

10.5.2.2. You need to know exactly where you are going

10.5.2.3. The business case is your best friend

10.5.2.4. This will take you a long time to do

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

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

10.5.2.7. TIP

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

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

10.5.3.1. A lot of being agile is about options

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

10.5.3.3. Choose the right person above the right skill set

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

10.5.3.5. You need collaboration and team spirit.

10.5.3.6. TIP

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

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

10.5.4.1. This is counter intuitive

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

10.5.4.3. Build from firm foundations

10.5.4.4. You must avoid analysis paralysis

10.5.4.5. Try and spot early solutioneering.

10.5.4.6. TIP

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

10.5.5. No. 4: Look backwards to go forwards

10.5.5.1. Learn your lessons – both good and bad

10.5.5.2. Evolve the process – it has to evolve

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

10.5.5.4. Try this! - Review, Plan, Do

10.5.5.5. Share your experiences with other teams.

10.5.5.6. TIP

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

10.5.6. No. 5: Change is great!

10.5.6.1. You need to anticipate change and embrace it

10.5.6.2. This allows a more accurate solution to result

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

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

10.5.6.5. TIP

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

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

10.5.7.1. Command and control may not work with Agile

10.5.7.2. Facilitation is a core competency

10.5.7.3. Big ears, big eyes, small mouth

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

10.5.7.5. This will give you ownership.

10.5.7.6. TIP

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

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

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

10.5.8.2. Meten is weten – to measure is to know

10.5.8.3. Start now – build a metrics database

10.5.8.4. Keep it simple to start with

10.5.8.5. Calibrate your estimates.

10.5.8.6. TIP

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

10.5.9. No. 8: Use fat communication channels

10.5.9.1. Shift the communication traffic to bigger pipes

10.5.9.2. The written word is a silent killer

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

10.5.9.4. Go visual

10.5.9.5. Use workshops.

10.5.9.6. TIP

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

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

10.5.10.1. Continuously manage external risks

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

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

10.5.10.4. Get the team involved

10.5.10.5. Be ‘a bit of a worrier’.

10.5.10.6. TIP

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

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

10.5.11.1. Time focus is your greatest weapon

10.5.11.2. Force the issue – understand your condition

10.5.11.3. Timeboxes not milestones

10.5.11.4. If you are going to fail – fail early

10.5.11.5. Prioritise with MoSCoW – it should be natural.

10.5.11.6. TIP

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

10.6. 1 - Focus on the business need

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

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

10.6.1.1.1. Solution products are more important than documentation

10.6.2. Understand true business priorities

10.6.3. Establish valid business case

10.6.3.1. There is a formal document called Business Case

10.6.4. Ensure continuous business sponsorship and commitment

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

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

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

10.6.5. Guarantee delivery of the Minimum Usable Subset of requirements

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

10.6.5.1.1. see MoSCoW prioritization

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

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

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

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

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

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

10.6.7. Principle supported by:

10.6.7.1. Roles

10.6.7.1.1. Business Sponsor (BS)

10.6.7.1.2. Business Visionary (BV)

10.6.7.2. Products

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

10.6.7.3. Techniques

10.6.7.3.1. MoSCoW

10.6.7.3.2. Timeboxing

10.7. 2 - Deliver on time

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

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

10.7.2. Timebox the work into manageable chunks of time.

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

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

10.7.2.1.2. DO NOT EVER EXTEND TIMEBOX!

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

10.7.3.1. Question each decision

10.7.4. Always hit deadlines

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

10.7.4.1.1. You can increade / decrease quality

10.7.4.1.2. You can increase / decrease risk

10.7.4.1.3. You can increase / decrease benefits

10.7.4.1.4. You can add / remove resources

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

10.7.4.2. Build confidence through predictable delivery and maintain reputation

10.7.4.2.1. QDOS - Quality Delivery of Service

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

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

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

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

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

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

10.7.6.1. UTH rule (rule not law)

10.7.6.1.1. Units, Tens and Hundreds

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

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

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

10.7.7. Principle supported by:

10.7.7.1. Roles

10.7.7.1.1. Project Manager (PM)

10.7.7.1.2. Team Leader (TL)

10.7.7.2. Techniques

10.7.7.2.1. MoSCoW

10.7.7.2.2. Timeboxing

10.8. 3 - Collaborate

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

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

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

10.8.3. Encourage pro-active involvement from the business representatives

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

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

10.8.4.1.1. Power to the people!

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

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

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

10.8.6. Actively involve business

10.8.6.1. Business involvment in every day

10.8.6.2. Done by Business Ambassador (BAMB) role

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

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

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

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

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

10.8.10.1. a.k.a. "fatware"

10.8.10.2. a.k.a. "shelfware"

10.8.10.3. a.k.a. "zombieware"

10.8.10.4. ...

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

10.8.12. People want to be part of something

10.8.13. Recommended co-location

10.8.14. Solution Development Teams are:

10.8.14.1. Empowered

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

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

10.8.14.2. Self-directed / Self-disciplined

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

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

10.8.14.3. Self-organizing

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

10.8.14.3.2. Style of working

10.8.14.3.3. Who is needed on the team and not

10.8.14.3.4. When it needs help resolving Impediments

10.8.14.3.5. Needed process improvements

10.8.14.3.6. Technology practices

10.8.14.3.7. Techniques

10.8.14.3.8. Who does what and when

10.8.14.3.9. Self-organizing rarely means self-managing

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

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

10.8.14.4. Self-aware

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

10.8.14.5. Self-sufficient

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

10.8.14.6. No hierarchy within the team

10.8.14.6.1. No bosses or managers.

10.8.14.7. Cross-functional

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

10.8.14.8. Small (7 +/- 2)

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

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

10.8.14.9. Autonomical

10.8.14.9.1. Yet SDTs do not work in a vacuum.

10.8.14.10. Accountable

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

10.8.14.11. Collaborative

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

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

10.8.14.12. Based on trust and respect

10.8.14.13. Ideally static

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

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

10.8.14.14. Ideally collocated

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

10.8.14.14.2. Collocated mentally not only phisically.

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

10.8.15. Principle supported by:

10.8.15.1. Roles

10.8.15.1.1. Business Sponsor (BS)

10.8.15.1.2. Business Visionary (BV)

10.8.15.1.3. Business Ambassador (BAMB)

10.8.15.1.4. Solution Development Teams (SDTs)

10.8.15.1.5. Workshop Facilitator (WF)

10.8.15.2. Techniques

10.8.15.2.1. Facilitated Workshops

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

10.9. 4 - Never compromise quality

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

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

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

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

10.9.2.2.1. All increments have the same level of quality

10.9.3. Ensure that quality does not become a variable

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

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

10.9.3.1.2. no "gold plating"

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

10.9.4.1. Everything is tested as early as possible.

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

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

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

10.9.4.3. Build in quality by constant review

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

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

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

10.9.6. Fail fast.

10.9.6.1. "fail fast, learn fast"

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

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

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

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

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

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

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

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

10.9.8. Principle supported by:

10.9.8.1. Roles

10.9.8.1.1. Solution Tester (ST)

10.9.8.2. Products

10.9.8.2.1. Testing products

10.9.8.3. Techniques

10.9.8.3.1. MoSCoW

10.9.8.3.2. Timeboxing

10.9.8.3.3. Daily Stand-ups

10.9.8.4. Early and integrated testing

10.9.8.5. Regular reviews throughout lifecycle

10.10. 5 - Build incrementally from firm foundation

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

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

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

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

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

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

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

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

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

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

10.10.4.2.1. Momentum is built.

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

10.10.5. Increments deployed into operational use for early ROI

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

10.10.7. Continually confirm the correct solution is being built.

10.10.8. Implement this principle using DSDM® lifecycle

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

10.10.10. Principle supported by:

10.10.10.1. Techniques

10.10.10.1.1. Iterative Development

10.10.10.2. DSDM® Lifecycle

10.11. 6 - Develop iteratively

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

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

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

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

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

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

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

10.11.3.2.1. Iterative approach on all projects

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

10.11.3.2.3. This means that DSDM® project lifecycle is iterative

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

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

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

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

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

10.11.6. Accept most detail emerges later rather than sooner.

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

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

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

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

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

10.11.10. Principle supported by:

10.11.10.1. Techniques

10.11.10.1.1. Iterative Development

10.11.10.1.2. Timeboxing

10.11.10.1.3. Prototyping

10.11.10.1.4. Modelling

10.11.10.2. Iteration and constant review

10.12. 7 - Communicate continuously and clearly

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

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

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

10.12.3. Run daily stand-ups sessions

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

10.12.4. Use workshops, with a facilitator where appropriate

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

10.12.6. Demonstrate the Evolving Solution early and often

10.12.7. Keep documentation lean and timely.

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

10.12.9. Always aim for honesty and transparency in all communication

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

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

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

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

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

10.12.13. Principle supported by:

10.12.13.1. Roles

10.12.13.1.1. Workshop Facilitator (WF)

10.12.13.2. Techniques

10.12.13.2.1. Facilitated workshops

10.12.13.2.2. Daily Stand-ups

10.12.13.3. Clearly defined roles

10.12.13.4. User and business involvement

10.12.13.5. Team empowerment

10.12.13.6. Models and prototypes

10.13. 8 - Demonstrate control

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

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

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

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

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

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

10.13.3. Make plans and progress visible to all.

10.13.3.1. Even to lowest level team members.

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

10.13.5. Manage proactively

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

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

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

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

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

10.13.10. Principle supported by:

10.13.10.1. Roles

10.13.10.1.1. Project Manager (PM)

10.13.10.1.2. Team Leader (TL)

10.13.10.2. Products

10.13.10.2.1. Management Foundations

10.13.10.2.2. Timebox Plans

10.13.10.3. Techniques

10.13.10.3.1. Timeboxing

10.13.10.4. Constant review with client and users

10.14. Summary & Conclusion

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

10.14.1.1. Iterative

10.14.1.2. Incremental

10.14.1.3. Adaptive

10.14.1.4. Empirical

10.14.1.5. Change-driven

10.14.2. The right business solution is delivers because

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

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

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

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

10.14.2.5. DSDM® does not compromise quality

11. Stakeholders

11.1. The key factors in communicating with Stakeholders within an Agile project.

11.2. Three types of stakeholders

11.2.1. External

11.2.1.1. e.g. Project Manager, Agile BA, Business Ambassador, Solution Developer, Solution Tester, Team Leader, Technical Advisor, Business Advisor, Business Sponsor, Business Visionary, Technical Coordinator

11.2.2. Business

11.2.2.1. e.g. Business Ambassadors, Business Advisors, Business Sponsors and Business Visionaries who are also Project Stakeholders

11.2.3. Project

11.2.3.1. e.g. customers, suppliers, competitors, partners, industry regulators, external auditors, industry professional bodies, trade associations.

11.3. Power/Interest Grid

11.3.1. This helps to ensure that the importance of different stakeholders is appreciated and that stakeholders are appropriately involved and communicated with during a project.

11.4. Personas

11.4.1. A Persona is the human role of an “actor” in our solution.

11.4.2. User Stories and Use Cases can be linked together into usage scenarios which describe real world examples of one or more of the typical people who will interact with the solution.

11.4.3. Creating a Persona involves identifying each potential user of the solution, and considering them as a real person, or category of person, including their likes, dislikes, concerns and needs.

12. DSDM® Philosophy (1)

12.1. DSDM® vs Traditional Project Variables

12.1.1. Project Variables - Traditional and DSDM®.

12.1.1.1. Deliver on time.

12.1.1.2. Deliver on budget.

12.1.1.3. Guarantee to meet quality standards.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.2. The DSDM® philosophy

12.2.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.3. 6P Model (a.k.a. DSDM “temple”)

12.3.1. Philosophy

12.3.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.3.2. Principles

12.3.2.1. Eight principles articulate the core elements of the philosophy

12.3.3. Process

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

12.3.4. People

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

12.3.5. Products

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

12.3.6. Practices

12.3.6.1. Structured techniques and activities

12.4. Philosophy is achieved when all stakeholders

12.4.1. Understands and buy into the business vision and objectives

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

12.4.3. Collaborate to deliver a fit for purpose business solution

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

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

12.5. 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.1. The 8 principles are themself supported by people, Agile process, clearly defined products and recommended practices

12.5.1.1. Thanks to the philosophy, principles, configurable lifecycle, products, roles, and key practices of DSDM® greatly reduces the risk of building the wrong solution, and the final solution is more likely to meet the user’s real business requirements, so users are more likely to claim ownership of the solution.

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. AgileBA® Official publications

13.1. Agile Business Analysis Handbook

13.1.1. http://www.dsdm.org/product/agileba-business-analysis-handbook

14. Techniquies for understanding the Business Environment

14.1. External analysis techniques (2)

14.1.1. PESTLE Analysis

14.1.1.1. PESTLE is a mnemonic which in its expanded form denotes P for Political, E for Economic, S for Social, T for Technological, L for Legal and E for Environmental.

14.1.1.2. This concept is used as a tool by companies to track the environment they’re operating in or are planning to launch a new project/product/service etc.

14.1.1.2.1. It gives a bird’s eye view of the whole environment from many different angles that one wants to check and keep a track of while contemplating on a certain idea/plan.

14.1.1.3. There are certain questions that one needs to ask while conducting this analysis, which give them an idea of what things to keep in mind. They are:

14.1.1.3.1. What is the political situation of the country and how can it affect the industry?

14.1.1.3.2. What are the prevalent economic factors?

14.1.1.3.3. How much importance does culture has in the market and what are its determinants?

14.1.1.3.4. What technological innovations are likely to pop up and affect the market structure?

14.1.1.3.5. Are there any current legislations that regulate the industry or can there be any change in the legislations for the industry?

14.1.1.3.6. What are the environmental concerns for the industry?

14.1.2. Porter’s Five Forces Analysis

14.1.2.1. This is useful, because it helps you understand both the strength of your current competitive position, and the strength of a position you're considering moving into. 

14.1.2.2. Five Forces Analysis assumes that there are five important forces that determine competitive power in a business situation. These are:

14.1.2.2.1. Supplier Power:

14.1.2.2.2. Buyer Power:

14.1.2.2.3. Competitive Rivalry:

14.1.2.2.4. Threat of Substitution:

14.1.2.2.5. Threat of New Entry:

14.1.2.3. Further reading

14.1.2.3.1. http://www.mindtools.com/pages/videos/five-forces-transcript.htm

14.1.2.3.2. http://www.mindtools.com/pages/article/newTMC_08.htm

14.2. Internal analysis techniques (9)

14.2.1. MOST Analysis

14.2.1.1. M.O.S.T. analysis is used to analyse the internal environment and, ideally, to change internal culture and processes for the better.

14.2.1.2. MOST is an analysis framework that helps you avoid this trap by checking whether the MOST elements – Mission, Objectives, Strategies, and Tactics – are in alignment.

14.2.1.3. Vision

14.2.1.3.1. This is your organization's purpose, in terms of its values or how it goes about doing business. It should inspire staff, and help customers understand why they would want to use the company's products or services.

14.2.1.4. Mission

14.2.1.4.1. This is also your organization's purpose, but expressed in terms of key measures that must be reached to achieve your vision.

14.2.1.5. Objectives

14.2.1.5.1. These are specific goals that you must meet to achieve the mission.

14.2.1.6. Strategy

14.2.1.6.1. This is the overall plan you'll follow to meet your objectives.

14.2.1.7. Tactics

14.2.1.7.1. These are specific sets of actions needed to execute your strategy.

14.2.2. Resource Audit

14.2.2.1. This analysis identifies the organisation’s strengths and weaknesses and provides input into the next technique of SWOT analysis.

14.2.2.2. Identifies an organisation’s strengths and weaknesses:

14.2.2.2.1. Financial resources e.g. assets

14.2.2.2.2. Physical resources e.g. buildings

14.2.2.2.3. Human resources e.g. skills, flexibility

14.2.2.2.4. Reputation e.g. Brand Recognition

14.2.2.2.5. "Know How" e.g. Patents, exploitation of technology

14.2.3. SWOT Analysis

14.2.3.1. Structured planning method used to evaluate the strengths, weaknesses, opportunities and threats involved in a project or in a business venture.

14.2.3.1.1. Strengths: characteristics of the business or project that give it an advantage over others.

14.2.3.1.2. Weaknesses: characteristics that place the business or project at a disadvantage relative to others.

14.2.3.1.3. Opportunities: elements that the project could exploit to its advantage.

14.2.3.1.4. Threats: elements in the environment that could cause trouble for the business or project.

14.2.3.2. SWOT analysis groups key pieces of information into two main categories:

14.2.3.2.1. internal factors

14.2.3.2.2. external factors

14.2.3.3. Further reading

14.2.3.3.1. http://www.mindtools.com/pages/videos/SWOT-analysis-transcript.htm

14.2.3.3.2. http://www.mindtools.com/pages/article/newTMC_05.htm

14.2.4. Boston Box

14.2.5. TOWS Analysis

14.2.5.1. TOWS Analysis is a variant of the classic business tool, SWOT Analysis.

14.2.5.1.1. TOWS and SWOT are acronyms for different arrangements of the words Strengths, Weaknesses, Opportunities and Threats.

14.2.5.2. By analyzing the external environment (threats and opportunities), and your internal environment (weaknesses and strengths), you can use these techniques to think about the strategy of your whole organization, a department or a team.

14.2.5.3. For each combination of internal and external environmental factors, consider how you can use them to create good strategic options:

14.2.5.3.1. Strengths and Opportunities (SO) – How can you use your strengths to take advantage of these opportunities?

14.2.5.3.2. Strengths and Threats (ST) – How can you take advantage of your strengths to avoid real and potential threats?

14.2.5.3.3. Weaknesses and Opportunities (WO) – How can you use your opportunities to overcome the weaknesses you are experiencing?

14.2.5.3.4. Weaknesses and Threats (WT) – How can you minimize your weaknesses and avoid threats?

14.2.6. Porter’s Value Chain

14.2.6.1. A value chain breaks an organisation down into its strategically valuable activities in order to understand the costs and sources of product and service differentiation.

14.2.6.2. The organisation can then aim to gain competitive advantage by performing these strategic activities more cheaply or better than its rivals.

14.2.6.3. A linked concept is the value stream, which is an end-to-end collection of activities that creates value for a customer.

14.2.6.3.1. This concept is found in lean manufacturing.

14.2.7. Lean thinking

14.2.7.1. Lean thinking links closely to the concept of delivering value. It is based on theory and practice developed for manufacturing and emphasises the removal of waste. Waste, often called “Muda” (a Japanese term) refers to everything which is not of value to the customer (internal and external).

14.2.7.2. The Lean approach advocates the following 5 principles:

14.2.7.2.1. Specify what creates value from a customer’s perspective

14.2.7.2.2. Identify all steps across the whole value chain

14.2.7.2.3. Make those actions happen that create the value flow

14.2.7.2.4. Make what is “pulled” (demanded or triggered) by the customer happen just in time

14.2.7.2.5. Strive for perfection by continually removing successive layers of waste

14.2.8. Leavitt's Diamond

14.2.9. The McFarlan’s matrix on the strategic importance of IT

14.3. Techniques for measuring the success of implementing change (2)

14.3.1. The McKinsey's 7S Model/Framework

14.3.1.1. The basic premise of the model is that there are seven internal aspects of an organization that need to be aligned if it is to be successful.

14.3.1.2. This model proposes that organisations are subject to these seven inter-related aspects

14.3.1.3. The 7-S model can be used in a wide variety of situations where an alignment perspective is useful, for example, to help you:

14.3.1.3.1. Improve the performance of a company.

14.3.1.3.2. Examine the likely effects of future changes within a company.

14.3.1.3.3. Align departments and processes during a merger or acquisition.

14.3.1.3.4. Determine how best to implement a proposed strategy.

14.3.1.4. Explaining each of the elements specifically:

14.3.1.4.1. Strategy

14.3.1.4.2. Structure

14.3.1.4.3. Systems

14.3.1.4.4. Shared Values

14.3.1.4.5. Style

14.3.1.4.6. Staff

14.3.1.4.7. Skills

14.3.1.5. Further reading

14.3.1.5.1. http://www.mindtools.com/pages/videos/7s-transcript.htm

14.3.1.5.2. http://www.mindtools.com/pages/article/newSTR_91.htm

14.3.2. The Balanced Business Scorecard

14.3.2.1. Strategic management system that helps organization translates its strategies into objectives that drive both behaviour and performance. Both financial and non-financial.

14.3.2.2. Measures are designed to track the progress of objectives against targets.

14.3.2.3. Financial

14.3.2.3.1. Share value, profit, revenue, cost of capital, debt, ROA, cash flow.

14.3.2.4. Customer

14.3.2.4.1. Market share, customer satisfaction, customer service, number of contracts, KYC, customer due diligence, number of claims.

14.3.2.5. Internal

14.3.2.5.1. Regulatory compliance, number of incidents, centralized data, process optimization.

14.3.2.6. Growth

14.3.2.6.1. Competitive advantage, reputation.

14.3.2.7. Further reading

14.3.2.7.1. http://www.mindtools.com/pages/article/newLDR_85.htm

15. Requirement prioritization

15.1. Other requirement prioritization techniques

15.1.1. https://en.wikipedia.org/wiki/Requirement_prioritization

16. The Agile Business Case

16.1. Types of Business Case

16.1.1. Project

16.1.2. Strategic

16.2. Business Canvas/Lean Canvas

16.2.1. A Business Canvas, or Lean Canvas, is a template that allows the consideration of the big picture of a business, or business area, on a single page.

16.2.2. This model assists in the production of the Business Case and clarification of the Business Vision.

16.2.3. It helps to define the product or service which the project is to produce and includes a high level stakeholder analysis.

16.3. Product Vision Box

16.3.1. The “Product Vision Box”, first proposed by Bill Shackleford, is a useful technique when starting a project, to help to create a shared vision of the objectives and expected outcome of the project between key stakeholders.

16.3.2. The stakeholders work together in small groups to create a visual, concrete image of the software, product or service which they are about to develop

16.3.2.1. The final result is always a single box, although several intermediate boxes may emerge during the workshop, as the group converges on a common understanding of their goal.

16.3.3. For the box, the group will usually consider:

16.3.3.1. Front:

16.3.3.1.1. Name

16.3.3.1.2. Picture or drawing

16.3.3.1.3. A slogan or “strap-line” for the product (e.g. Coca Cola, “the real thing”)

16.3.3.1.4. Unique selling points

16.3.3.2. Back, sides, top, bottom:

16.3.3.2.1. A more detailed view

16.3.3.2.2. Pre-requisites

16.3.3.2.3. Benefits

16.3.3.2.4. Warranty

16.3.3.2.5. Cost

16.3.3.2.6. Version number

16.3.3.2.7. Warnings and constraints (e.g. Sell-by date)

16.3.3.2.8. Instructions:

16.3.3.2.9. How to use