Agile Change Agent

Agile Change Agent

WorkBook © The Knowledge Academy 2021

AGILE CHANGE AGENT - WORKBOOK

1

Contents An Agile Overview ......................................................................................................................................... 3

Importance of Agile ................................................................................................................................... 4

Introduction to Change Management .......................................................................................................... 6

The Change Management Process ............................................................................................................ 7

Change Management takes place at three stages: ................................................................................... 7

Change Management on Projects ............................................................................................................. 8

Three Levels of Change Management .................................................................................................. 8

Introduction to Project Management ......................................................................................................... 10

Choosing Methodologies ........................................................................................................................ 11

Introduction to Product Roadmap .............................................................................................................. 15

Introduction to Iteration Development in Agile ......................................................................................... 17

Agile Iterative Development ................................................................................................................... 18

Employment of Agile Iterative Approach ................................................................................................ 22

Benefits of Agile Iterative Development ............................................................................................. 23

Business Drivers in Change Management ................................................................................................... 25

External ................................................................................................................................................... 25

Internal .................................................................................................................................................... 26

SMART Goals ............................................................................................................................................... 27

S - Specific ............................................................................................................................................... 27

M - Measurable ....................................................................................................................................... 28

A - Attainable .......................................................................................................................................... 28

R - Relevant ............................................................................................................................................. 29

T - Time Bound ........................................................................................................................................ 29

Business Case .............................................................................................................................................. 30

Value of the Business Case for Change Management ........................................................................ 31

Foundation of the Business Case for Change Management ................................................................... 32

Benefits of a Business Case for Change Management ............................................................................ 34

Realising Benefits ........................................................................................................................................ 39

Benefit Realisation Cycle ......................................................................................................................... 40

MoSCoW ..................................................................................................................................................... 41

Must Have Initiative ................................................................................................................................ 42


2

Should-Have Initiatives ........................................................................................................................... 43

Could-Have Initiatives ............................................................................................................................. 43

Will not have (this time) ......................................................................................................................... 44


3

An Agile Overview

Agile is a method used for managing projects. It can be utilised for

anything virtually, but it was founded in software development. Agile

splits down larger projects into small, manageable parts and these parts

are also known as iterations. A value is produced at the end of each

iteration (which usually takes place over a constant time interval). The

product developed during each iteration must be able to launch into the

world to obtain feedback from users or stakeholders.

As made popular by the “Agile Manifesto”, agile values:

People and communications over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan


4

Importance of Agile

Speed to Market: Agile allows you to get your idea to your users as

soon as possible. An agile project delivers something of value

during every sprint. At any point, you may define your desire to

launch what has been delivered and start developing a user base

or testing your hypothesis.

Flexibility: Agile is based on providing change. Software projects

continuously change. You should be able to react and update the

product accordingly, a product comes to life, or the market grows.

Agile also realises that excellent ideas are bound to come mid-

project, and being locked into a scope doesn’t let you take

advantage of these realisations.

Risk Management: Incremental releases mean that the product

can be utilised first in the process by stakeholders and users. It lets

you recognise problems and feature deficits first in the process.

Being adaptable to change means it isn't a problem to change the

project's scope midway, which would be difficult in a waterfall style

project.

Cost Control: Unlike a fixed budget project, agile is flexible about

scope. More often than not, our clients realise the features they

initially requested are no longer necessary. It allows them to launch

sooner and pay less. Agile isn’t about spending a lot with

uncertainty; it’s about paying for only what you require. Require to

stick within a budget? No problem! We can rearrange the product

backlog so that critical new features are implemented at the

expense of less powerful features, not your budget.


5

Quality: Agile integrates testing during the process. Continuously

delivering tested software indicates higher overall quality and less

time spent on QAing the full application.

Right Product: Incremental releases let you test your product first

and often. Even if you don’t release it to the public, and it’s much

easier to determine issues and things which can be changed or

enhanced when you have an actual product to play with vs a series

of designs.

Transparency: Agile lets you recognise, feel and use a project

consistently during the project. You don’t see things in

compartmentalised silos; you see how things work together.


6

Introduction to Change Management

Change management is described as how a company defines and

implements change within both its internal and external processes. It

