Accelerated Delivery Method Iteration 1 RC · Web viewSee more on this and other topics at . Agile...

Accelerate your project

February 2016

Material on this website is protected by copyright. Unless otherwise stated in relation to specific content, copyright in material on this website is owned by the Department of Internal Affairs on behalf of the Crown and is licensed for re-use under the Creative Commons Attribution 3.0 New Zealand licence . In essence, under this licence you are free to copy, distribute and adapt such content and material, as long as you attribute it to the Department of Internal Affairs and abide by the other licence terms. Please note that this licence does not apply to any logos, emblems and trade marks on the website or to the website’s design elements, which may not be re-used without express permission. Where applicable, this website identifies specific copyright content that is owned by a third party and/or is subject to any licence or other terms in addition to (or in place of) the Creative Commons Attribution 3.0 New Zealand licence referred to above. Your use of that content is subject to those terms.

http://creativecommons.org/licenses/by/3.0/nz/

http://creativecommons.org/licenses/by/3.0/nz/

ContentsOverview............................................................................................................................4

Introduction....................................................................................................................... 4Accelerate phases.............................................................................................................. 8Which projects are good candidates for Accelerate?.........................................................9How to use this toolkit.....................................................................................................10Key terms used in Accelerate...........................................................................................11Tailoring Accelerate..........................................................................................................18Hot tips.............................................................................................................................23Agile development processes...........................................................................................25

Phase 1. Prepare...............................................................................................................27Introduction to Prepare....................................................................................................27Getting started.................................................................................................................30Unpack the problem or opportunity................................................................................31Align with strategic priorities...........................................................................................32Determine the benefits....................................................................................................34Identify who is responsible...............................................................................................35Outline the strategic response.........................................................................................37Choose the path forward.................................................................................................39Present the case...............................................................................................................40Preparing for Discover......................................................................................................42

Phase 2. Discover..............................................................................................................44Introduction to Discover..................................................................................................44Explore the business ecosystem.......................................................................................47Elaborate the customer view...........................................................................................49Elaborate the product......................................................................................................51Engage the coalition of the willing...................................................................................54Elaborate the solution architecture.................................................................................56Elaborate the business case.............................................................................................58Gain project approval.......................................................................................................60Preparing for Alpha..........................................................................................................61

Page

Phase 3. Alpha...................................................................................................................62Introduction to Alpha.......................................................................................................62Preparing to sprint (sprint zero).......................................................................................65Product grooming............................................................................................................ 68Release planning..............................................................................................................70Sprint................................................................................................................................71Business change management.........................................................................................73

Phase 4. Beta....................................................................................................................75Introduction to Beta.........................................................................................................75Releasing the product......................................................................................................78Tracking the releases’ progress........................................................................................79

Phase 5. Live.....................................................................................................................80Introduction to Live..........................................................................................................80Customer acquisition....................................................................................................... 82Benefits realisation...........................................................................................................83Enhancing the product platform......................................................................................84

Phase 6. Grow...................................................................................................................85

Page

Overview

IntroductionImportant Please read all of this overview, and then refer to the sections for each

phase as required.

Intended audience

This toolkit has been created for:

managers wanting to invest in improving their service or business capability

managers and team members involved in an Accelerate project.

Contacts Contact [email protected] for help or feedback.

What is Accelerate?

Accelerate is a scalable framework of tools bought together in a high-level process to support faster delivery of benefits, using a multi-function team from several disciplines, including policy, technology, development and assurance. It supports rapid design, prototyping, testing, and learning for improved citizen centred experiences.

Existing delegated authority, responsibilities and accountabilities continue to apply, including the Treasury investment management processes.

It incorporates proven techniques from a number of disciplines to support a project from the point when the opportunity is identified, through to maximising the benefits of the completed working product.

Why use Accelerate?

Using Accelerate can help projects to:

define the opportunity and benefits incorporate customer-centred service design create a roadmap for evolving the product over time ensure projects align with cross-agency strategic priorities identify business benefits and appropriate business changes make cross-agency collaboration and coordination easier deliver the most valuable components to customers and

investors earlier and in working form identify opportunities for cross-agency common capabilities.

Page 3

mailto:[email protected]

Accelerate can reduce delays

Accelerate includes the following processes, which can reduce delays:

establishing a multi-discipline team across policy, delivery, and technology

adopting a simplified governance environment considering pre and post-delivery phases to optimise work flow using agile techniques during development and release coordinating the cross-agency release of integrated services.

Assurance Accelerate projects need to follow the all-of-government assurance guidance provided on ICT projects and programmes available at www.ict.govt.nz (search for project assurance).

This guidance encourages tailoring assurance processes to match the risks and value of the project.

Risk management

The following features in Accelerate (including agile development) mitigate common risks associated with traditional project methodologies:

frequent engagement of customers during design and development

prioritization of high value work for early delivery short inspect and adapt cycle clear definitions of ‘done’ high engagement of the team with the business via the product

owner small frequent iterations automated testing test-driven design explicit review and management of technical data prototyping of solution components cross functional teams - many perspectives delivery of working systems.

Page 4

http://www.ict.govt.nz/

What makes Accelerate different?

Accelerate uses approaches for managing projects that can deliver benefits safely and reduce delays.

Accelerate is flexible, and builds on the natural increase of information as a project progresses, so more decision making is based on real information, rather than on predictions. In this approach, changes are welcome.

This compares with traditional project management methods, where the details of a project are approved and locked in before the work begins, using assumptions which are based on the available information. In these methods, change is minimised and carefully managed.

Accelerate facilitates better financial control as it delivers the product in smaller and more frequent working releases, so the Project Board is able to reprioritise investment at the end of each release.

Background For many years agencies have been providing public services and carrying out projects following well-understood methods, largely independent of each other.

Recently a number of new methods have become available that have been shown to improve how public services and projects can be delivered.

The Government has identified delivering better public services within tight financial constraints as one of its top priorities. This and the Government’s ICT Strategy place new demands on Government agencies:

a focus on customer-centred services greater collaboration between agencies shorter time to realising benefits investing in common ICT capabilities.

Research undertaken with project managers and sponsors indicates there is significant opportunity to improve the current project environment.

The GCIO’s team has developed Accelerate as an approach to organise and support projects delivering customer-centred services that are enabled by technology.

Page 5

Accelerate’s phases

Accelerate has six phases – Prepare, Discover, Alpha, Beta, Live, and Grow (see Accelerate phases on page Error: Reference source not found). These phases are divided into stages that describe the main tasks that need to be considered.

Figure 1: Accelerate’s phases

This toolkit describes each phase including its:

stages goals possible techniques.

The techniques come from successful projects of varying size and complexity.

What is Accelerate based on?

Accelerate is based on the successful Government Service Design Manual (see www.gov.uk/service-manual).

Their approach has been tailored to the New Zealand environment and includes:

proven customer service design techniques (NZ Government Service Design Guideline), architecture techniques (the Government Enterprise Architecture for New Zealand v3.0, GEA-NZ Data and Information Reference model and Taxonomy v3.0, TOGAF and ArchiMate®), and agile project delivery techniques.

benefits planning and change management to Discover, Alpha, and Live

the Grow phase, to support co-ordinated investment planning for cross-agency common capabilities.

Page 6

http://www.gov.uk/service-manual

Accelerate phasesAccelerate is made up of six phases, summarised below.

Prepare The purpose of Prepare (page 26) is to:

clearly identify the problem or opportunity engage stakeholders and align the project with their

investment objectives identify a sponsor for the change.

Discover The purpose of Discover (page 44) is to:

identify the most valuable customer and stakeholder needs explore the root causes, constraints and critical success

factors build a coalition of the willing to support the change create the business case for the investment.

Alpha The purpose of Alpha (page 62) is to:

build the product in increments, according to the product roadmap and the release plan created during Discover.

Beta The purpose of Beta (page 75) is to:

release the product to market coordinate the multi-agency release.

Live The purpose of Live (page 80) is to:

add customers to the customer base add capacity to the platform monitor the performance of the product start benefits realisation activities (benefits owner).

Grow The purpose of Grow (page 85) is to:

progress the product capability based on customer feedback and continuous improvement processes.

Page 7

Which projects are good candidates for Accelerate? Deciding to use Accelerate

The sponsor (senior responsible officer), together with the GCIO’s team, chooses whether to apply Accelerate to projects that they consider have the required features and support.

The use of Accelerate is not mandated. The characteristics of projects that fit well with Accelerate are described below.

Accelerate projects

Accelerate is:

for projects (including projects that are part of programmes), rather than programmes

designed to support multiple agencies collaborating to achieve common customer service goals.

Potential Accelerate projects

A potential Accelerate project is one that will:

deliver benefits to customers (New Zealanders and/or the Government)

contribute to the Government’s strategic outcomes have:

○ buy-in from the participating agencies○ high technology reuse potential○ future value.

Accelerate is scalable, and can be used for a project with a single team of three people, up to cross-agency projects involving several teams.

Best use Accelerate is best used when:

there is a clear customer service outcome which involves a technology change

there is uncertainty in the outcome, change in the details of the features is likely, and variability in the delivered scope can be tolerated – it is not suited to life or death issues, fixed-scope or fixed-price contracts, or when scope variance cannot be tolerated

high levels of engagement with the business leaders can be sustained throughout the project.

Page 8

Accelerate unsuitable for…

Accelerate is not for situations where:

the outcome is predominantly a technology change with low customer involvement

the initiative involves life or death issues, fixed-scope or fixed-price contracts, or when cost variance cannot be tolerated

