copy of agility questionnaire

8/11/2019 Copy of Agility Questionnaire

1/101

Createdy by

License


2/101

Marcel Britsch, June 2013

Agile Questionnaire by Marcel Britsch is licensed under a

Creative Commons Attribution-NonCommercial-ShareAlike

4.0 International License.

Based on a work at

http://www.thedigitalbusinessanalyst.co.uk/2014/07/Agile-

Questionnaire.html.


3/101


4/101


5/101


6/101


7/101


8/101


9/101


10/101


11/101

Requirements and Expectations

We usually capture many detailed requirements at the beginning of the

project

The project team alone will not be able to provide all requirements

We have a very clear idea of the final product must look like.

Requirements are a brief for the solution design team rather than a

contractual agreement we have to follow.

Product and Features

We are ok with starting on a journey of exploration where the final product

may not be what we expect (as long as this means delivering value (earlier))

We think a fully comprehensive solution serves our customers and the

business better than an earlier delivered version with a reduced set of

valuable features.

We find it easy to distinguish between valuable features and nice to haves.

As the project team we will need to consider other stakeholders wishes

towards requirements and features; some of these will be outside our

control.

Decisions and Information

The project team can make decisions and provide information when they are

required (Just In Time)

The project team includes or has easy access to relevant experts

The product we are working on reflects our decisions. We do not need

detailed history of previous conversations.

The project team has authority to make all project relevant decisions when

they are required (Just In Time)

Where the project context changes we will be able to make all relevant

decisions on the spot.Agile working allows us to change requirements as we go along without

impacting our initial expectation of scope.

Review and Feedback


12/101

We make decisions only after careful consideration by a number of

stakeholders.

In order to agree on a solution we need to see it concepted in great detail,

ideally with design visuals and content in place

In our business decisions have to be confirmed by various levels in the

hierarchy

We prefer to review and critique, rather than get involved. After all, you are

the experts.

Documentation and Process

We believe that solution quality is better when it is based on detailed

documentation and specification

In order to make decisions about the solution we need see what it will be

'quite clearly'

Solution quality is improved by delivering 'digestible' pieces.

Digital Projects are complex and require consideration of the big picture,

items cannot be looked at in isolation

Our stakeholders are comfortable to work at abstract conceptual levels

Interaction and Collaboration

We believe good products are designed on paper first, then built

Too much collaboration can dilute quality of outcome and be a waste of time disciplinary boundaries should be observed to a certain degree.

The Product Owner is there to approve at key stages but can leave the day

to day work to experts

This will not be the only project the team will be working on.

Some business stakeholders will not feed back / approve work in progress

but require a more formal feedback cycle.

You and Agile

Agile Experience

We have worked agile before, and it was successful

The reason we want to work agile is because we need flexibility of when and

how we engage with stakeholders


13/101

As a business we do not follow agile principles

As a business we have experience in delivering digital projects like the one

in question

Project Profile

Goals & Objectives

Goals and Objectives are clear and unlikely to change over the project

duration

We are certain we have correctly identified the root-cause for our project

All stakeholders are aligned to these goals and objectives

Requirements and Expectations

Scope creep is rare in projects our organization is involved in

Our organization is well versed in managing requirements

Project Context

The project domain has very clear boundaries

We have a good understanding of and control over all areas related to this

project

The project or some of its key aspects are tightly integrated into the wider

business context

A key challenge for this project are dependencies onto other projects or

areas of the business


14/101


15/101


16/101


17/101

Please Select:

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral


18/101


19/101

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral


20/101

Neutral

Neutral

Please Select:

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral


21/101

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral

Neutral


22/101


23/101


24/101

Rationale

Indicator for bureaucracy / hierarchy and may thus require formal process / stage-gates

and may thus conflict with Agile.

Indicator for bureaucracy which will hinder communication and collaboration, and thus

may become an issue for Agile.

Agile is about responding to change, evolution and iterative development. While an MPdefines a certain agreed scope, risk aversion may be an indicator against Agile