involves preparing and supporting employees, discovering the essential

steps for change, and managing pre-and post-change activities to assure

successful implementation.

Important organisational change can be difficult. It usually needs various

levels of assistance and may include several independent entities in an

organisation. Developing a well-structured strategy to change is

important to assure a profitable change while decreasing disruption.

Changes usually fail for human reasons: the change promoters did not

attend to the good, real and anticipated reactions of normal people to

disturb their routines. Efficient conversation is one of the most crucial

success factors for efficient change management. All included people

should know the development by the different stages and see outcomes

as the change cascades.


7

The Change Management Process

From a process viewpoint, change management is a collection of stages

a team member follows on a specific project or initiative—the approach

and methods concentrated on moving people by the change. Prosci’s

research-based methodology involves three main stages:

1. Preparing for change

2. Managing change

3. Reinforcing change

Change Management takes place at three stages:

• For People: To allow the success of people through encouraging them

on their personal change journey.

• On a Project: To improve results and return on investment by making

acceptance and usage.

• Across an Organisation: Implementing change management to

achieve strategic plan, reduce overload, and enhance agility.

For People

On a

Project

Across an

Organisation


8

Change Management on Projects

Change happens one person at a time, Change Management at the project level may help to promote the change through groups. Change management is the practice on projects as well as initiatives. Popular methods and techniques for implementing change are implemented regularly and constantly across the enterprise. A change agent is an individual that implements change. Three Levels of Change Management

1. Individual Change Management

Human resistance to change is the normal psychological response, we are still very resilient beings. Individual change management needs to consider how individuals see change and whether they expect to succeed change. It also includes learning what can help people make a good change: what information people need to determine where and from whom, what the best time to teach someone a new ability is, how to encourage people to show different habits, and what helps improvements "Stick" in someone's job.

1. Individual Change Management

2. Organisational Change Management

3. Enterprise Change Management Capability


9

2. Organisational Change Management

Although change occurs at the individual level, a project team also cannot handle change on a person‐by‐person basis. Organisational change management gives us with the actions and decisions to be followed at project level to help the hundreds or thousands of people affected by a project. Organisational change management includes first describing the organisations and individuals who would need to change as an outcome of the project, and how they would need to change.

3. Enterprise Change Management Capability

Enterprise change management is a key organisational skill which presents competitive differentiation and the ability to adjust effectively to the ever‐changing environment. An enterprise change management skill means efficient change management is set into the roles, methods, structures, and projects of an organisation. Processes in change management are introduced systematically and successfully to projects; leaders have the expertise to direct their teams using change and workers.


10

Introduction to Project Management

A project is a short and one‐time exercise whose duration varies. It is dedicated to meeting an organisation's particular needs to develop a service or to change a business method. It is in direct contrast to how a company usually operates continuously to produce its products or services. For example, an organisation's task may be to produce vehicles continuingly, and the task or work is called functional because the company produces over-and‐over again the same goods or services and employees maintain their jobs semi‐permanently. A perceived need generally initiates a project in an organisation. As a one‐off project, it will have a beginning and an end, expenditure limitations, time and tools, and includes a purpose‐built team. Project teams consist of several team leaders from end users/customers, Information technology staff, a leader of a project, trainers, project manager, sponsor, and other stakeholders. Project management is the practice of handling all the numerous project resources and facets in a way that the resources provide all the performance needed to accomplish the project within the specified scope, time, and cost constraints. This should be accepted at the beginning point of the project, and by the time the project starts both stakeholders and team leaders should have a strong understanding and approval of the procedure, approach, and planned results. A successful project manager uses a structured framework that can be audited and utilised for the project as a blueprint, and this is done by applying a technique by project management.


11

Choosing Methodologies

Projects are usually divided into three stages: Initiation, Implementation, and Closure. Every stage has various checkpoints to be reached until the next step starts. The extent to which a project is being managed will depend on the project size. A more structured strategy is required for a complicated project inside a broad company requiring a variety of individuals, personnel, time and energy, and further measures must be incorporated into each level of the process to insure the process delivers the desired end result. A few checklists, and someone to manage the project may be all that is required for a simple project in a small company, agreed milestones.

1. Initiating a Project