the outcome requires a programme approach the outcome is predominantly and organisational change or

design.

Accelerate is not a substitute for Better Business Cases, or investment management processes such as risk profile assessment.

How to use this toolkit Follow the phases, choose your tools

All the Accelerate phases and stages are considered in every project.

However, the effort and formality for each stage needs to reflect the project’s size, complexity and uncertainty.

Effective use of Accelerate relies on the sponsor and project manager using their judgement (with the assistance of an Accelerate navigator) to decide which tools will best benefit the project, and to what depth to complete the stages.

How to start The Accelerate quick start guide supports project managers and sponsors getting a project underway as soon as possible. It is available on the Accelerate downloads page. This covers:

Starting (also in the Getting started section of Prepare) Tailoring Accelerate (also in this overview) Hot tips (also in this overview).

The quick start guide is intended to be used initially, and then once things are underway in Prepare, the project manager or sponsor needs to refer to the main guide to get more context and more detailed information about Prepare, and the other phases.

Most roles used during Accelerate are described in the glossary (available on the Accelerate downloads page). More detailed descriptions of the architecture owner, and product owner are given in Key terms used in Accelerate on page 10 , as they are likely to be less familiar in the Accelerate environment.

Page 9

Key terms used in Accelerate Some key terms used in Accelerate that may be less familiar to the sponsor and project manager that are explained below are:

architecture owner architecture runway product owner project space.

Architecture owner

What is an architecture owner?

The architecture owner is:

part of the project’s core team responsible for facilitating the development of the product’s

architecture.

When is an architecture owner required?

Architecture owners are needed for complex or large solutions, when the development teams are unable to anticipate the complexities outside their immediate environment, or understand every aspect of the entire system.

Assigning an architecture owner:

supports the ability to respond to changes to the solution as more information is available

reduces the production of redundant or conflicting features.

Architecture owner’s responsibilities

The Architecture Owner’s responsibilities are listed below.

Across project life:

understanding the IT strategy and standards ensuring the solution is fit for purpose understanding and applying required information security

controls to the solution developing an architecture runway supporting the product

roadmap making scope vs quality trade-off decisions for the team carrying out agreed assurance activities supporting the sponsor to socialise and convey the project

vision and intent to the team and primary stakeholders, along with the product owner

Continued…

Page 10

Architecture owner’s responsibilities (continued)

communicating the emerging solution design with technical review boards

contributing to the:

○ assurance plan and risk register○ business operating model○ product release roadmap○ product release board(s)

understanding and applying enterprise technical standards assessing changes to the scope for assurance implications, and

recording the decisions and their rationale in a project log

During development:

organising milestone reviews participating in project planning, daily stand up meetings,

reviews, retrospectives, sprint and release planning providing input to the feature analysis and discussion during

sprint planning considering the readiness of the IT services to accept the

change, prior to approving the release for Live, along with the product owner

reviewing test results prior to the approval of sprint deliverables with the product owner

providing input to the product owner when they are determining whether to approve the release of sprint deliverables

working closely with the change manager to ensure alignment of release and change management activity

liaising with the IT owner regarding the release’s IT change management

reviewing issues raised in testing during Alpha and Beta, and ensuring suitable remediation plans are established, with the product owner.

Page 11

Architecture documentation requirements during development (Alpha and Beta)

In Accelerate, the architecture is developed in iterations that are presented to stakeholders. These descriptions of the solution are intended to:

align designs across teams synchronize iterations between teams communicate the description of the solution to support teams

(for example, security, technical operations, quality, assurance, or privacy).

In an agile environment, the suitable level of architecture documentation is the minimum amount necessary for current discussions with the intended audience. A critical part of this is provided by the architecture runway (see below).

Principles for architecture owner

Principles that guide the architecture owner include:

1. Collaboration – the architecture owner works collaboratively with the team to develop and evolve the architecture, benefiting from inclusion of a range of viewpoints.

2. Empowering the team – 70% of skills development occurs on the job, so architecture owners and other team members with more skills and experience share their skills.

3. Reducing complexity and uncertainty – the architecture owner identifies areas of technical complexity in the architecture, and addresses them. This may involve setting up an architectural prototype.

4. Communication – the architecture owner communicates decisions and guidelines (including coding standards, database, security, and control objectives) to the team. They also communicate the description of the solution to stakeholders as part of reviews.

5. Ensuring the solution’s integrity – the architecture owner reviews the product backlog and the completed product increments to ensure the integrity of the product and the overall system.

Page 12

Architectural runway

Architectural runway

An architectural runway:

is the responsibility of the architecture owner is a forward-looking view of the product’s architecture, the

capabilities it needs, and the product increments that will provide them

plans capabilities just in time for uninterrupted deployment of new business features to customers

is recommended for managing technical complexity in agile projects.

Architectural runway and the product roadmap

The architecture runway aligns with the product roadmap created by the product owner. It considers the changes in IT components needed to realise the customer benefits and creates a plan to deliver them. The architecture runway forms the “bottom half” of the product roadmap as it describes the changes needed to provide the customer benefits described in the top half. A draft example from the BABII project is available on the Accelerate downloads page.

Product owner

The product owner is:

a member of the ‘core team’, along with the project manager, and architecture owner (and scrum master during development)

the stakeholders’ representative on the team, and vice versa the voice of the customer accountable for ensuring that the team delivers value to the

business and the customer.

Page 13

Communication and the product owner

Communication is a main function of the product owner, and the engagement of the product owner with the development team and stakeholders is extensive.

The communication tasks of the product owner to the stakeholders include:

communicating between the team and stakeholders demonstrating the solution to key stakeholders announcing releases communicating team status organising milestone reviews educating stakeholders in the development process negotiating priorities, scope, funding, and schedules communicating the product vision, strategy, roadmap, and

releases to relevant parties.

Key relationships

The product owner’s key relationships are:

internally:

○ architecture owner○ business owner○ business representatives○ benefits owner○ business analysts○ project managers○ lead solution analysts○ architects○ testing

externally:

○ external service providers○ provider, vendor representatives○ other government agencies.

Page 14

General responsibilities

The product owner’s general responsibilities include:

ensuring the solution provided is fit for purpose for the business

carrying out agreed assurance activities prioritising features and user stories making scope versus quality trade-off decisions for the team

with the architecture owner liaising with the benefits owner regarding change

management and benefits management developing the product vision and strategy co-authoring the business operating model with the sponsor

and the stakeholders working with the sponsor to define the business acceptance

criteria working with the change manager and architecture owner to

ensure alignment of release and change management activity contributing to and approving the product roadmap and

product release board(s) ensuring the product backlog is visible, transparent, and clear.

Development responsibilities

The product owner’s responsibilities during development (Alpha and Beta) include:

reviewing test results prior to the approval of sprint deliverables, with the architecture owner

reviewing issues raised in testing during Alpha and Beta and ensuring suitable remediation plans are established for risk accepted issues, with the architecture owner

participating in daily stand up meetings, reviews, retrospectives, sprint and release planning

provide input to the feature analysis and discussion with the team during sprint planning

approving the sprint deliverables at the sprint review meeting with input from the architecture owner

refining the product backlog.

Page 15

Project space

A project space is a dedicated physical area for:

some or all of the team to work in organising and displaying project materials team meetings.

The main benefits of a project space are that it:

enables the team to collaborate and communicate more effectively and efficiently

allows project information to be displayed visually helping with processing, organising and communicating information.

The importance of co-location is discussed in the Hot tips section on page 22.

Page 16

Tailoring AccelerateFollow the phases, choose your tools

All the Accelerate phases and stages are considered in every project.

However, the effort and formality for each stage needs to reflect the project’s size, complexity and uncertainty.

Effective use of Accelerate relies on the sponsor and project manager using their judgement to decide which tools will best benefit the project, and to what depth to complete the stages.

Goal of tailoring Accelerate

The goal of tailoring Accelerate is to apply a level of project management and control that:

does not overburden the project, and provides an appropriate level of oversight given the risk,

complexity and significance of the project.

Using navigators

The GCIO’s team can identify Accelerate coaches and navigators who can help you choose the best path forward.

After you read through this section, contact the GCIO’s team at [email protected] to locate a navigator or an Accelerate coach.

How to tailor Accelerate

The first step for the project manager or sponsor when tailoring the approach is to determine the complexity of the problem, the certainty of the outcome and approach, and the possible impact of the project. They need to consider:

achieving things is straightforward when they are well understood – even if they are complex

even straightforward things can be a challenge - if you’re unsure what to do next

when the impact is high it is wise to take extra care – even when you know what to do.

Possible factors to consider are given in Table 1.

Table 1: Factors to consider when tailoring Accelerate

Complexity factors Outcome uncertainty factors Effect factors

Process The degree of variability in the

process and business rulesOrganisational Change The number of agencies and

branches involved The degree to which the

project is changing attitudes and behaviours

Customer Our level of understanding

of the high value features Our level of understanding

of the customer journeys Our level of understanding

of the customer groupsOrganisation Level of understanding of

Organisational impact The extent of the

project impact on the operations of the branch or agency

How constrained is the project end date?

Financial size Size of project budget

Page 17

mailto:[email protected]

Complexity factors Outcome uncertainty factors Effect factors

Multi-disciplinary The number of business groups

involved in the delivery The range of resources

requiredStakeholders The number of stakeholders

involved The degree of divergence

between stakeholder goalsTechnical The number of technical

systems requiring change or integration

The level of legacy system involvement in the product

the processes involved Degree of change required

for the processProject The predictability of project