May indicate positive attitude towards collaboration or decision making by committee.

Agile is about delivering value early, even if this means deviating from the original plan

While Agile is highly formal, it is iterative and does not lend itself easily to formal review

and approval stages which stifle agility and velocity

Dto

Dto

In addition: While Agile can cater for defined deliverables including specification Agile

may be stifled by a traditional waterfall, BigDesignUpFront approach.

Agile is based on making decisions 'just in time' and values working software over

documentation. The evolving products is the status quo.

Agile is focused on delivering value early, not following a plan or specification just

'because'

One of Agile's paradigms is to always deliver on time and rather reduce scope

Control question to above



25/101

The standard approach seems to be Big Design Up Front. This attitude may conflict with

Agile methodologies

Ideally the project team includes all relevant stakeholders to provide information and

make decisions. Other stakeholders and experts can be included, but it needs to be

ensured that they are available when required

While this is helpful as vision/goal orthodox agile will not guarantee a specific outcome.

It does only guarantee focus on value.

MVP, however allows mitigation of this.

This is in the spirit of agile, lean product evolution and low ceremony

Agile is intrinsically evolutionary, although MVP can add a bit of guaranteed outcome

where required

Control question to a number of questions above

Indicates client understands focus on value and need / mechanism to prioritise

May indicate risk of scope creep ad issues with empowerment of project delivery team

when working agile

Agile requires decisions to be made and information to be provided just in time. This

means having access to experts and decisions makers there and then.



Agile works best lean, which means with low levels of documentation / specification





While agile appreciates and caters for change, we need to ensure that this is not seen as

a 'free for all' approach: Agile is highly structured and reglemented.


26/101


27/101

If the business does not work agile an individual project embedded in this context may

struggle. Keep in mind no project works in isolation.

Indicates whether the client has experience with this specific project type, i.e. whether

we can assume that the stakeholders understand Wireframes, UserJourneys, etc.

Understanding of the various conceptual artefacts is very important for lean, agile

working. Waterfall makes it easier to work with inexperienced stakeholders.

Multiplier

May pose to entire project. Waterfall may protect the supplier while agile may be bettersuited to deal with change if it occurs

Dto

While waterfall and agile require alignment with objectives, agile working requires an

intrinsic and intuitive understanding of and focus on values, objectives and goals

Waterfall may be easier to rain in scope creep, agile may lead to a better outcome due to

its evolutionary exploration. If scope creep is due to capriciousness then waterfall may

be advised, if it is based on complexity or difficulties to envisage the solution, agile may

be the better approach


Open domain boundaries indicate a risk / challenge of change and arising complexities.

Based on this we need to decide how to approach analysis, requirements management,

specification and delivery.

Big Design Up front approaches help avoid change and drive towards an early defined

goal, while Enough Design Up Front and evolutionary delivery embrace change but may

make it harder to deliver against initial expectations in full.

Indicates level of uncertainty and need to explore requirements and the solution.

See above

Integration into the organisational context (processes, systems, etc.) can be easier to

analyse up front or iteratively. Dependent on complexity and stability of the system to

integrate with Big Design Up Front or just Enough Design Up Front is recommended.

The latter being more suited in an Agile environment.

Also indicates need for detailed Context Modelling.

See various items above

Also indicates the need for detailed stakeholder analysis


28/101

Indicates a need for stakeholder analysis and management, as well as might indicate an

issue in agreeing scope.

Where stakeholders can collaborate and focus on business value, Agile is preferred,

where we have competing stakeholders and political challenges waterfall may make it

easier to control the situationThe area of challenge may indicate how strongly scope needs to be fixed, how closely

process needs to informed and whether to expect a lot of change or not.The challenge may also indicate team profile and cultural preferences / challenges

resulting from this related to ways of working etc.

Dto

Dto

Control Question related to questions higher up.

If that change is seen as something positive, we may allow for it, if it is seen as

disruption we need mechanisms to avoid it.

May indicate risk of change or simply unknown factors, which need to be considered and