2. Implementing

a Project

3. Closing a Project


12

1. Initiating a Project

Each and every project begins with a concept for a product, service, new technology or other desirable result. The proposal is conveyed to the project sponsors (the individuals who fund the project) through what is often called a project charter or a mandate. The task is a document organised in a way that lays out a consistent procedure for project implementation which will contribute to a business case for the project. When the business case has been approved, a comprehensive document to clarify the proposal is prepared, and it is called 'The Project Definition Report'. The PD is not only used for providing complete project's information but is also the report on which an assessment is given as to whether or not the project should continue. Some of the essential fields it covers are the project's scope, the results of any feasibility studies, and what it is meant to deliver. The document will also describe main stakeholders, necessary resources, costs and planned duration, as well as market benefits. They also need to determine what is regarded as Key Success Criteria from this list, and these are the goals that are 'key' to the project's success or failure-regardless though specific goals are achieved. If the project has been granted the go-ahead, a legal agreement is drawn up, and this is used by the project sponsor to give the project funding officially and to begin the project.


13

2. Implementing a Project

The implementation step revolves around monitoring and project management. The first thing that occurs when the project starts is to utilise the Report on Project Definition to build a project schedule that describes how to perform what is defined in the PD report. The project schedule is the core document used to coordinate the project for its duration in order to gain agreement and acceptance by all the teams on issues such as project goals, stages, and assignments, as well as who is accountable for each activity, corresponding schedules, and the deadlines to be accomplished. The phases in implementing a project include quality control, progress monitoring, change control, and risk management. The first thing we are going to address is risk management, because if you have prepared the project, it is necessary to identify any considerations that can have an effect. Throughout this case, 'Risk' is supposed to be anything that can influence project delivery deadlines negatively. A risk log is utilised to record and grade risks and is accompanied by an action plan to minimise the risk identified. Issues management is a related area and refers to the concerns raised by any stakeholder regarding the project. This step also includes the Project Manager in quality control, where daily checks are performed at formalised meetings to guarantee that the product is reviewed to specific predefined criteria.


14

3. Closing a Project

All projects are planned for a particular time period, and the project completion cycle is an essential part of project management and it provides a formal approval to signify their sign‐off on the project. This is normally achieved in the form of a consumer acceptance form which is the customer's formal acknowledgement that the project is completed. The project team is disbanded after it has been signed off and no further activity is carried out. Nevertheless, the project team will come collectively and formally end the project and address any remaining problems such as continuing maintenance, the closing of project files, and undertaking a management analysis of the project. The Project Manager also develops a process improvement document which evaluates the procedures utilised by the project to allow the organisation to learn about this project and render more effective future projects. Because the project was managed by a team of people who invested a lot of time engaging in the success of a particular piece of action that took them out of their normal day‐to‐day activities, it is necessary to have some social closing event.


15

Introduction to Product Roadmap

A product roadmap is an action plan for how a solution or product will evolve over time. Roadmaps are used by product owners to outline the future functionality of the product and when new features will be released. When a roadmap is utilised in agile development, it provides significant context for the team's daily work and also it should be responsive to shifts in the competitive landscape. A single product roadmap may be shared by multiple agile teams. In order to build a roadmap, market trajectories, engineering constraints, and value propositions are taken into account by product owners. Once these factors are reasonably well-comprehend, they are expressed in a roadmap as timelines and initiatives. A simple roadmap for a product team is given below. The initiatives are in blue, and the milestone-markers indicate timelines in red. Sep Oct Nov Dec Jan Feb Mar Apr

Team in Space Website

TIS Mobile Site

TIS Native Apps

TIS Native Apps

TIS Launch

Mobile Group Travel


16

A product roadmap is generated as a result of strategic planning. It documents both the organisational strategy and the overall aims of a product. A strategic product roadmap typically involves the following key points:

Product vision: what you want your product to become in the future.

Strategy: an execution plan detailing what your company is going to do to meet the vision.

Goal: a time-bound objective that can be measured by a specific metric.

Initiative: broad themes that unite features that must be implemented to achieve a goal.

Feature: an actual piece of a product that’s either part of functionality or a third-party application.