and resource costs Level of understanding of

the system componentsResources Availability of appropriate

skills and resources Availability of relevant

previous experience Availability of relevant

knowledge of the system

The level of financial commitment post- project

Customer impact The extent of the

project impact on the customers

Political impact The political

significance of the outcome

The team Typical roles in an Accelerate support team include:

a team leader representatives of the customer(s) and stakeholder(s) the team to analyse and develop the product people responsible for the:

○ assurance○ architecture○ policy○ benefits planning and realisation○ customer service.

How many of each role (and whether some may be combined) depends on the nature and quality of the product being created, and the time available.

An indicative team structure is given in the introductions for Prepare, Discover, Alpha and Beta.

Page 18

Engaging future critical roles

The following resources need to be identified by the end of Prepare so they can be engaged for subsequent work:

the core team (when practicable, this team will include the members of the Prepare team):

○ product owner○ architecture owner○ project manager

key personnel (the larger or more complex the project, the greater level of experience required – see Table 2):

○ Accelerate navigator or coach○ assurance contact○ EPMO contact.

Table 2: Requirements for personnel

Factor Response

Complex stakeholder landscape More experienced project manager and sponsor

Complex technical landscape More experienced architecture owner and technical leads

Complex operations and product

More experienced product owner

Larger team More experienced project manager

Inexperienced team More experienced project managerMore engagement with navigator and subject matter coaches

Contact people for communication in supporting teams also need to be established, for example in EPMO, Assurance, SDLC groups, Security, ICT review boards.

Considering complexity and uncertainty

The size effect The size of the project amplifies the effect of complexity and uncertainty. The larger the potential impact, the more formal the recommended approach and communication.

As a matrix Accelerate can be tailored to address varying levels of uncertainty and complexity (see Figure 2). Each of the quadrants is discussed below.

Page 19

Figure 2: Accelerate’s approaches to complexity and outcome uncertainty

High complexity, high uncertainty

When the assessment shows the project and its business ecosystem will be complex, and the path forward is uncertain, consider:

separating the project into smaller, simpler components and taking more steps to build the total solution

using more rigorous and formal analysis tools to research the evidence

setting up more formal engagement and communication processes with stakeholders

engaging stakeholders in planning and benefits planning with frequent updates as more information becomes available.

The following are strongly advised:

strong governance and external assurance adherence to methodology experienced leaders and team members.

Page 20

High complexity, low uncertainty

When the assessment shows the project and its business ecosystem will be complex, and the path forward is certain:

use:

○ workshop approaches with larger groups from multiple areas○ more formal documentation○ wider socialisation of the workshop output

make sure the problem statement is clear take care with stakeholder communications and commitment consider using prototypes to research areas of business and

technical complexity.

The following are recommended:

external assurance more formal project governance an experienced project team.

Low complexity, high uncertainty

When the assessment shows the project and its business ecosystem will be simple, and the path forward is uncertain, consider:

multiple smaller workshops with a variety of groups to explore the situation and share insights and materials with the team

several prototypes.

Low complexity, low uncertainty

When the assessment shows the project and its business ecosystem will be simple and the path forward is certain, consider using:

an early release of the first MVP, and with quick iterations based on customer feedback

less formal methods of analysis and communication lighter Governance and assurance activities simpler project documentation.

Page 21

Hot tips

Get an agile or Accelerate coach, or a navigator

Using coaches and navigators is strongly recommended in Accelerate.

In Accelerate, a ‘coach’, including an agile or Accelerate coach, is someone with experience who can mentor less experienced practitioners.

An Accelerate ‘navigator’ is someone who has been specifically trained to support the sponsor, project manager and other core roles who are using (or deciding whether to use) the Accelerate framework.

Where to find a coach

To find an agile coach, approach the professional services of (in preferred order):

the lead agency other participating agencies other stakeholders.

To find an Accelerate coach or navigator:

ask the Accelerate support team (details on the Accelerate landing page).

Collaboration and the business case

How to get buy-in

When multiple agencies are involved in the outcome, it is important to engage the agencies’ representatives in developing the business case. A jointly-created business case that reflects their voice and objectives along with those of the lead agency will be agreed more quickly than one where it is developed in isolation.

The hurdles Common reactions to the urgency created by deadlines are to:

reduce the emphasis on collaboration reduce the scope of the material considered.

These actions:

bias the business case towards the lead agency’s concerns weaken the group commitment and endorsement of the

investment lengthen the negotiation period for business case approval.

Page 22

The importance of co-location

Co-location is important in Accelerate. Ideally, the whole team will all be located in the same place – not just the same office, but literally sitting side by side. This may cause some inconvenience, and require management intervention in order to achieve it, but it is worth it.

Why is co-location important?

Having co-located teams:

reduces coordination overheads speeds up communication fosters closer working relationships, and creates the

opportunity for continuous collaboration enables face-to-face communication ensures progress boards are visible to the whole team strengthens team spirit increases the immediately available knowledge.

These factors, over the course of a project, can make or break it.

Co-location benefits

The benefits of co-location are:

fewer misunderstandings when people talk with each other, compared with phone calls or written communication

conversations can occur immediately individuals become a team by being in the same space while

working on something together. Also any team issues become clear earlier, and can be resolved earlier.

So co-location means:

more shared understanding fewer work blockages becoming more efficient as a team greater information sharing.

More information

See more on this and other topics at www.allaboutagile.com/5-reasons-why-agile-development-must-be-driven-from-the-top.

Page 23

http://www.allaboutagile.com/5-reasons-why-agile-development-must-be-driven-from-the-top

http://www.allaboutagile.com/5-reasons-why-agile-development-must-be-driven-from-the-top

Agile development processesAgile, scrum, and Accelerate

This toolkit incorporates agile development techniques during Alpha and Beta, and more specifically focuses on scrum, as it is most commonly applied and widely understood.

Other agile techniques such as Kanban, extreme programming, and feature- or test-driven development, may be used in Accelerate, as well as more traditional development methods, such as waterfall.

This toolkit is not meant to be a training manual for agile or scrum, but rather to give brief descriptions of their techniques so the wider audience can understand the processes within Accelerate.

Features of agile methods

This Accelerate toolkit describes agile development methods (usually scrum) including:

short iterations (sprints) that deliver release-ready product increments every 3 or 4 weeks using a co-located team

building up a minimum viable product (MVP) through iterative product releases following the product roadmap

adding product features described in user stories prioritising the work backlog by the product owner following

the shortest path to greatest value (for customers and investors), leading to best use of the available budget on the features of greatest value

exit ramps available after each product release, allowing the project to stop with a working system at the end of a release

clear definition of done, to ensure quality is reviewed with the product owner or stakeholders at the end of each sprint.

Agile manifesto and principles

The agile manifesto and principles are available at www.agilemanifesto.org.

Evidence for agile’s success

Surveys have confirmed repeatedly over the last seven years that agile projects have higher success rates when compared with traditional approaches, for example:

Agile projects are successful three times more often than non-agile projects (2011 CHAOS report from the Standish Group).

Page 24

http://www.agilemanifesto.org/

Figure 3: Comparative success rates for waterfall and agile projectsSource: The CHAOS Manifesto, the Standish Group 2012

Agile methods have a 64% success rate, compared to 49% for the waterfall model (www.ambysoft.com)

Agile methods were more successful when considering product quality, functionality, return on investment and time/schedule – see Figure 4 (www.ambysoft.com).

Figure 4: Comparison of methodologiesSource: DDJ2008 Project success survey (copyright ©Scott Ambler)

Page 25

http://www.ambysoft.com/surveys/success2008

http://www.ambysoft.com/surveys/success2008

Phase 1. Prepare

Introduction to Prepare

Prepare stages pg Description

Getting started Error: Reference sourcenotfound

Start the project preparation

Unpack the problem or opportunity

31 Describe the opportunity or problem overview

Align with strategic priorities 32 Align the project with the agencies’ strategic priorities

Determine the benefits 34 Identify the potential benefits of the project

Identify who is responsible 35 Allocate the key roles and responsibilities

Outline the strategic response 37 Decide on the high level intention of the project

Choose the path forward 39 Choose the most appropriate method

Present the case 40 Present the business case for proceeding to Discover

Preparing for Discover Error: Ref

Set up the processes that will support the next stages

Page 26

Prepare stages pg Description

Purpose The purpose of Prepare is to:

test the problem or opportunity to see if it is worth investigating further.

Prepare is not…

Prepare does not require an exhaustive analysis; it is not needed or suitable at this point. Remember – perfection is the enemy of progress.

Prepare does not involve estimating or asking for approval for the whole project, just determining whether it is worth the investment of a small team to investigate the problem and design further.

Page 27

Actions Actions which may be carried out during this stage include:

1. Clearly identify the opportunity, considering the views of the customers and stakeholders, and their interactions with each other.

2. Engage stakeholders (to form the coalition of the willing).

3. Choose the most appropriate lead agency (they will be the service provider).

4. Identify a sponsor for the change.

5. Carry out the assurance processes tailored appropriately for Accelerate and agreed with the sponsor, following the all-of-government assurance guidelines provided on ICT projects and programmes available at www.ict.govt.nz (search for “project assurance”).

6. Develop a concept brief.

7. Prepare a funding request for Discover.

8. Present the concept brief and business case A3 summary to get a decision on whether to proceed.

9. If going ahead, set up the team for Discover, including their physical and virtual working spaces.

Outputs The outputs from this stage include:

an agreement (or not) to proceed to Discover (based on the funding case and concept brief).

If the project proceeds, arrange:

