This is all the templates from the 'Launching Agile Projects' workshop

1. Launching
Agile Projects
Template Pack

2. Elevator Pitch Template
Target customer
For
Who
Our Product Is
Customer need, opportunity or current dissatisfaction
That
Key benefit for this customer
Unlike Alternative solution or competition
Our
Product
Product category - what your product will actually do
Why it meets the need better than the alternative
@simongirvan
Based on a format from “Crossing The Chasm” by Geoffrey Moore

3. In Scope Not In Scope
Unsure
The NOT List
These are the things that you are certain are in scope for the project These are the things that you are certain are NOT in scope for the project
These are the things that you aren’t sure whether they are in scope or not in scope.
Based on ideas from “The Agile Samurai”, by Jonathan Rasmussan
@simongirvan

4. Assumption Map
Have
Evidence
Brainstorm all your assumptions and map onto the
horizontal axis first.
Then, map onto vertical axis ands decide what to do!
@simongirvan
No
Evidence
Important
Not
Important
Based on ideas from @davidjbland, @danto_ma and @AlexOsterwalder.

5. 1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Awake List
These are the things we are are worried may
keep us awake at night
What are the things that you personally are worrying about? This is more than
just project risks. Include non-technical factors like people, facilities, processes,
skills, other demands on your time, office politics, etc. Discuss amongst the
team what you can do about them.
@simongirvan
Based on ideas from “The Agile Samurai”, by Jonathan Rasmussan

6. The Wheel of Pain Discuss each factor and score based on how much that factor
makes it difficult to apply agile approaches.
For high spikes or categories, consider what you can do?
@simongirvan
How does this factor help you work
with an agile mindset?
0 - It is a perfect fit
1 - It really helps us
2 - It’s OK
3 - It makes it a bit more difficult
4 - It makes it really hard
5 - It makes it almost impossible.
What will you do about it?
Note any mitigations or interventions here

7. @simongirvan
Understanding the Wheel of Pain
Team Factors
Size - The ideal team size is 3 - 9.
Skill - How skilled and experienced is the team in the technologies
and problem domain?
Agile Experience - How experienced is the team with agile
development, and the approach chosen?
Maturity - Have mature is the team? Have they worked well
together in the past?
Availability - Are the team dedicated fully time to this work?
Each factor on the wheel of pain is something that is important when successfully applying an agile mindset to developing your product
or solution. However, each factor can also make this really hard, and can lead to projects struggling to deliver, or failing to meet customer
expectations.
Considering each factor on its ability to help or hinder can provide an insight to what problems you may face and allow you to consider
what mitigations or interventions you can apply.
Work Factors
Clarity - How clear is the work? Do you know how success will be measured?
Does everyone understand what needs to be done (including the stakeholders)?
Stability - Is the problem or the solution likely to change much? If so, how will
you know?
Complexity - Is this a complex problem (or solution) to understand or explain?
How important is it that everyone understands the complexity? Is documentation
important?
Non-functional Dependancies - Have you thought about them? Are they
challenging? What about support?
Dependancies - What are the incoming and outgoing dependancies? Are you
worried about any of them?
Stakeholders
Empowered Product Owner - Do you have one?
Availability - Are your stakeholders (not just product owner) available for the team
when they need them?
Agile Experience - How experienced is the PO and the wider stakeholders with
agile development and mindset? Do they ‘get it’?
Number - The more influential stakeholders you have, the more you will need to
manage them.
Environment
Geographic Distribution - Agile works best when teams and
stakeholders are co-located and within earshot.
Organisational Constraints - Does the organisation have any
constraints that will get in the way? Governance, meetings,
reporting, training, etc.
Regulatory Constraints - Are there regulatory or legal constraints
you must be aware of? Is external assurance or approval required?
Security - Are there particular security requirements or approvals?
Tools and Infrastructure - Is the infrastructure and tolling
available? It is suitable for your proposed solution?
Culture
Team - Does the team culture support agile practices and ways of working? Do they naturally want to deliver regular increments of business value?
Stakeholders - Is the culture of direct stakeholders one that supports incremental delivery of value and that will want to use early increments?
Organisation - Is the culture of the organisation one that supports agile delivery, and lean and agile concepts?
Governance and Process - Do the governance and organisational processes help with agile development or not?

8. What’s Gonna Give? Decide the extent to which you expect each factor to
be flexible or fixed.
If too many are too fixed, consider forcing a minimum
number of points (say 10 if scoring 4 factors)
@simongirvan
Deliver All
The Features
Based on an idea from “The Agile Samurai” by Jonathan Rasmusson
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
0 1 2 3 4 5
Stay On
Budget
Can be flexible
on this
Must do
this
Deliver on
Time
Deliver High
Quality
Others may include Useability, Security, Supportability, Accessibility, etc. If they matter to you or your stakeholders include them!
Must
Must
Must
Must
Must
Must

9. 1.
2.
3.
4.
5.
Working Agreement
As a team, we work together best when we…
These few (5 plus or minus 2) statements describe the contract between the team members. They describe specific
actions that the team have decided are important to them and will call each other out on. They will evolve with the team.
For example: “We respect each other’s quiet time - headphones on means no interruptions” @simongirvan
Based on ideas from “Liftoff”, by Diana Larson and Ainsley Nies

10. 1.
2.
3.
4.
5.
Simple Rules
These are the things we value and believe in
A few (5 plus or minus 2) short descriptions of the values and beliefs that the team find important.
Start with an action verb. Eg: “Ingenuity - We collaborate to help us come up with the best ideas.” @simongirvan
Based on ideas from “Liftoff”, by Diana Larson and Ainsley Nies

11. Committed Resources
These are the resources that the team need or
want to help them deliver the product
Consider anything that makes a difference to the team’s ability to deliver. Eg IT
resources, licences, training, accommodation, budgets, tools, time, availability
to stakeholders, hardware, etc
@simongirvan
Based on ideas from “Liftoff”, by Diana Larson and Ainsley Nies
Committed Resource Priority
(M/S/C)

12. Prospective Analysis Imagine all the possible events that could happen over
the next few months, both positive and negative.
Assess their impact (positive and negative) on the
project and the likelihood of them happening. Be bold.
@simongirvanProbability
Won’t Happen
Based on ideas from “Liftoff”, by Diana Larson and Ainsley Nies
Unlikely 50/50 Chance Likely Will Happen
Impact
-3
-2
-1
0
3
2
1