Time-frames: dates or time periods for a certain goal or feature to be finished. As a rule, a product roadmap suggests only an approximation.

Status markers: used to track the progress of work.

Metrics: assistance in the measurement data-driven goals, e.g. churn rate or organic traffic.


17

Introduction to Iteration Development in Agile The agile iterative approach concentrates on delivering value as quickly as possible in increments instead of at once. Specifically, this approach is helpful in software development and product development. An iterative approach refers to the software or product development process split into various explicit iterations or versions, each delivering a few important improvements or further features. The iterative methodology enables software developers to constantly adjust, refine, as well as review software development processes to enhance their performance incrementally. The iterative approach of agile make opportunities for continuous evaluation and improvement in development processes. The design of an iterative approach is straightforward and easy to execute, irrespective of the context


18

Agile Iterative Development

Iterative development breaks down huge tasks into shorter pieces that can be repeated, researched, as well as refined during the software development cycle. Project developers utilise the most recent development, or iteration, as a base from which to design additional products or processes. The iterative development model attempts to advance and refine a product or process in each and every iteration.


19

Incremental development is an approach that utilises a set number of steps, or increments, that follow a progression's linear path. The steps involve conception, design, analysis, testing, maintenance, release, and other increments. An example of incremental development is the waterfall model. Every sequential increment reacts to changes or developments that have been done already. Especially, this is software development which is equivalent to the factory assembly line. While the incremental approaches are not more flexible than iterative approaches, usually these two methods are utilised with each other in software development projects

Fre

qu

en

cy o

f D

eliv

ery

Degree of Change

LOW

LOW

High

Iterative &

Incremental

Incremental

Predictive Iterative


20

The agile iterative model, or PDCA cycle, is the agile iterative development's centrepiece. Agile iterative software development projects are implemented as per the following four-step pattern:

P (Plan): Iteration planning concentrates on the requirements' planning and discussion and project objectives. Throughout the planning phase, software developers recap made iterations and discuss expected requirements moving ahead.

D (Design): Iteration implementation is concerned with analysing, designing, and implementing projects. The team develops software throughout this cycle's phase. Developers may also test the product's functionality in the Design phase.

C (Check): Iteration testing is concerned with making sure the deliverable satisfies the project requirements. If specific criteria are not met, the team can move backwards to the other phases for more improvements.

A (Adjust): Iteration evaluation refers to reviewing the iteration or cycle's work in a comprehensive way. Its backlog will also be refined by the software development team to prepare for upcoming iterations.


21

Requirements

Planning

Initial Planning

Analysis & Design

Implementation

Deployment

Testing Evaluation

Model 1: Typical Iterative Development Process


22

Employment of Agile Iterative Approach

The approach suits continually developing software projects for the given reasons:

A few requirements may develop throughout the development process. The agile iterative approach enables teams to modify and improve various aspects of a deliverable during the cycle, particularly in the Check and Adjust phases. The methodology’s cyclical and modifiable nature provides development teams with an enormous advantage over more rigid processes.

While working on a project, a development team may adapt to change in a quick and ‘productive’ way. The iterative approach’s PDCA model enables far more flexibility, adaptability, and speed than sequential approaches.

The urgency or risk which are associated with the components of the project, may change. The approach gives time and space for urgency and risk recognition, and alleviation in the process's initial stages.


23

Benefits of Agile Iterative Development

The agile iterative approach gives various benefits to software development teams, which are the following:

Flexibility for Making Changes: The methodology enables modification during the process of development.

Customer Involvement: Development teams concentrate on the feedback of the customer throughout the Design and Adjust the PDCA iterative cycle's periods.

Early Risk Identification and Response: Maintaining each and every iteration is more straightforward than maintaining the entire project at a time. The iterative approach enables development teams to tackle problems early on without needing the team to backtrack.

Rapid Delivery: The iterative approach does not need more time on documenting, allowing development teams to consume more time in designing and executing projects.

Testing During Iteration is Easier than Testing at the End of the Development Process: Teams can analyse risks as well as modify their deliverables by testing early.

Enables Cognitively-Diverse Teams to Experiment and Innovate: The iterative approach's modifiable and cyclical nature enables teams to test innovative ideas for their products.


24