a project space – a dedicated area to organise and display project materials, work, and for the Discover team to meet

access to the collaboration and information tools needed for the project. This is useful for any team members that work from separate locations.

Tools Tools that may be helpful during this stage include:

project collaboration tools.

For more information on this tool, please contact the Accelerate support team (details on the Accelerate landing page).

Page 28


Roles for Prepare

Prepare involves a small number of people (typically 3-7) who form an ad-hoc team for 4-6 weeks to explore the proposed plan of action, develop the concept brief, and the business case A3 summary. For a small business-as-usual project, Prepare may be as short as 2-3 weeks.

The team typically involves a project lead, an enterprise architect, a business analyst, a service designer and business subject matter experts.

Contact your Accelerate navigator in the GCIO’s team to discuss your team for Prepare.

Figure 5: Possible roles during Prepare

Page 29

Getting startedIntroduction The first step is to get an Accelerate coach or navigator.

Next, decide whether to start following the quick start guide, which allows the project to begin in parallel with learning about Accelerate, or whether to ensure the Prepare material is well understood before starting to carry out the Prepare stages.

Aim The aim of this stage is to:

start the preparation.


1. Confirm your starting point (see ‘Starting’ section in the Quick-start Accelerate guide).

1. Identify the project lead.

2. Follow the instructions from that point.

3. Use the toolkit to clarify any stages as required.


a clear understanding of the work that has been done, and what the next steps are.

Tools and templates

Tools that may be helpful during this stage include:

Quick-start Accelerate guide.

These tools and related templates are available on the Accelerate downloads page of www.ict.govt.nz.

Page 30


Unpack the problem or opportunityIntroduction It is important to understand the opportunity and the benefits from the

(possibly differing) perspectives of the Prepare team members, the customers, and any other stakeholders.

Aim The aim for this stage is to clearly state the opportunity at a high level, including:

what the opportunity is the main aspects of it the benefits to the stakeholders.

This description of the opportunity will be expanded during Discover.


1. Prepare a clear high-level statement of the problem.

2. Write a problem statement – the problem trajectory diagram may be used for this.

3. Add material from the problem statement to the concept brief.

4. Review the current concept brief with stakeholders.

Tools and templates


problem trajectory diagram putting the problem in context structured problem solving listening to the customer concept brief root cause analysis (such as Ishikawa or 5 Whys) investment logic map.


Page 31


Align with strategic priorities Introduction The Government, agencies, and business units set challenging goals.

Therefore determining cross-agency strategic priorities is complicated.


identify how the project contributes to the strategic directions and goals for the participating agency(s) which will clarify the project’s benefits and priorities.

Where to find strategic priorities

You can find descriptions of Government strategic priorities on https://www.ssc.govt.nz/bps-results-for-nzers.

Each government agency publishes their strategic priorities and goals on their websites.

When searching, consider focus areas, four year plans, improvement plans, and investment objectives.


1. Research each participating agency’s strategic documents and evaluate the project against all these using the strategic alignment questionnaire.

2. Undertake a scan of the strategic environment using PEST or PESTLE.

3. Include a summary of the research from step 1 for each agency in the concept brief. Include the agency’s goals, current activities, available resources, operating environment, and any externally driven factors.

4. Map the project outputs to relevant stakeholder goals and investment objectives using:

5 Whats to identify the project’s value and outcomes a strategic value map to show how this project aligns and

supports the strategic goals and objectives of the agencies involved.

5. Update the concept brief with a strategic value map.

6. Review alignment of the project deliverables with the strategic objectives of the participating agency(s) using the Strategic Alignment questionnaire.

7. Update the current concept brief and communicate it to stakeholders.

Page 32

https://www.ssc.govt.nz/bps-results-for-nzers


updated concept brief.

Tools and templates


5 Whats strategic alignment questionnaire.


Page 33


Determine the benefitsIntroduction Today’s business environments are complex and rapidly changing,

making realisation of the benefits more difficult, particularly when multiple agencies are involved. Clear and credible benefits:

help justify the investment provide reasons for participating agencies to engage.


clearly identify the benefits add the benefits into the concept brief ensure the benefits are confirmed at a high level, and that

adequate data will be available to monitor their realisation.


1. Review the material described in the problem trajectory diagram or the investment logic map, turning the negative effects around into potential benefits. These benefits will form the basis of key performance indicators (KPIs).

2. If necessary use the 5 Whys or the 5 Whats to identify root causes, key symptoms, and the benefits that will be realised by the project.

3. Add initial input to the benefits realisation plan. (During Discover, the baseline, KPIs, targets and benefits trajectory will be added).

4. Add material from the chosen tools to update the concept brief and review this version with stakeholders.


identification of the root causes and key symptoms of the problem, the benefits that will be realised, and the KPIs

updated concept brief the initial draft of the benefits realisation plan and its

associated benefits profile.

Tools and templates


problem trajectory diagram investment logic map 5 Whats benefits realisation.


Page 34


Identify who is responsibleIntroduction It is important to have a clear description of all the roles that need to be

involved and their responsibilities.

Aim The aim of this stage is to identify the:

stakeholders lead agency (they will be the service provider) sponsor product owner architecture owner other roles who need to be involved.

Stakeholders Understanding who the stakeholders are will:

help when planning the communications ensure you engage the right people in the discussions support the creation of the coalition of the willing.

Lead agency Identifying the lead agency (the service provider) in cross-agency projects is important. A suitable agency to be lead is one that:

has a significant stake in the outcome has suitable resources and capabilities is acceptable to the other agencies has an available sponsor.

Sponsor The project sponsor is ultimately accountable for the completion of the work. Identifying the sponsor is the start of the governance for the project.

All stakeholders need to be consulted about who will be the sponsor, as the sponsor needs to be supported by all the stakeholders during the project.

Product owner The product owner is a key role within Accelerate (and scrum/agile). They are responsible for:

supporting the sponsor in articulating the project vision communicating to the team the:

○ business and customer viewpoint○ product owner’s decisions on scope and business priorities.

Page 35

Other key roles Along with the sponsor, there are a number of key roles that may also be involved. For example, the:

customers’ representative staff representative other agencies’ representatives owner of the key business capabilities and of the technical

systems benefits owner.


1. Identify the key stakeholders and their concerns and perspective, considering the:

problem trajectory benefits business context diagram stakeholders’ level of interest in the project, and their level of

influence over the project.

2. Update the stakeholder analysis.

3. Create a WIIFM for each stakeholder to justify the value of their participation during Prepare and Discover.

4. Add sponsor, product owner, and stakeholders table to the concept brief.

5. Review the updated concept brief with stakeholders.

During Discover, the list of stakeholders may change as we better understand the project, so don’t invest too much time in detailed analysis.

Outputs The outputs for this stage are:

updated concept brief initial stakeholder analysis and WIIFM for the project.

Tools and templates


stakeholder analysis WIIFM.


Page 36


Outline the strategic responseIntroduction After defining the opportunity and the benefits, it is time to consider the

strategic response (how do we propose to intervene?). It needs to:

be a valid response to the identified root causes deliver some of the identified benefits allow more than one possible solution propose a preferred option consider the commercial concerns.

The team needs to:

identify a range of feasible possibilities create a qualitative description of the advantages and

disadvantages for the possibilities.

The stakeholders then use the information the team has collected to identify the main viable options. These will be expanded during Discover.

When working out what changes need to be made by the business to realise the benefits, the team needs to consider:

changes to people (number and skills), process and channels, and team structure

assets (computers or software) that need to be built or purchased

new or changed commercial arrangements that will be needed cost effectiveness of the solution relative to the expected

benefits.


document the strategic response to the opportunity.

Page 37


1. Conduct an initial options analysis to identify the relative merits and drawbacks of the feasible options.

2. Complete an investment checklist to ensure you have got to the heart of the problem, defined the appropriate benefits the investment will deliver and devised an effective strategic response and solution.

3. Document the conceptual solution architecture to explain in simple terms and at a high level what a solution will do and how it will do it for a client. This is to communicate key concepts to the business audience and communicate to technical staff what the solution is trying to provide and what key concerns it must address.

4. Identify possible sourcing approaches for key components and review with procurement to create an initial commercial case for the project.

5. Engage the stakeholders and review the opportunity for service design.

6. Update the concept brief and review with stakeholders.


initial options analysis conceptual solution architecture overview service design brief (if necessary) initial commercial case for the project updated concept brief.

Tools and templates


options analysis table conceptual solution architecture the commercial case how much service design.


Page 38


Choose the path forwardIntroduction

One of the decisions that is made during Prepare, is selection of the most appropriate approach to use going forward.


determine whether Accelerate is appropriate for the project.


1. Assess the risk level for the project to identify the optimal approach for delivery.

2. Hold a meeting between the business owner and the GCIO’s team to identify the suitability of Accelerate for the initiative.

Outputs The outputs from this stage include a:

documented high level risk assessment for the project decision to proceed using Accelerate, Managing Successful

Programmes (MSP®), or PRINCE2.

Tools and templates


Accelerate readiness tool Better Business Cases’ strategic assessment and strategic case,

available at http://www.infrastructure.govt.nz/publications/betterbusinesscases/files/bbc-strass-gd.pdf

Treasury risk profile assessment (to determine the level of risk and the best approach) available at http://www.treasury.govt.nz/statesector/investmentmanagement/think/riskprofile

DIA risk management guidance benefits, complexity, uncertainty, and impact assessments.


Page 39


http://www.treasury.govt.nz/statesector/investmentmanagement/think/riskprofile