mitigated independent of delivery methodology chosen.


29/101


30/101


31/101


32/101


33/101


34/101


35/101


36/101


37/101


38/101


39/101


40/101


41/101


42/101


43/101


44/101


45/101


46/101


47/101


48/101


49/101


50/101


51/101


52/101


53/101


54/101


55/101


56/101


57/101


58/101


59/101


60/101


61/101


62/101


63/101


64/101


65/101


66/101


67/101


68/101


69/101


70/101


71/101


72/101


73/101


74/101


75/101


76/101


77/101


78/101


79/101


80/101


81/101


82/101


83/101


84/101


85/101

Key

Value Focus

Ceremony

Collaboration

-10

-8

-6

-4

-2

0

2

4

6

8

10

Value Focus

Decisions and Informati

Responsiveness

Experience

Your Agility


86/101


87/101

Has the client fully signed up to the agile paradigm of

- value delivery

- partial delivery

- prioritization / MVP

Can we work in an agile environment or should this be

impossible because of

- hierarchy

- process

Can we collaborate?

- are the clients prepared to spend time with the team?

Ceremony

Collaboration

ion

Your AgilityNeutral

P


88/101

- are the clients able to work in an multi-disciplinary team?

Can the client provide the agile team with the support they need

to be lean and fast?

- do we have access to the right stakeholders

- is the project team empowered?

- can decisions be made JET- can information be provided JIT

Can the client deal with change in an agile way?

Is the client's attitude towards Agile positive?


89/101

Key

Goals-Objectives

Uncertainty

Complexity

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

Goals-Objec

Technical Challenge

Creative Challenge

Political / Process Challenge

roject Profile


90/101

Volatility

Technical Challenge

Creative Challenge

Political / Process Challenge

High Values indicate high degree of risk / uncertainty.

Axes are not in same scale!


91/101

Indicates risk around clarity and stability of goals and objectives

Indicates a degree of unknowns and uncertainty

Indicates a degree of complexity

tives

Uncertainty

Complexity

Volatility


92/101

Indicates a likelihood of hard-to-control change

Indicates that this project has a technical challenge

Indicates that this project has a creative challenge

Indicates that this project has a political / process related

challenge


93/101

he Project


94/101


95/101


96/101


97/101


98/101


99/101


100/101

Agilty section of questionnaire

Categories

Values to display

'neutral' line on

graph

Values selected by

user, normalised to

range from -10 to 10

Sum of values

selected by userNeutral Normalised Sum Sum

Value Focus 0 0 0

Ceremony 0 0 0

Collaboration 0 0 0

Decisions and Information 0 0 0

Responsiveness 0 0 0

Experience 0 0 0

Project Profile section of questionnaire

Categories

Values to display

'neutral' line on

graph

Values selected by

user, normalised to

range from 0 to 10

Sum of values

selected by user

Normalised Sum Sum

Goals-Objectives 5 6

Uncertainty 5 10

Complexity 5 8

Volatility 5 2

Technical Challenge 5 2

Creative Challenge 5 2

Political / Process Challenge 5 2


101/101

Counts questions wihtin

this category and

multiplies by max value

(=2).

Factor to

normalise values

selected by user

to range from -

10 to 10

Defines items /

values for selection

by user.Max Values Normalise to 10 List Value

16 0.625 Strongly Agree 2

38 0.263157895 Agree 1

6 1.666666667 Neutral 0

18 0.555555556 Disagree -1

4 2.5 Strongly Disagree -2

8 1.25

Counts questions wihtinthis category and

multiplies by max value

(=4).

Factor to

normalise valuesselected by user

to range from 0

to 10

Defines items /

values for selectio by

user

Highest Value Normalise to 10 List Value

12 0.833333333 Strongly Agree 4

20 0.5 Agree 3

16 0.625 Neutral 2

4 2.5 Disagree 1

4 2.5 Strongly Disagree 0

4 2.5

4 2.5

copy of agility questionnaire

Documents