Createdy by

License
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.
Agility
Your Organizations
Corporate Culture
As a business we believe in observing hierarchy and the chain of command
Departments and disciplines within our business are separated by formal
boundaries and communication procedures between them
As a business we are risk averse and will only follow proven and tested
approaches
As a business we like to get 'everyone' involved
As a business we measure success as delivering against plan and
specification (rather than focusing mainly on value)
Governance and Control
Successful projects require a structured approach with clear sign off stages
between the various phases.
Formal approval (of certain aspects of the project) will be required from
stakeholders outside the direct project team.
Our business enforces a number of formal stage gates and or deliverables as
part of our delivery methodology
Decisions need to be formally documented so we know what was agreed
Your Project / Your Project Team
Goals & Objectives
Delivering value is more important than delivering to specification
We rather delay launch than not go live with all features
It is important for us to deliver the solution as we initially envisaged it
(delivering something different will be seen as failure)
Speed to market is more important than perfection
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
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
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
The project deals with a large number of heterogeneous stakeholders
The key challenge of this project is creatively.
The key challenge of this project is technically.
The key challenge of this project is politically or process-related.
Some areas of the project context are unclear and hard to determine
Emergence
Project context and environment are stable and unlikely to change
There are some high impact factors (internal / external) which are unknowns
/ require finalization.
Please Select:
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Please Select:
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
Neutral
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 MP
defines 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
Control question to above
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 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
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 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.
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.
Agile requires decisions to be made just in time and generally will be harder if constant
feedback from large stakeholder groups are required
Indicates inexperience with conceptual artefacts, and may thus mean having to provide
Big Design Up Front (waterfall)
Indicates requirement for formal reviews and sign offs, i.e. stages / gates (waterfall)
Agile working requires high degrees of involvement and collaboration, not a lean-back
attitude
Indicates preference of Big Design Up Front, rather than a focus on working software,
and thus a preference towards waterfall.
Indicates inexperience with conceptual artefacts, and may thus mean having to provide
Big Design Up Front (waterfall)
Indicates leaning towards iterative / evolutionary delivery (Agile)
Indicates preference of or need for Big Design Up Front, rather than a focus on working
software, and thus a preference towards waterfall.
Control question to question 2 in this block.
Indicates strong leaning towards Big Design Up Front (waterfall)
Indicates issues with empowered teams and high levels of low ceremony collaboration
Indicates a "review and critique" not a highly involved approach as is required for Agile.
Agile requires empowered decisions makers to be part of day to day work
May indicate issues with stakeholder availability which is required for high degrees of
agility
Preference to waterfall ways of working, though (gated) agile can allow for review
periods
What were previous learnings?
While this is correct, we need to be careful for this not to mean an unstructured 'free for
all approach'
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 better
suited 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
Control question to above
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
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 situation
The 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.
Key
Value Focus
Ceremony
Collaboration
-10
-8
-6
-4
-2
0
2
4
6
8
10
Value Focus
Decisions and Information
Responsiveness
Experience
Your Agility
Decisions and Information
Responsiveness
Experience
High Values indicate high degree of agility.
Axes are not in same scale!
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
Decisions and Information
Your Agility
Neutral
Project Profile
- 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?
Key
Goals-Objectives
Uncertainty
Complexity
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
Goals-Objectives
Technical Challenge
Creative Challenge
Political / Process Challenge
Project Profile
Volatility
Technical Challenge
Creative Challenge
Political / Process Challenge
High Values indicate high degree of risk / uncertainty.
Axes are not in same scale!
Indicates risk around clarity and stability of goals and objectives
Indicates a degree of unknowns and uncertainty
Indicates a degree of complexity
Goals-Objectives
Uncertainty
Complexity
Volatility
The Project
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
The Project
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 user
Neutral 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
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 wihtin
this category and
multiplies by max value
(=4).
Factor to
normalise values
selected 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