http://www.treasury.govt.nz/statesector/investmentmanagement/think/riskprofile

http://www.infrastructure.govt.nz/publications/betterbusinesscases/files/bbc-strass-gd.pdf

http://www.infrastructure.govt.nz/publications/betterbusinesscases/files/bbc-strass-gd.pdf

Present the case Introduction The business case from Prepare requests funding only for Discover

(which can be accurately estimated). It is built from the outputs of the other Prepare stages.

Consider four questions:

Is the economic value of the estimated benefits sufficient to justify an intervention?

Is the priority sufficient to justify investing some opex to investigate the case more fully?

Does the economic value and priority justify the cost of a three month investment in Discover with a limited team?

What is/are the appropriate source(s) of funding for Discover?


present the initial business case to fund Discover, to the project stakeholders.


1. Create the initial business case A3 summary.

2. Update the concept brief to align with the business case.

3. Append the ILM or the project trajectory to the concept brief.

4. Append the recommended option from the initial options analysis to the concept brief, including a conceptual picture of the solution components.

5. Present the concept brief to stakeholders for their support, along with the estimated cost for Discover.

6. Negotiate the plan with the stakeholders and the funding body to secure resources for Discover.


business case A3 summary updated concept brief.

Page 40

Tools and templates


investment checklist (Prepare) business case A3 summary establish project finances options analysis table problem trajectory diagram investment logic map concept brief.


Page 41


Preparing for DiscoverIntroduction This stage establishes solid project foundations and prepares the

agencies for the work that needs to be done. The Accelerate approach aims to do just enough to establish a fit-for-purpose project environment, and no more.

Use the standards and templates defined by the agency leading the project, which are often based on methodologies such as PRINCE2 and Managing Successful Programmes (MSP®). This section identifies important items rather than specifying the approach.

The following identifies some useful tools from PRINCE2.


establish appropriate provisions for governance, reporting, financial control, business change management, assurance, risk management, and benefits management.


1. Work with the EPMO to establish the project controls such as risk, issues, and change control registers.

2. Work with the EPMO to establish regular project reporting.

3. Establish a Project Board with the stakeholders, including representatives from all the participating agencies.

4. Create the project file structure in a collaborative project management or document management tool.

5. Complete a project impact assessment.

6. Conduct an initial risk review and document for subsequent review and update.

7. Start conversations with supporting groups (such as procurement, security, legal, privacy, and finance) to allow them to plan for their engagement.

8. Conduct an agile readiness review to assess the preparedness of the agency to adopt Accelerate.


Page 42


Note: These actions may:

occur once with the output reused during the project (for example project file structure, project controls and registers)

be repeated during the project (for example project reporting, risk reviews and Project Board meetings)

be completed once and revisited if necessary (for example project impact assessment or an agile readiness review).


common project file system for team artefacts project controls documentation project risk register Project Board and terms of reference project impact assessment updated benefits realisation plan agreements in place with support teams of specialist

resources.

For examples and templates that can be used to produce the output, please contact the lead agency’s EPMO.

Tools and templates


establish project reporting project impact assessment risk management.

This list of tools is not intended to be exhaustive. Seek guidance from the lead agency’s EPMO for appropriate standards.

Many of the templates and examples here have been provided by the Department of Internal Affairs for illustrative purposes. Their suitability at other agencies needs to be confirmed.


Page 43


Phase 2. Discover

Introduction to DiscoverDiscover stages pg Description

Explore the business ecosystem 47 Increase understanding of the business environment

Elaborate the customer view 49 Expand the business case evidence regarding customers

Elaborate the product 51 Initiate the product vision, roadmap, and release plan

Engage the coalition of the willing 54 Engage a cross-agency group

Elaborate the solution 56 Develop the conceptual solution architecture

Elaborate the business case 58 Expand the business case developed during Prepare

Gain project approval 60 Present the proposal to the stakeholders

Preparing for Alpha 61 Prepare for Alpha, as much as practicable before funding

The Discover stages are inter-related, and may be carried out in parallel with different people leading each stage.

Important: Teams producing output must have common members and there must be no independent workstreams or individuals.

Purpose The purpose of the Discover phase is to:

get a clear understanding of the design and how the project will progress if funding is approved

expand and present the business case begin preparations for Alpha.

Page 44

Achieving the purpose

The purpose is achieved by:

understanding the business ecosystem, customers’ situation, and the business operating model

creating the product vision and product roadmap building a supporting coalition designing a proposed solution carrying out the assurance processes tailored

appropriately for Accelerate and agreed with the sponsor, following the all-of-government assurance guidelines provided on ICT projects and programmes available at www.ict.govt.nz (search for “project assurance”)

creating a business case.

Roles for Discover

Discover involves a small number of people (typically 4-9) forming a formal team for 8-12 weeks, to validate and elaborate the initial view developed during Prepare (see Figure 6). Given the need to communicate with multiple stakeholders, the shortest practicable period is 4 weeks.

Discover expands the Prepare team with:

representatives from participating organisations a business case writer additional design and specialist technical resources (if

necessary) resources for technical and business prototypes (if

necessary).

Page 45


Other roles that support this team include:

navigators benefits owner primary assurance contact EPMO (via the primary assurance contact).

Figure 6: Possible roles during Discover

The combination and number of each role depends on the nature of the product. Contact your Accelerate navigator to discuss your team requirements for Discover.

Page 46

Explore the business ecosystemIntroduction Analysing the whole system in which a business service or product

operates shows:

where and how the customer, other service providers, and intermediaries fit

the relationships and interactions among the key parties the roles, functions, and behaviour of individual components the overall operation of the system.

It considers the events that triggered identifying the opportunity, customer goals, and the business capabilities needed to satisfy the customer requests.

It is particularly important with large and complex cross-agency projects, where responsibility, accountability and mandate may not be immediately obvious.

Aim The aims of this stage are to:

gain a high-level understanding of the business ecosystem, to make the project more effective

ensure all significant factors required to generate the benefits are considered.

Enterprise architect

This stage is the responsibility of an enterprise architect, or the project’s architecture owner. They work with a team of business analysts, architects and service designers.

The enterprise architect documents a suite of business context, business collaboration, and business interaction diagrams, and information maps and undertakes an ecosystem scan using a technique such as PEST analysis.


1. Document the ecosystem in the following diagrams:

business context – to identify the actors (people, agencies, systems) who play a significant role in the business process, and the business areas of interest

business collaboration – to describe how the different actors work together to achieve their goals

business interactions –to describe the participating agencies’ view of the business interactions that support collaboration

Page 47

business operating model – to describe how the participating agencies support the ecosystem, ORbusiness domain model – to describe all topics related to a specific problem domain considering the various entities, their attributes, roles, and relationships, and any constraints

information discovery map – to create an overview of the internal and external information in an agency, what information gets manipulated by which system, and who needs to receive which information

ecosystem scan – to understand the business environment in which this capability operates, identify trends and drivers that affect the various individuals and agencies that are involved.

2. Present this material to the project team and include aspects in the business case.


a presentation summarising the big picture view of the ecosystem along with key insights

additions to the business case, typically as appendices.

Tools and templates

Tools (specifically enterprise architecture techniques) that may be helpful during this stage include:

business collaboration diagram business interaction diagram business operating model information discovery map ecosystem scan.


Page 48


Elaborate the customer view Introduction Elaborating the customer view allows the project to form an empathetic

understanding of the customer, their situation, and what the customers are trying to achieve.

Customer-centred design services have been identified as critical to creating better public services.

Service design involves planning and organising the components of a service to make it more effective for the customer, shifting the perspective from the agency to that of the customer. This is sometimes called an ‘outside in’ approach, or customer-centred service design.

The service design approach combines what is:

desirable from a customer's perspective viable from the agency's perspective technically feasible.

Employees are an important source of business knowledge and information and should be engaged to understand their perspective.

For further information on service design methods see the NZ Government Service Design Guideline, https://webtoolkit.govt.nz/guidance/service-design/.


consolidate and clarify the initial understanding (from Prepare) of what people do and prefer.


1. Work with a service designer to identify the required service design.

2. Engage a service designer and business analyst to plan and carry out the service design.

3. Select the techniques to be used.

4. Create service design artefacts, for example:

service design blueprint service design concept report paper or electronic prototypes.

5. Create an initial user story map from the service design material to support release planning.

6. Present this work to the project team, and include in the business case.

Page 49

https://webtoolkit.govt.nz/guidance/service-design/

https://desonance.wordpress.com/2010/06/16/service-blueprinting/

Outputs The usual outputs from this stage include:

a customer journey map a service design blueprint a service design concept report a presentation of the prototype user story maps additions to the business case (often as appendices).

Tools and templates


understanding the customer collecting customer views describing the customer experience usability testing prototyping.

For more information on these tools, please contact the Accelerate support team (details on the Accelerate landing page), or consult the UK Government Service Design Manual www.gov.uk/service-manual.

Page 50

https://www.gov.uk/service-manual

Elaborate the productIntroduction It is important to develop a clear path forward for the product

development, before beginning to carry out the work.

A product roadmap summarises the likely growth of a product by dividing the product into a sequence of releasable working increments. The product roadmap:

is the responsibility of the product owner is fundamental to the scaling of agile projects provides the link between the strategic direction and the

minimum viable products (MVPs) is a ‘top down’ approach and not an aggregation of user

stories structures and prioritises epics, user stories, and use cases (if

relevant).

It is used to support:

alignment of stakeholders validating product strategy acquiring budget for the product (as part of the management

considerations of the business case).