The agile iterative approach enables software development teams to plan, design, check and adjust iterations. This software development model is a complete and accessible methodology that can be beneficial for agile organisations immensely. The agile iterative approach is more flexible, quicker, innovative, and modifiable than other approaches. The approach gives customers a space to be included throughout the development process, so no retroactive changes are needed to be made once a deliverable is released. Leveraging agile practices results in increased productivity for software teams and organisations. The agile iterative approach's continuous nature enables teams to become professionals in their roles and learn from mistakes. Several existing performance measurement tools assess the effectiveness of agile teams objectively, enabling for correct monitoring as well as evaluation.


25

Business Drivers in Change Management

It is beneficial to understanding the drivers. It can help in identifying

what type of change you are dealing. It is important if there is a

misalignment internally or miscommunication regarding the scope or

requirement for change. It can make implementing that change difficult

for all included.

External

These drivers are those with whom the leaders are more familiar and will

usually consider first while determining the underlying change's cause

and the extent of the change's impact. External drivers may involve

changing to satisfy the changing requirements/demands of stakeholders

or align internal systems with decreasing overhead costs and allowing for

a more internal flow of information.

Environment

Marketplace Requirements for Success

Business Imperatives

Organisational Imperatives


26

Internal

These drivers are more difficult to identify and articulate, but if they are

not attended to, they could contribute to a project which is unsuccessful.

Attending to both internal as well as external drivers is key to success. So

much concentration on one can result in challenges.

Cultural Imperatives

Leader and Employee Behaviour

Leader and Employee Mind-set

Most project will have an external driver that begins the requirement for

change, but usually, that external driver will trigger an internal driver.

For an organisation that is switching from a legacy platform or moving from excel to Salesforce, the main driver is a requirement to optimise operational efficiency and meet the needs of the clients, donors, volunteers, stakeholders. While it is tempting to say that the change is nothing more than that, it is essential to consider the internal effect this change will have inside the organisation.


27

SMART Goals

S - Specific

Usually, when you look at a specific goal, you will find that it can be break

into separate, more specific aims.

In this procedure, the initial step is to ask the five ’W’ questions:

What: What do I want to achieve?

Why: Particular reasons for, or aim or benefit of achieving goals

Who: Who is involved?

Where: Recognise a location

Actually, in these terms thinking may lead you to consider establishing a

few more specific objectives instead of one all-encompassing another,

which is given below:

To extend the training of initial customer to involve answers for the

five most common technical issues.

To refresh the website’s area of technical support inside two hours of

another issue getting obvious.

To execute a formal and unified system to covering the account

manager’s absence.


28

M - Measurable

Measuring the progress will assist a team to keep on the track, attain the

mark dates and feel the sense of accomplishment which drives it on the

constant effort which is needed to achieve the objective.

Usually, a measurable goal will give answer for the questions, like:

How much?

How many?

How will I know it’s accomplished?

A - Attainable

In establishing an objective there is little point that is also very

challenging to accomplish or outside your abilities, because this will just

help to de-motivate your confidence.

While establishing an objective, you should utilise your skills and current

abilities like an indicator for assuring that the aim or goal is ‘achievable’.

Setting you for an objective which is satisfied very simply will let you feel

cheated once it is accomplished.


29

R - Relevant

The goals which are relevant drives the department, company and team

forward. An objective which supports or is in arrangement with different

purposes would be viewed as a suitable objective.

It is cautious analysis of where you wish to be or what you need to

accomplish that will decide the significance of your objectives.

You should to consider also whether this objective is most appropriate

for you and your job, or whether it would be much suitable for it to be

allotted to a member of your team.

T - Time Bound

Objectives or goals must have a time-span or deadline. A commitment to

a time limit assist a team to focus on their efforts towards the conclusion

of the objective as well as stops objectives by being passed by other, the

tasks which are non-relevant may increase.

1. Urgency

2. Motivation

3. Focus


30

Business Case

A business case recognises the reasoning for starting a task or project

and assists in convincing a decision-maker to take action.

A well-structured, formal document, the business case tells the story of

an initiative from the beginning (initiative is triggered by what situation

or problem) to end (what value, benefit or return is anticipated). Usually,

business cases are written at the initiative or project level to secure

commitment and funding.


31

Value of the Business Case for Change Management

The business case is a powerful vehicle to present the rationale and

approach for change management as it assists in addressing some of the

most common challenges or objections to change management. The

following are the top responses for most commonly faced challenges or

objections to change management:

0 10 20 30 40 50 60

Change management looks than what I'maccustomated to

Change management looks soft and fuzzy

I don't see the value of change management

What does it really means to apply changemanagement to a project?

Chart Title


32

Foundation of the Business Case for Change Management

You'll need to answer the following four key questions to build a

business case for change management:

1. What is the Task or Project?

A business case proposes a particular task or project. Your “task or

project” is to apply a change management approach that is structured

on a specific project or initiative.

2. What is the Reasoning?

The reasoning and rationale for initiating the task or project are

presented by a business case. For the change management business

case, the reasoning is that the ultimate benefit realisation, value

creation and attainment of outcomes and results for the particular

initiative or project are tied directly to managing the people side of

change.

3. Who Are We Trying to Convince?

The decision-makers of the business case are the audience who can

eventually take action in terms of support and funding. Your likely

audiences are project leaders, senior leaders, and project managers

for the change management business case.


33

4. What is the Action We Need?

Usually, a business case is used to secure a level of funding and

commitment for the task or project. The actions you need are:

a. A commitment to apply change management on the initiative or

project

b. The funding and resources to apply change management

While the business case is a basic tool for initiatives and projects,

some change management practitioners have translated the

approach and rationale for change management into a formal

business case.


34

Benefits of a Business Case for Change Management

Below are the three benefits of using a business case to tell the story of

change management:

1. Gain Credibility

The business case itself is a document that is credible. It is familiar, and project leaders and senior leaders are familiar with the format, structure, and use of a business case. Leaders expect to see project descriptions, situational assessments, solution descriptions, and cost-benefit analyses while evaluating an undertaking and deciding on resources and priority. Your business case for change management clearly addresses all of these.

In addition, you gain credibility by putting in the effort to write a

business case. It shows that you have thought and considered several

aspects of change management and have taken the additional step to

Gain Credibility

Make the Connection to Project Results

Make Change Management Tangible

for Your Audiences


35

capture your reasoning in a formal document. You are presenting

change management, such as other efforts in the organisation are

presented.

Ultimately, a business case addresses the misperception directly that

change management is fuzzy and soft. You can clearly demonstrate

the value, need and approach for managing an individual side of

change with the business case as your vehicle.

2. Make the Connection to Project Results

These are common objections faced by change management

practitioners while introducing change management to project

leaders or senior leaders:

o "I don't really see the value of change management."

o "Can't we just tell people to change?"

o "We already have a communication plan, isn't that enough?"

Building support for change management is hard if you cannot connect

the people side of change to what leaders care about—getting the

anticipated outcomes and results from change.

The business case is a powerful vehicle for connecting the people side of

change and project results. Specifically, the business case's situational

assessment and problem statement section let you explain the rationale

of change management in a suitable context: the benefits realisation,

results, and outcomes of the change

The problem you are solving, or the situation you are addressing, is not

that "change management is missing on this project," but instead "to get


36

what we aspire out of this initiative, people must change the way they

do their jobs." It is a subtle but vital shift in conversation, allowing you to

express the requirement for change management in terms of project

success that is crucial for gaining buy-in and support. The problem

statement and situational assessment section of the business case is

your venue to show how project outcomes are linked to the people side

of change.

3. Make Change Management Tangible for Your Audiences

You answer the following question by completing a business case:

o "What does it really mean to apply change management?"

o "I'm not sure what you would actually do on the project."

o "We've already scheduled training, so aren't we done?"

Several leaders are reluctant to support change management just

because they do not comprehend what it actually means to apply

change management to a project. The business case provides you

with particular opportunities to make change management real for

your audiences.

One of the significant values of writing a business case for change

management is that you can explain change management in such

terms and language that will be understood by your audience.


37

In the description of the project section of the business case, you

present the following three aspects of your proposal for change

management:

Overview

Scope

Objectives


38

Explaining the scope of change management clearly (both what is out of

scope what is in scope) and defining the objectives clearly (what you

anticipate to deliver to the project) makes it real.