The product roadmap is usually completed by a team of business analysts, architects, service designers and the product owner.

The details of each release are described in a product release board which provides input into the design of each product release or minimum viable product (MVP).

This is based on the material of Roman Pichler at http://www.romanpichler.com/


produce a product roadmap clarify the minimal viable product.

Page 51

http://www.romanpichler.com/

Product vision A product roadmap is based on a product vision (displayed on a vision board).

A vision board (see Roman Pichler at http://www.romanpichler.com/):

starts with understanding the agencies’ existing strategy and operating model(s)

summarises the:

○ target group○ user needs○ key product features○ potential benefits realised through the product.

The vision board and the business operating model work ensure the product vision fits with the operating model and any supporting changes to the business are identified.


1. Review the agencies’ existing strategies and operating models.

2. If multiple agencies are involved, consider establishing a cross-agency product owners’ council to align product visions, approaches, plans, and benefits.

3. Document the business operating model to understand how the product fits into the business.

4. Create a product vision.

5. Create a product roadmap to describe how the product evolves over time.

6. Present this work to the project team.

7. Communicate the product roadmap to the stakeholders.


product roadmap clear description of the proposed minimal viable product.

Page 52

http://www.romanpichler.com/

Tools and templates


www.mindtools.com for information on creating vision and mission statements

product vision board – to articulate the product vision product roadmap – to describe the long term and strategic

direction of the product and how the vision will be delivered through a series of product or service releases

product release board – to describe the key aspects of each release

explore the business operating model – to review the business operating model material and update the product roadmap

user stories use case.


Page 53


http://www.mindtools.com/pages/article/newLDR_90.htm

Engage the coalition of the willing Introduction The stakeholders that were identified during Prepare now need to:

support the project participate in governance of the project provide supporting staff within their agency align their plans.

Project success is strongly linked to the attention provided by senior leadership. Therefore this stage is about creating a coalition of willing people to lead the project and keep it on track. This coalition is usually built by the product owner, project manager and sponsor.

This applies well within a single agency where authority can be formally applied. When this concept is applied to independent agencies the coalition is less delegated and more voluntary – hence the phrase ‘coalition of the willing’.

The coalition needs to include the product owner and the sponsor, and have the following considered:

representatives of the customers, the involved staff, participating agencies

the owners of the key business and of the technical systems involved, including the benefits owner.

The coalition of the willing is set up by a team that includes the sponsor, project manager, change manager, architecture owner, product owner, and members of the lead agency’s communications team. Either the sponsor or project manager is responsible for engaging the coalition of the willing.


enrol active support from the participating agencies by creating a coalition of willing people to lead the project and keep it on track.

Page 54


1. Create a RASCI matrix for the project team to clarify roles and responsibilities.

2. Considering the problem trajectory, the benefits and the business context diagram from the Prepare phase, create a WIIFM (see tools section) for each agency to justify the value of their participation during Discovery.

3. Use stakeholder analysis and the strategic value map to consider the strategic objectives and goals for the participating agencies so you can present the tailored value proposition.

4. Work with participating organisations on the organisation impact assessment to identify the opportunities and points of contention and to understand their constraints, plans and schedules.

5. Present a tailored concept brief (from Prepare) to each of the stakeholders to enrol them.

6. Establish a governance board and document terms of reference for the board.


fully engaged stakeholders available and engaged representatives.

Tools and templates


RASCI matrix WIIFM stakeholder analysis communications plan organisation impact assessment.


Page 55


Elaborate the solution architectureIntroduction This solution architecture description outlines the structure of the key

building blocks (especially those with shared or common capabilities) of the proposed product. This supports:

estimating and planning development work in Alpha and Beta ensuring the product roadmap is:

○ aligned across agencies○ technically feasible○ consistent with other projects and agencies’ strategies○ aligned to benefits

trade-off discussions about the scope, quality and schedule, that occur to gain project approval.

This is the responsibility of the architecture owner, and is usually done by a combined team of service designers, business analysts, and architects.

This stage is an important part of scaling the project.


develop a description of the proposed product’s architecture, based on the conceptual solution architecture from Prepare, and consistent with the product roadmap.

Building blocks In this context, a building block can be described as a functional unit that meets the business’s needs. Common types of building blocks include actors, business services, applications, or data entities.

Architecture owner

The architecture owner is part of the project team, and is responsible for:

the evolution of the solution architecture communicating and maintaining the integrity and structure of

the solution ensuring the solution will meet the requirements articulated

by the product owner, and just in time according to the schedule in the product roadmap.

Page 56


1. Document the solution architecture using input from the elaborated customer view, business ecosystem, elaborated business operating model and the product roadmap.

2. Create a capability heat map diagram for the project to identify the business capabilities of Government that are in the scope of the solution

3. Collaborate with the architecture teams from other agencies as necessary.

4. Review logical solution architecture with security to develop a risk report and identification of key security controls for subsequent detailed design and review during sprint reviews.

5. Create viewpoints of the solution for each of the involved agencies.


logical solution architecture document agency-specific views of the solution architecture.

Tools and templates


conceptual solution architecture ArchiMate® Introductory Viewpoint ArchiMate® Service Realisation Viewpoint ArchiMate® Application Usage Viewpoint ArchiMate® Layered Viewpoint.


Page 57


Elaborate the business case Introduction Prior to beginning to develop the business case, agree the process, and

the amount of analytical effort needed, with the stakeholders.

This stage brings together the other stages to create the business case.

To support the business case, an assessment of project risks is undertaken to predict and deal with events that might prevent project outcomes being delivered. All projects should follow the lead agency’s risk management framework.

This stage is the responsibility of the project manager. The work is carried out by a team that includes business case writers, the product owner, architecture owner, service designer and business analysts.

If the investment falls under Treasury’s CO 15 threshold, contact the Better Business Case centre in Treasury. Information is available on the Treasury website under Better Business Cases: Guidance (on the A-Z of Treasury Publications under the Publications tab).

http://www.treasury.govt.nz/statesector/investmentmanagement/plan/bbc/guidance


expand the business case by refining the content, and extending the view to include Alpha, Beta, and Live for the minimum viable product (MVP)

update the benefits realisation plan, worksheet, and profile with the information from Discover.


1. Gather input from the earlier aspects of Discover, particularly the product roadmap, business context, solution architecture, and the service blueprint.

2. Document a high level organisational impact assessment for the participating agencies.

3. Use the material in the problem trajectory diagram if sufficient, otherwise develop an investment logic map as input to the business case.

4. Add a summary of the above material to the business case, and create a business case A3 summary.

5. Document the identified risks.

6. Update the benefits realisation plan.

7. Communicate this material with the stakeholders.

Page 58




a completed and communicated business case that is supported by the investing agencies

a business case A3 summary an initial risk assessment for the project risk register and assessment document benefits realisation plan change impact assessment for the participating agencies.

Tools and templates

Tools that may be helpful during this stage include all tools used during Discover, particularly:

investment checklist (Discover) risk management benefits realisation business case A3 summary commercial case concept brief.


Page 59


Gain project approvalIntroduction This stage involves:

presenting the business case to get the project (and funding) approved

creating a plan of approach for the approved project that includes governance and sign-off. It must be agreed by the sponsor and approved by the Project Board.


identify funding sources create a funding model/proposal gain approval for:

○ the project○ how the project will progress from this point.


1. Choose a funding source.

2. Create a funding model/proposal.

3. Prepare a project plan (using a plan of approach workshop) that includes governance and sign-off processes for the project from this point onwards.

4. Review the project plan with the sponsor and present it to the Project Board for approval.

5. Present the business case A3 summary as a request for funds.


governance proposal for the sponsor and the Project Board secured resources (including a core team) for Alpha.

Tools and templates


plan of approach workshop assurance plan privacy impact assessment project initiation documentation.


Page 60


Preparing for AlphaIntroduction This stage covers preparing for Alpha, as far as is practicable before

funding is approved. Any items not done before the project’s funding is approved will be carried over to Alpha, and done during Preparing to spring (sprint zero).


start preparing for Alpha.

Actions, outputs and tools

The actions, outputs, and tools are described in Preparing to sprint (sprint zero).

These are carried out as far as is practicable with no approved funding. Any actions not completed here become part of Preparing to sprint (sprint zero).

Page 61

Phase 3. Alpha

Introduction to Alpha

Alpha stages pg Description

Preparing to sprint (sprint zero) 65 Set up the work and prepare the project environment

Product grooming 68 Prioritise and prepare the work

Sprint 69 Carry out the development work

71 Plan the release of the product increments

Business change management 73 Identify and address changes needed for the product release

About Alpha Alpha is when the product increments are developed, ready for release to customers.

This toolkit is based on agile development techniques, specifically scrum. It assumes the team is already trained in agile and scrum, and focuses on explaining how Accelerate and agile work together.

In Accelerate, because of the complexity of cross-agency releases, Alpha is considered completed when the product is ready to be released, and the release process is covered in Beta.

In a single agency project Alpha and Beta may be merged.

Purpose The purpose of Alpha is to:

develop working product increments, following the product roadmap and the release plan

identify and implement the business changes needed to embed the new or changed capability.

Page 62

Main Alpha actions

The main Alpha actions are:

1. Set up the project space, the team, and the collaboration tools.

2. Review the product release board.

3. The team agrees the definition of ‘ready’ and ‘done’.

4. Start product grooming to prioritise the work (this is done at least weekly throughout Alpha).

5. Start user story grooming so the user stories are clarified, ready for the sprint.

6. Update the benefits profile for each sprint.

7. Update the benefits worksheet.

8. Plan and carry out sprints.

9. Carry out release planning.

10. Plan customer experience reviews.

11. Create progress reports.

12. Carry out a sprint review and demonstration at the end of each sprint.

13. Hold sprint retrospectives at the end of each sprint to identify opportunities for improvement.

14. Review the product increment(s) and include them in a release.


16. Complete privacy assessment on the material in the release, if required.

Roles for Alpha The resources for Alpha depend on the scale of the project. Possible roles in Alpha for single teams and multiple teams are given in Table 3 on page 64.

Contact your Accelerate navigator to discuss your team requirements for Alpha.

Page 63


Table 3: Possible roles in Alpha

Roles in a single team Roles in multiple teams

Page 64

Preparing to sprint (sprint zero)Introduction Sprint zero prepares for the rest of the sprints. It sets up the physical

and technical environment (see ‘What is sprint zero?’ www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero).

Sprint zero includes:

defining the minimum viable product creating definitions of ‘ready’ and ‘done’ with the team creating initial versions of business and technical

documentation preparing the product backlog training, if people are new to Accelerate or agile techniques.


set up the physical and technical environment.

Making sprint zero more effective

Sprint zero is made more effective by:

creating only the basic project structure, so that future sprints can add their value in an efficient way. This may require using research spikes (such as a prototype) to set development guides or investigate areas of complexity

minimising the amount of up-front design so that the design can emerge in future sprints

choosing a few critical stories and developing them to completion (this ensures sprint zero provides a completed product increment). Since these are the first, delivering them includes putting the skeleton/framework in place.

Page 65

https://www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero#sthash.uJXKLMsJ.dpuf

https://www.scrumalliance.org/community/articles/2013/september/what-is-sprint-zero#sthash.uJXKLMsJ.dpuf


1. Develop the initial version of the release plan, using a workshop and the user story map or service blueprint.

2. If required, agree how to coordinate tasks and governance across agencies using either scrum of scrums or the Project Board.

3. Draft the generic meeting calendar for the team to schedule the recurring meetings for Alpha.

4. Complete a project initiation document.

5. Complete an initial privacy assessment.

6. Complete an initial assurance plan.

7. Complete the initial service readiness and technical support documentation.

8. Complete the initial benefits realisation plan.

9. Update the benefits profile and plan.

10. Establish the resources for Alpha:

project space (see The importance of co-location on page Error: Reference source not found) including desks, boards, stationery supplies

set up:

○ the required tools○ IT platforms and networks

establish access to:

○ team collaboration and test tools○ version control tools and libraries○ development and test environments○ software release management tools.

11. Arrange Accelerate and agile training if necessary.

12. Select items for the initial product backlog from the product release board, user story map, and possibly from use cases.

13. Start sprint planning meetings by populating an initial sprint plan with some estimated items.

14. Arrange a workshop to document the team’s definition of done and definition of ready.

15. Develop initial documents for the benefits realisation plan, security review, test strategy, as-built documentation, and operations and support guides. These will be filled in for each release at the end of Alpha or Beta phases. These documents should include the key acceptance criteria for these documents, so they can be included in the sprint reviews.

Page 66


minimum viable product (MVP) documented and communicated to stakeholders

agreed and commonly understood definitions of ready and done

tailored governance, and operational impact assessments reflecting the lead agency

updated benefits profile and benefits plan project initiation documentation a project space a technical platform for development, testing and release

packaging an initial product backlog an initial security review document an initial test strategy document an initial as-built document an initial operational support and service desk document product release board describing the goal for the first release.

Tools and templates


product backlog scrum of scrums definition of ready definition of done defining the MVP Accelerate readiness assessment user stories user case generic meeting schedule.


Page 67


Product groomingIntroduction The higher the quality of the work items in the product backlog, the

higher the quality of the outputs of the sprint(s).

Product grooming involves the product owner, team, and the scrum master meeting regularly to improve the product backlog ready for the sprint planning meeting. This may lead to:

removing user stories that are no longer relevant creating new user stories to meet newly identified needs adding new user stories to address issues identified during

testing adjusting the relative priority of user stories assigning estimates to user stories correcting estimates splitting high priority user stories to refine them, ready for the

sprint.


prepare the work items for the sprints, so they are relevant, and appropriately detailed and estimated for their priority

ensure the team understands the goal and requirements of the user stories.


1. Undertake product grooming to focus the team on the top priority user stories.

2. Complete user story grooming (including identification of acceptance criteria), to ensure the user stories are complete and detailed enough to use for estimation and creation.

3. Complete sprint planning so the team and product owner understands what work will be undertaken in the sprint.

4. Plan the release so preparation can start while the release is being assembled (see on page 69).

Outputs The outputs from this stage include a:

groomed product backlog or work items suitable for development

list of candidate product increments for inclusion in a product release.

Page 68

Tools and templates


usability testing product backlog product backlog grooming user story grooming completing sprint planning release preparation definition of ready.


Page 69


Release planning

Introduction During release planning (in Alpha), the release team adapts the Accelerate approach to match the specific release and business change management processes of the participating agencies.

Planning for the release starts during product grooming and is done by:

release team - project manager, lead solution architect, project change leader, and

IT change control and operations teams.


create an initial description of the release packages plan the release (based on the release packages) while the

product is being developed (i.e. during the sprint).


1. Create a release candidate using the agreed list of user stories identified for the sprints contributing to a release.

2. Develop a schedule for:

building, testing, and deploying the release into production providing early delivery support providing eventual movement of the release into full

operation.


release candidate release plan.

Tools and templates


product grooming sprint review product release board.


Page 70


Sprint Introduction The development work to produce the product increments is done

during regular, repeatable 2-4 week work cycles, known as sprints.

During each sprint, the team develops (analyses, builds, integrates, tests, packages, and releases) a working product ready to be released, concentrating on the most essential functionality as indicated by the product owner, who considers the interests of both customers and stakeholders.

Following the sprint review, the release team (members listed under on page 69) allocates completed product increments to a scheduled release.


produce the product increment(s) (tested and ready for release) .

Sprint reviews During Alpha, the work outputs are reviewed at the end of a sprint at a sprint review. This ensures the work is completed according to standards documented as part of the definition of done created for the sprint and in accordance with governance processes and the plan of approach agreed in Discover.

Test-driven development

The following cycle for test-driven development is recommended in Accelerate projects.

The development team:

1. Works with the agency’s test manager to set up the test environment.

2. Writes an automated (initially failing) test case that defines a desired improvement.

3. Produces the minimum amount of code or configuration to pass the test.

4. Refactors the new code to acceptable standards.

5. Repeats steps 2-4 for each user story in the sprint backlog.

The product owner:

6. Accepts products that have passed their test cases.

Automated test suites are recommended to improve the quality and speed of the testing.

Page 71


1. Develop the product increment(s).

2. Monitor progress, using sprints, a scrum board, and a burndown chart.

3. Hold a sprint review to present the product increment(s) to the product owner, for them to check against the definition of done.

4. Review the sprint, using a sprint retrospective.


the completed product increment(s) as-built documentation data on team velocity for subsequent planning.

Tools and templates


sprint planning daily stand up meeting (scrum) scrum board definition of ‘done’ definition of ‘ready’ burn down chart velocity graph usability testing sprint review sprint retrospective as-built documentation.


Page 72


Business change management Introduction Business change management is a structured approach used to ensure

smooth and effective change implementation. The business change management plans need to be tracked as the project progresses.

During Alpha, this involves managing the specific impacts of a release and how to move from the current situation to the new one This builds on the change impact assessment developed during Discover.

The focus is to plan, develop, and implement a business change plan for the planned release(s) considering launch, IT support service activities, and business changes (such as training, update of knowledge bases and procedures, new tools).

If the release is an initial release, the amount of change can be significant. For example, channel shifts may impact business teams, processes may be impacted, a new operating model may need to be introduced, and new training or retraining may take significant time.


plan, develop, and implement the change plan ensure ongoing activities to realise benefits.


1. Form a change team with members from the project and business area.

2. Conduct a change readiness assessment (this may contribute to the final go/no-go decision).

3. Plan and carry out communication.

4. Monitor the level of stakeholder engagement and support.

5. Develop and implement new or updated processes.

6. Undertake a training needs analysis and create training plans.

7. Develop and implement changes to the business operating model, such as changes to teams, roles, and responsibilities.

8. Document and update the benefits profiles for each release.

9. Identify key metrics and relevant baselines, to measure the change and benefits realisation.

Page 73


a change communication plan that includes purpose, key messages, audience(s), channels, budget, and schedule

an assessment of the audience’s change readiness for the specific changes in this release

documentation of any new process skills competency assessment with respect to any new process

or tools training needs assessment, and training opportunities updated benefits realisation plan, benefits profile and benefits

worksheet.

Tools and templates


benefits realisation.


Page 74


Phase 4. Beta

Introduction to Beta

Beta stages pg Description

Releasing the product 78 Following the release processes effectively

Tracking the releases’ progress 79 Keeping track of the releases’ progress

About Beta Effective delivery of cross-agency services requires a coordinated release of product increments with close attention to detail to avoid delays.

In Beta, the participating agencies’ processes are used to provide a coordinated release.

At the end of each release, the working product increments are added to the fixed asset register as part of the ‘close’ process.

Purpose The purpose of Beta is to:

release product increments effectively across agencies.

Immediate or delayed release

The product increment(s) may be:

released immediately following the sprint queued for release during Beta.

Reasons for a delayed release include:

interdependent product increments waiting for user training or a communications campaign to be

completed fitting with an integrated release involving other agencies.

Page 75

Actions After the sprint review:

1. Update the release plan.

2. Add the approved product increment(s) to the release and update the product release board.

At the end of the release:

3. Conduct a sprint retrospective that includes how to improve the release process.

Throughout Alpha:

4. Carry out the assurance processes tailored appropriately for Accelerate and agreed with the sponsor, following the all-of-government assurance guidelines provided on ICT projects and programmes available at www.ict.govt.nz (search for project assurance).


security tests applied in a pre-production environment, including penetration testing if required

completed product increments deployed in production completed releases added to the fixed asset register updates to the configuration management database improvements to the release management process.

Roles for Beta The resources for Beta depend on the scale of the project. Possible roles in Beta for single teams and multiple teams are given in Table 4 on page 77.

Contact your Accelerate navigator to discuss your team requirements for Beta.

Page 76


Table 4: Possible roles in Beta

Roles in a single team Roles in multiple teams

Page 77

Releasing the productIntroduction During release planning (in Alpha) the release team adapts the

Accelerate approach to match the specific release and business change management processes of the participating agency(s).

This stage of Beta is when the release plan is put into action.

A scrum of scrums may be used to synchronise the different release processes and a product release board to visualise the coordinated efforts.


ensure each release is carried out with effective engagement with the different agencies’ release management processes.


1. Determine the agencies’ release management methods and schedules.

2. Establish contacts for synchronising release actions with other agencies.

3. Agree integrated release processes with agencies involved in the release, including how releases will be tracked.

4. Integrate testing with other agencies.

5. Release the product(s).

6. Provide early release support.

7. Complete security testing and accreditation in the integrated environment.


approved product increments(s) are released every release is recorded in the fixed asset register.

Tools and templates


scrum of scrums product release boards release package board.


Page 78


Tracking the releases’ progress Introduction Accelerate follows a continuous delivery model to move each release

through the release processes of the participating agencies.

Continuous delivery views deployment activities as a pipeline with a series of validations through which the product increment(s) must pass on the way to deployment.

The product release board is used to display the status and progress of the release as it moves towards full deployment. A scrum of scrums can be used to review and communicate progress across agencies.

At each stage feedback is provided to the team who may adjust the material in the release using a number of different techniques to complete testing of updated material.


track the progress of releases.


1. Hold a stand-up meeting to review each releases’ progress.

2. Update the product release board.


an updated product release board.

Tools and templates


scrum of scrums product release board.


Page 79


Phase 5. Live

Introduction to LiveLive stages pg Description

Customer acquisition 82 Acquiring new customers for the product

Benefits realisation 83 Starting the benefits realisation activities

Enhancing the product platform 84 Developing the product platform capacity

About Live Often the product increment(s) from Alpha or Beta will be deployed to a restricted audience, on a restricted platform.

During Live the benefits are grown by:

acquiring new customers for the product starting the benefits realisation actions (benefits owner) developing the platform to meet customer volumes and

availability demands.

Purpose The purpose of Live is to:

promote adoption by customers, including developing and implementing communication processes

start benefits realisation activities (benefits owner) monitor demand growth increase the capacity to meet the demand (within the

available budget).

Responsibilities for Live

Responsibilities during Live may belong with the project, or with supporting teams.

Page 80

Responsibilities of the project

Actions that are project responsibilities include:

1. Develop a marketing and awareness campaign (in conjunction with communications team).

2. Monitor the campaign results and adjust the plan accordingly.

3. Set up customer engagement and feedback mechanisms to inform ongoing improvements.


5. Review and adjust the business case and product roadmap in light of learnings from Beta and the results of customer acquisition and benefits realisation progress.

Responsibilities of supporting teams

Actions that rely on supporting teams, such as IT service management and security performance monitoring include:

1. Gather anecdotal feedback from participants (customers, users, partners).

2. Enhance the initial technical and operational capability supporting the product release according to increased usage.

3. Implement security monitoring, application performance reporting, web clickstream analysis and business process performance reporting.

4. Implement benefits realisation actions.

Page 81


Customer acquisition Introduction Creating a marketing and public awareness campaign can be seen as an

extension of the communications and business change management plans of previous phases to include more external promotional activities.


work with the lead agency’s communications team to create a marketing and public awareness campaign, following their usual processes.

Actions With the lead agency’s communications team:

1. Identify the marketing and promotional activities that will maximise impact with the target audience (for example, press releases, advertising campaigns, content-based marketing, search engine optimisation, roadshows).

2. Coordinate with other agencies’ communications campaigns.


marketing and public awareness campaigns to grow the customer base.

Page 82

Benefits realisationIntroduction The business case created in Discover identified benefits which justified

the investment. During Alpha, business change management plans were made to realise those benefits.

With the new product capability deployed, the user base increasing, and the IT capabilities in place, it is time to start the benefits realisation actions identified in the business case and business change management plans.

Benefits realisation:

is the responsibility of the product owner and benefits owner requires monitoring progress through a few critical indicators,

and intervening where necessary grows as people use the product, often after project close. It is

important to identify resources for benefits realisation beyond the project.

Aim The aim of this stage is to ensure the:

benefits of the project are maximised as far as is practicable ongoing benefits realisation accountabilities are assigned.


1. Monitor progress of benefits realisation through a few critical indicators.

2. Update the benefits realisation plan, worksheet, and profile.

3. Intervene where necessary.


The project’s benefits maximised as far as is practicable.

Tools and templates


benefits realisation plan benefits management worksheet benefits profile.


Page 83


Enhancing the product platform Introduction Often the initial product increment(s) will be made available on a

restricted product platform because the starting workload and customer base is small.

During this stage of Live, the initial product platform is developed to support increasing the numbers of customers by improving the availability, resilience, and capacity of the system.

Ongoing monitoring for security, application performance and process performance is also established.


develop the product platform to support increasing customer numbers.


1. Negotiate service level agreements and service level objectives for the product platform operation.

2. Invest in additional infrastructure to increase platform resilience.

3. Extend available hours of service.

4. Develop business continuity and disaster recovery plans.

5. Establish BAU user administration processes.

6. Apply data backup and archive processes.

7. Create capability or asset management plans.


improved capacity of the product platform.

Tools and templates

A variety of industry approaches are available, for example ITIL or IT Service Management. These tools are the responsibility of the relevant agency(s) and are beyond the scope of this document.

Page 84

Phase 6. Grow

Introduction Accelerate is designed to support projects that grow product capabilities to match changing customer and business expectations and availability of funding.

Grow offers an approach for investment planning that supports iterative improvements in cross-agency common capabilities.

Because there are cross-agency benefits, the capability improvement requires a shared investment plan. This investment planning needs to incorporate the processes of multiple agencies.

During Grow, an integrated business case is developed that links cross-agency capability roadmaps with cross-agency investment plans.

Purpose The purpose of Grow is to:

determine ways to meaningfully increase the product’s capabilities

negotiate cross-agency investment to support increasing the capability.

Improving the product’s capabilities

Capability improvements need to be based on:

information from customer research and feedback application performance monitoring continuous improvement analysis capacity asset lifecycle plans.

Page 85

Investment planning

Investment planning for cross-agency shared capabilities requires a different approach to coordinate ongoing funding, including:

capex funding of new functionality and assets opex funding for operating expenses application administration and maintenance, minor works

and training onboarding project costs for a new partner depreciation.

Possible funding options for different expenses are summarised in Table 5.

Table 5: Possible funding options for different expenses

Expense Question Funding Options

Capex (capital expenditure) for new functionality

Who funds investment in new shared capability or the enhancement of existing shared capability?

seed investment funding pooled funding between agency partners baseline funding of the provider agency baseline funding of the requestor agency

Opex (operational expenditure) for operating expenses

Who funds the operational costs for shared capability?

fund from baseline for the owner of the financial asset

usage fee cost recovery from participating agencies

Application administration and maintenance, minor works and training

Who funds minor enhancements, maintenance and ongoing training?

pool funding between partners baseline agency funding usage or transaction fee cost recovery from participating agencies

based on usage, estimated value, capex contribution

Onboarding project costs for a new partner

Who funds the tailoring costs for new partners?

the cost is shared across all participating agencies

an installation fee each meets their own cost

Depreciation Where is the depreciation allocated for shared assets?

the owner of the financial asset

Page 86


1. Identify improvement opportunities by reviewing:

customer feedback and customer service design research customer interactions and transactions analysis for customer

experience insights and service ‘drop out points’ security, application and business performance reports.

2. Develop a capability model for the product to coordinate investment plans, using the business operating model output from Discover and the GCIO capability reference model.

3. Create product investment plans and an integrated business plan that are aligned to the relevant IT asset management plans, the product vision, and product roadmap.

4. Review and amend the benefits realisation plan.

5. Update the product roadmaps from the aligned investment plans.

6. Communicate the findings to the participating agencies’ product owners.

7. Include the investment plans in the 4 year plan and budget round for the participating agencies.

8. Use the investment plans to identify opportunities and restart the Accelerate approach.

9. Carry out the assurance processes tailored appropriately for Accelerate and agreed with the sponsor, following the all-of-government assurance guidelines provided on ICT projects and programmes available at www.ict.govt.nz (search for project assurance).

Page 87


Accelerated Delivery Method Iteration 1 RC · Web viewSee more on this and other topics at . Agile...

Documents

Transcript of Accelerated Delivery Method Iteration 1 RC · Web viewSee more on this and other topics at . Agile...