In the business case's solution description section, you give even more

detail about what it really means to apply change management to the

project. Change management will be presented in terms of:

Work Streams

Milestones

Deliverables

Roles


39

Realising Benefits

It's a process that spans the pre and post-delivery phases of projects.

Projects often promise the earth, but their outcome often falls way short

of the promise. It does two main things for us:

1. It brings real clarity to the target benefits of a project.

2. It brings accountability for benefits following project delivery.

How does it work?

It has three parts:

a. Identification: Defines crystal clear benefits and outcomes.

b. Planning: Defines all changes needed to maximise each benefit.

c. Realisation: Ensures plans are done, and benefits are maximised.

Identification Planning Realisation


40

Benefit Realisation Cycle

Identify and Structure

RealisationPlanning


41

MoSCoW

The MoSCoW method is a prioritisation technique utilised in business

analysis, management, software development, and project management

in order to reach a common understanding with stakeholders on the

significance they place on the delivery of each and every requirement; it

is also known as MoSCoW analysis or MoSCoW prioritisation.

Prioritisation Technique of MoSCoW plays a key role in Agile Project

Management. In an Agile project, understanding the importance of

different things is necessary. Due to the time being a fixed resource, so

prioritisation is applied to tasks, requirements, products, cases, user, and

so on. Be very careful as this is not an Agile technique (include Kanban,

Scrum, XP and so on); however, this technique is utilised in Agile.

The term MoSCoW an acronym which is derived from the initial letter of

each and every of four prioritisation categories (Must have, Should have,

Could have, and Won't have), with the interstitial Os added so that the

work can be made pronounceable. While the Os are typically in lower-

case to show that they do not stand for anything, the all-capitals

MOSCOW is also utilised.


42

Must Have Initiative

This category includes initiatives that are “musts” for your team, just as

the name suggests. They represent needs that are non-negotiable for the

product, project, or release in question.

For instance, a must-have initiative in releasing a healthcare application

may be security functionalities that assist maintain compliance.

Anything in the category of “must-have” is considered necessary for the

team to achieve. If you’re not sure about whether something belongs in

this category, ask yourself the following:

o What occurs if we release without this?

o Is there a more simpler way or workaround to achieve this?

o Will the release/product/project work without this initiative?

Initiatives is more likely a “must-have” if the product would not work

without an initiative, or the release becomes useless without it.


43

Should-Have Initiatives

This initiative is just a step below must-haves initiatives. They are

essential to the project, product, or release; however, not vital. If it is left

out, the project or product still functions. But, if they will add significant

value if included.

“Should-have” are different from “must-have” initiatives as they can be

slated for a future release without affecting the current one. For

instance, minor bug fixes, performance improvements, or new

functionality may be “should-have” initiatives. Without them, the

product still works.

Could-Have Initiatives

Another way of defining “could-have” initiatives is nice-to-haves. They

are not necessary for the product’s core function. As comparatively with

“should-have” initiatives, their impact is much smaller on the result if

they are left out.

So, initiatives that are placed in this category are usually the first to be

deprioritised in case a project in the “must-have” or “should-have”

category ends up larger than anticipated.


44

Will not have (this time)

One advantage of the MoSCoW method is that it places many initiatives

in the category of “will-not-have”. It helps in managing anticipations

about what will not be involved in a particular release (or another

timeframe that you’re prioritising for).

Placing initiatives in this category is one way to prevent scope creep. If

initiatives are in this category, then it is known by the team that they will

not be a priority for this particular time frame. A few initiatives in the

“will-not-have” group will get prioritised in the future, while others are

not likely to take place at all. Some teams select to distinguish among

those by creating a subcategory in this group.

The world’s largest global training provider

theknowledgeacademy.com

[email protected]

/The.Knowledge.Academy.Ltd

/+TheKnowledgeAcademyWink�eld /TheKnowledgeAcademy

/TKA_Training /the-knowledge-academy

To the best of our knowledge, the information contained herein is accurate and reliable as of the date of publication; however, we do not assume any liability whatsoever for the accuracy and completeness of the

above information.

Agile Change Agent

Documents

Transcript of Agile Change Agent