Sponsors of development projects generally want to know what they are going to get, when they are going to get it, and how much it will cost *before* they make the commitment to "purchase". In many businesses, while the software development process may be Agile, the reality is that other functions in the business - Documentation, Training, Marketing, Sales, Finance, Business Planning - need to know what's coming well in advance. When starting an Agile project these stakeholder needs must be met if the team is to get off on the right track, and be allowed to proceed without undue outside interference.
Centred on the use of the "Inception Deck", participants will learn techniques to kick off an Agile project that will help them to:
1. Create a shared understanding around the project’s goals.
2. Identify and understand risk on the project.
3. Build a high level plan for the project and setting the ground rules for change on the project.
4. Get agreement on a set of “project bounds” for scope/content, schedule/delivery, and resources/cost, to allow the project team to proceed independently and make their own decisions as the project progresses.
This session co-presented and pair-facilitated by Bill Bourne and Caroline Sauve
This workshop was presented at the Gatineau-Ottawa Agile Tour, November 24th, 2014. #GOAT14 http://goagiletour.ca/en/
AI Mastery 201: Elevating Your Workflow with Advanced LLM Techniques
Agile Project Inception Workshop- Getting Aligned and Making Commitments
1. Agile Project Inception
Workshop
Getting Aligned and Making Commitments
1
Bill Bourne & Caroline Sauvé
Gatineau-Ottawa Agile Tour 2014 #GOAT14
November 24th, 2014
This chart package will be available on-line, along with reference
resources.
2. Caroline Sauvé
Lean and Agile Coach
@caro_sauve
https://agilemeditation.wordpress.com/
http://boldradius.com/blog
Who Are We?
Agile Project Inception #GOAT14
2
Bill Bourne
Development Leader
@abbourne
ca.linkedin.com/in/williambourne/
bill@sourceform.ca
www.sourceform.ca
3. Why go through project inception?
What problems are we solving?
3Agile Project Inception #GOAT14
4. Project Family Car
Project Description: “As a driver I want to buy a 4
door car for my family. It should be economical and
reliable.”
Framed as a software project, before I “buy”, I need
to know:
What I will get?
How long it will take?
What it will cost?
Agile Project Inception #GOAT14
4
5. Project Family Car
Project Description: “As a driver I want to buy a 4
door car for my family. It should be economical and
reliable.”
Agile Project Inception #GOAT14
5
“No problem! We should be able to get started in two
months and we’ll probably take about 3 months to build and
test it. Assuming (of course) that the team doesn’t get
pulled on to building or repairing another car. We’ll plan out
the build together and give you regular “show and tells” to
review progress every couple of weeks.”
In House Agile Development Point of View…
6. Project Family Car
Project Description: “As a driver I want to buy a 4 door car
for my family. It should be economical and reliable.”
Agile Project Inception #GOAT14
6
“No problem! It will cost about $20K to $30K.
We’ll assign 1 junior engineer to build it.
We’ll deliver it in 2 to 3 months, and we’ll
give you demos of progress every 2 weeks.
We’ll work out the detailed features as we go.
Please sign here!!!”
Consultant Point of View…
7. Project Family Car
Project Description: “As a driver I want to buy a 4 door car
for my family. It should be economical and reliable.”
Four Doors
Economical?
Reliable?
Family Car????
Framed as a software project, what do each of the
stakeholders believe will fulfill the vision or need expressed
by the driver?
Agile Project Inception #GOAT14
7
9. Project Family Car
Project Description: “As a driver I want to buy a 4 door
car for my family. It should be economical and reliable.”
Does the driver have a place to park the car?
Does the driver have license to drive? How long will it
take for him to get a license?
Does the driver have “family activities” that we should be
aware of?
Does the driver live in chilly Ottawa or warm San
Francisco?
Agile Project Inception #GOAT14
9
10. Project Family Car
Project Description: “As a driver I want to buy a 4 door
car for my family. It should be economical and reliable.”
“The car needs to have a top speed that beats a Bugatti
Veyron… that’s never been done before.”
“The paint color has been changed 5 times because it’s not
quite right… the team is getting frustrated because they
aren’t done building the engine.”
“Driver wants the car to also be able to tow his new boat.”
Agile Project Inception #GOAT14
10
11. 10 Questions You’d be Crazy not to ask Before
you Start Your Next Project
Agile Project Inception #GOAT14
11
r
Ask tough questions early, when its cheap to change
Take a few days or so for every couple of months of project duration
Project Bounds Shrink as Time goes by
Neighbors can be a big help
Too late! Find risks early
12. The Source
Agile Project Inception #GOAT14
12
Project chartering is a gap in
Agile methods.
There’s value in identifying major
gaps early.
The Inception Deck is a
lightweight Agile project
chartering technique…
https://pragprog.com/book/jtrap/the-agile-samurai
13. Project Inception Outcomes
1. Creating a Shared Understanding
2. Understanding and Managing Risk
3. Product Context and Estimation
4. Putting it All Together – Go Forward!
Workshop Rules:
A. Ask questions - we’re here to help!
B. Smart phones welcomed to support your
work.
C. Work as a team.
D. Have fun!
13
14. Settle In With Your Team
Introduce yourself
Where you are from
What role you play on a project
What you are hoping to learn from this session
Bonus points (purely optional)
A past or current stressor on a project
Agile Project Inception #GOAT14
14
15. Inception Deck
A. Creating a Shared Understanding
1. Ask why we are here
2. Create an elevator pitch
3. Design a product box
4. Create a NOT list
B. Understanding and Managing Risk
5. Meet your neighbors
6. Show the solution
7. What keeps us up at night
C. Product Context and Estimation
8. Size it up
9. What’s going to give
D. Putting it All Together
10. What’s it going to take
Create the Project Bounds
Customize the Inception Deck
Keep it Agile and Fun!
Agile Project Inception #GOAT14
15
16. Inception Deck Purpose
Eliminate confusion and misuderstanding
Set Expectations
Highlight Challenges
Get Alignment
Build the sense of Team
Do this before you write a single line of code!
Agile Project Inception #GOAT14
16
17. Inception Deck Principles
It’s a “deck” not a document
Don’t get attached to the deck itself.
The 5 Cs:
Stimulate Conversations
Encourage Collaborations
Develop shared understanding – Consensus
Allow for Creativity
Its about Communication
Agile Project Inception #GOAT14
17
18. Create a Shared Understanding
A. Creating a Shared Understanding
1. Ask why we are here
2. Create an elevator pitch
3. Design a product box
4. Create a NOT list
B. Understanding and Managing Risk
5. Meet your neighbors
6. Show the solution
7. What keeps us up at night
C. Product Context and Estimation
8. Size it up
9. What’s going to give
D. Putting it All Together
10. What’s it going to take
Create the Project Bounds
Customize the Inception Deck
Keep it Agile and Fun!
Agile Project Inception #GOAT14
18
19. Create Shared Understanding
1. Ask why we are here (Really)
Teams make 1000s of decisions and tradeoffs
Goal + Decisions = Impact
Team needs to know why…
Motivate the team!
Empower self-organization
Agile Project Inception #GOAT14
19
What is the #1 reason for doing this project?
20. Create Shared Understanding
2. Create an Elevator Pitch – 30 seconds
Forces hard conversations happen:
Who is it for?
How is it different?
Why will people buy it?
What’s its value?
What’s the Minimum Viable Product (MVP)
Agile Project Inception #GOAT14
20
Brings Clarity and Focus to Project
22. Create Shared Understanding
2. Create an Elevator Pitch – 30 seconds
Project Description: “As a driver I want to buy a 4 door car for my
family. It should be economical and reliable.”
For “drivers”
Who “want an economical and reliable car”
The “CarolineAndBillMobile”
Is a “Family Car”
That “hummm….”
Unlike “derp derp…”
Our product “meep meep meeps…”
Agile Project Inception #GOAT14
22
23. Create Shared Understanding
3. What if your product was a box
What would it look like?
Would you buy?
Features -> Benefits
Agile Project Inception #GOAT14
23
24. Create Shared Understanding
3. What if your product was a box
What would it look like?
Would you buy?
Features -> Benefits
Agile Project Inception #GOAT14
24
• 555 HP engine
• 0-100 km/h in 4.7 sec
• Brake energy regeneration
• All wheel drive
Features
25. Create Shared Understanding
3. What if your product was a box
What would it look like?
Would you buy?
Features -> Benefits
Agile Project Inception #GOAT14
25
• 555 HP engine
• 0-100 km/h in 4.7 sec
• Brake energy regeneration
• All wheel drive
Features
• Pass easy on highway
• Impress your friends
• Save money
• Never get stuck
Benefits
26. Create Shared Understanding
3. What if your product was a box – What’s on the box
List the benefits (at least 3 compelling reasons why someone
would buy)
Create a slogan – something catchy
(go ahead and be cheesy!)
Draw your creation
Why would we buy?
Clarity
Focus
Alignment
Intent
Agile Project Inception #GOAT14
26
27. Create Shared Understanding
4. Create a “Not” List (Scope)
How do you tell someone what’s IN scope for their project?
Agile Project Inception #GOAT14
27
28. Create Shared Understanding
4. Create a “Not” List (Scope)
How do you tell someone what’s IN scope for their project?
Agile Project Inception #GOAT14
28
29. Exercise
Lego Desk Accessory Builder Kit
Answer “why are we
here?”
Create the elevator
pitch
Design a product box
Create a “not” list
Agile Project Inception #GOAT14
29
30. Understanding and Manage Risk
A. Creating a Shared Understanding
1. Ask why we are here
2. Create an elevator pitch
3. Design a product box
4. Create a NOT list
B. Understanding and Managing Risk
5. Meet your neighbors
6. Show the solution
7. What keeps us up at night
C. Product Context and Estimation
8. Size it up
9. What’s going to give
D. Putting it All Together
10. What’s it going to take
Create the Project Bounds
Customize the Inception Deck
Keep it Agile and Fun!
Agile Project Inception #GOAT14
30
31. Understanding & Managing Risk
5. Meet Your Neighbours
Your project community is always bigger than you think
Agile Project Inception #GOAT14
31
32. Understanding & Managing Risk
5. Meet Your Neighbours
Your project community is always bigger than you think
Agile Project Inception #GOAT14
32
Technical Writers
Training
Product Support
Help Desk
Professional Services
Security
Trials Team
Sales
Account Teams
Production
Support
Database
Administrators
Installation TeamsEveryone Else!
33. Understanding & Managing Risk
5. Meet Your Neighbours
The Greater Community:
Agile Project Inception #GOAT14
33
34. Understanding & Managing Risk
6. Show the Solution
You pick your architecture … when you pick your team!
Agile Project Inception #GOAT14
34
35. Understanding & Managing Risk
6. Show the Solution
Your pick your architecture … when you pick your team!
Agile Project Inception #GOAT14
35
36. Understanding & Managing Risk
7. What keeps us up at night?
Surface risky assumptions
New requirements and stakeholders
What you know you don’t know
What you don’t know, you don’t know
Agile Project Inception #GOAT14
36
37. Understanding & Managing Risk
7. What keeps us up at night?
Talk to your neighbours! Hear from the “other side” as well
as team members
If you hear something crazy… get it out there!
Better now than leaving it to later
But don’t create a:
“Whine chart”
“Cover Your Ass chart”
Agile Project Inception #GOAT14
37
38. Understanding & Managing Risk
7. What keeps us up at night?
Avoid whining and CYA
Agile Project Inception #GOAT14
38
39. Understanding & Managing Risk
7. What keeps us up at night?
Conduct a project “Pre-Mortem”
A. Get the team together … plan for an hour or so
B. Imagine a fiasco … the project totally failing…. so bad its
embarrassing
C. Ask “What could have caused this?” Each person (on their
own) generates possible reasons for the fiasco
D. Consolidate the Lists
E. Prioritize the items, and pick a few “hot topics”
F. Re-visit the plan
G. Rinse and Repeat – review the list every so often.
Agile Project Inception #GOAT14
39
40. Exercise
Lego Desk Accessory Builder Kit
Meet the Neighbours
Conduct a mini Pre-
Mortem. Role play
some of the
neighbours.
Agile Project Inception #GOAT14
40
41. Product Context and Estimation
A. Creating a Shared Understanding
1. Ask why we are here
2. Create an elevator pitch
3. Design a product box
4. Create a NOT list
B. Understanding and Managing Risk
5. Meet your neighbors
6. Show the solution
7. What keeps us up at night
C. Product Context and Estimation
8. Size it up
9. What’s going to give
D. Putting it All Together
10. What’s it going to take
Create the Project Bounds
Customize the Inception Deck
Keep it Agile and Fun!
Agile Project Inception #GOAT14
41
1? 3 ? 6 mont hs?
Monday, 13 August, 12
42. Product Context and Estimation
8. Size It Up
Recognize you are guessing!
You do need a good, reviewed, Product Backlog to estimate
from.
If the Product Backlog is unstable, its too early to estimate
Use the “law of large numbers” to your advantage
The estimate for each User Story does not need to be
accurate, just unbiased.
Some will be high, some will be low… so the overall estimate
will come out “about” right
Agile Project Inception #GOAT14
42
43. Product Context and Estimation
8. Size It Up
Make sure your sponsors/stakeholders see this!
Agile Project Inception #GOAT14
43
Guestimation
Add user
Print itinerary
Cancel trip
Book permit
Update permit
Search
Create device
Add swap trade
Add option
Cancel plan
Master story list
44. Product Context and Estimation
8. Size It Up
Think Small – Break up a large project if necessary
Agile Project Inception #GOAT14
44
Think small
1 2 3 6 9 12 months
Risk
Project length
(Randy Mott)
Monday, 13 August, 12
45. Product Context and Estimation
9. Be Clear on What’s Going to Give
Need to deal with “too much to do and not enough time”
Agile Project Inception #GOAT14
45
46. Product Context and Estimation
9. Be Clear on What’s Going to Give
Need to deal with “too much to do and not enough time”
Agile Project Inception #GOAT14
46
Time Budget Quality Scope
47. Product Context and Estimation
9. Be Clear on What’s Going to Give
Use Trade-off Sliders
Agile Project Inception #GOAT14
47
• They can’t all be ‘ON’
• No two can occupy the same level
• Quality should probably be excluded, or always be ‘ON’
• Low quality is ultimately expensive, slows the project, and increases costs.
But these are not enough…..
48. Product Context and Estimation
9. Be Clear on What’s Going to Give
Use Trade-off Sliders
Agile Project Inception #GOAT14
48
Include other important stuff……
50. Putting It All Together
A. Creating a Shared Understanding
1. Ask why we are here
2. Create an elevator pitch
3. Design a product box
4. Create a NOT list
B. Understanding and Managing Risk
5. Meet your neighbors
6. Show the solution
7. What keeps us up at night
C. Product Context and Estimation
8. Size it up
9. What’s going to give
D. Putting it All Together
10. What’s it going to take
Create the Project Bounds
Customize the Inception Deck
Keep it Agile and Fun!
Agile Project Inception #GOAT14
50
Time Budget Quality Scope
Monday, 13 August, 12
1.How much?
Monday, 13 August, 12
2.When?
Monday, 13 August, 12
Monday, 13 August, 12
How Much? When? What Will it Take?
“The Furious Four”
“What Every Executive Wants to Know”
51. Putting it All Together
10.What’s it Going to Take?
Agile Project Inception #GOAT14
51
52. Putting it All Together
10.What’s it Going to Take?
Be Clear on Your Team
Agile Project Inception #GOAT14
52
Put anyone (or skill) you feel is necessary for the success of the project on this list
53. Putting it All Together
10.What’s it Going to Take?
Be Clear on the Resources You Need
Agile Project Inception #GOAT14
53
Put the resources you need to be effective and complete the project
# Item Description Why
6 PC Desktops For developers
2 Windows Surface RT For testing with
3 Linux Servers For back end development & testing
Access to current
production system
Need logs and performance data
Dedicated LAN and
WiFi system & test
equipment
Network performance impairment test
equipment. Load balancer
To to test system
performance when
network is impaired.
54. Putting it All Together
10.What’s it Going to Take?
Clarify Who’s Calling the Shots
Agile Project Inception #GOAT14
54
55. Create Your “Project Bounds”
Describes when an Agile Team needs to escalate
change decisions to stakeholders.
The Agile team must be allowed to be self-organizing and
make their own decisions on the day-to-day execution of
the project.
However at some point, when changes exceed a certain
agreed point, then the decisions on how to handle the
change must be brought to the “stakeholders”
Agile Project Inception #GOAT14
55
Time Budget Quality Scope
56. Sample Project Bounds
Describe when an Agile Team need to escalate change decisions to
stakeholders, and when stakeholders need to escalate to Agile Team
“Out of Bounds” is not always negative!
Agile Project Inception #GOAT14
56
Criteria Value Range Notes
Date: May 15th, 2015 +/- 4 Weeks
Scope: All product backlog epic stories
listed as “anchor”
30%-60% of the
epics listed as
“important”
Budget: $300,000 +/- 20%
Staffing 7 person scrum team assuming
regular vacation schedules
+/- 3 person
months
Loss of staff, extended illness,
new SME staff need to be
added, etc
Quality Whether this should be on the
project bounds is debatable
Other
57. Customize the Inception Deck
Be flexible … you don’t always need every slide
Add or adapt slides if it will help with understanding
Keep the deck visible at all times
Update certain activities as it makes sense (e.g. elevator
pitch; what keeps you up at night?)
Several adaptations out there... Check ‘em out!
Agile Project Inception #GOAT14
57
58. Summary
The inception deck outcomes…
1. Creating a Shared Understanding
2. Understanding and Managing Risk
3. Product Context and Estimation
4. Putting it All Together – Go Forward!
Hard questions, hard conversations…
It’s about establishing safety.
Cost of delay: client, team, business.
Agile Project Inception #GOAT14
58
59. Parting Thoughts
Keep it Agile and Fun
Focus on the conversations, collaboration and shared
understanding
Don’t be afraid to have the difficult conversations
You can use the Inception Deck at “Concept” and “Commit”
Gates when using Agile under a Phase Gate Process
Agile software development under a Phase Gate “top level”
product development process
Agile Project Inception #GOAT14
59
60. References
“The Agile Samurai”, Jonathan Rasmusson, https://pragprog.com/book/jtrap/the-agile-samurai
“Agile Project Initiation Techniques – The Inception Deck and Boot Camp”, Jonathan Rasmusson,
http://rasmusson.files.wordpress.com/2008/01/rasmusson-agileinceptiondeckbootcamp.pdf
The Agile Warrior Blog – The Agile Inception Deck
https://agilewarrior.wordpress.com/2010/11/06/the-agile-inception-deck/
The Agile Warrior Blog – Blank Agile Inception Deck Template
https://agilewarrior.wordpress.com/2011/02/06/blank-agile-inception-deck-template/ and
http://anoriginalidea.wordpress.com/2011/01/27/powerpoint-inception-deck-template-for-the-agile-
samurai/
Nine Agile Steps that Injected magic into our project http://nomad8.com/9-agile-steps-that-
injected-magic-into-our-project/
“Introducing Agility into a Phase Gate Process”, Construx, V1.1, 2011
http://www.construx.com/Resources/White_Papers/Introducing_Agility_into_a_Phase_Gate_Proce
ss/
An excellent paper on how Agile processes can fit effectively “under” a traditional end-to-end phase gate
process.
Project Pre-Mortems: http://en.wikipedia.org/wiki/Pre-mortem https://hbr.org/2007/09/performing-
a-project-premortem http://www.wdtb.noaa.gov/courses/risk-comms/module_2/documents/pre-
mortem.pdf
“Project Success Sliders”, Mountain Goat Software
http://www.mountaingoatsoftware.com/tools/project-success
Also check out the other tools on Mike Cohn’s site
Agile Project Inception #GOAT14
60
Caroline
I am a Lean and Agile Coach working at thriving startup headquartered right here in Gatineau called BoldRadius.
BoldRadius is a custom software development, training and consulting firm specializing in the Typesafe Reactive Platform; Scala, Akka and Play Framework… but I work side by side with these amazing people and our wonderful clients to rapidly deliver high quality valuable software.
I’ve been known to be quite tweetable…please add me to your Lean / Agile list… because that’s where I live on Twitter… though the occasional tweet about my 5 year does slip in every once and a while.
Lastly, I have a blog about all things lean and agile that go through my head… called Agile meditation…. where I desperately need to spend more time. It’s just too damn engaging to work at BoldRadius… ;-)
I also blog on the BoldRadius website… where you’ll find my Lean Agile experiments in there among all sorts of practical information about Scala, Akka and Play.
Caroline
If inception is the conscious starting point of a thing… then project inception is the conscious starting point of a project. If Agile encourages us to create smaller development cycles… where the team adjusts planning and execution based on what they learn… what in the heck are Bill and Caroline going to talk to you about today?
Why would an Agile project go through a distinct project inception phase before iterating over the smaller development cycles?
To better understand why we should go through project inception, let’s consider what problems the inception process can solve.
Caroline
For this, let’s take a look at the following example in order to better understand what can happen on software projects…. Consider that a customer or project manager has approached your team and defines the following project…
Let’s frame this in terms of your typical software project… our customer is “the driver” and this “driver” will probably want to know from the software team “what he will get”, “how long it will take” as well as “what it will cost”.
Bill - From an in-house development point of view…
Caroline
From an Agile Dev Consultant’s point of view… for the record this is absolutely not how we approach projects at BoldRadius. Though it can be a little jarring at times how quickly clients want to jump to a dollar amount without better understanding or exploring their own expectations in order to better ensure a good match in capabilities with a consulting organization.
But I digress… let’s assume that the driver is extremely motivated and decides to proceed with the project. He might then ask himself… ok, tell me more about the car…
Caroline
The software team kicks into gear… ok, looking at this, we can extract a few requirements: four doors, economical, reliable… what’s this family car business? We’ll side that one as a “non-functional” requirement for now and see how it goes.
Now consider for a moment, as we dive into this “story writing / requirements gathering phase” as a software team… what do each of the stakeholder believe will fulfill the vision or need of expressed by the driver. Put another way, think… designers, developers, testers, documentation team… imagine what each of them envisions this “reliable, economical, 4 door family car” will look like.
Caroline
Are any of these in line with what the “driver” expects?
If all of these people are on the same team… what car is the team building? How will this different view impact their ability to deliver? How can we be sure that we are meeting the driver’s expectations and that our client will be happy with what we deliver if his vision is the Honda and ours is the Reliant over here?
Though technically I think the reliant fails the reliable test… what with the tipping over when it goes around any corner… ;-)
I think that you will agree, failure to have a well established shared understanding around what we are doing and why we are doing it… it’s a project killer. Establishing a shared understanding is extremely important to the success of the software project.
Caroline
What about requirements around the “building of the car” that are ancillary but no less important requirements to consider? -> READ SLIDES
This speaks to those devilishly “hidden requirements” that can have a deep impact on the project. The stuff that the driver doesn’t consider important when describing his family car? - go through bullets.
The stakeholders on these “hidden requirements” would benefit from understanding more about the car so that they can proceed with their own work (e.g. What kind of license the driver needs will depend on the type of vehicle being purchased.)
So surfacing and managing risk is a very important part of Project Inception...
Caroline
But what will happen when the team starts to dig in the real fun begins? -> READ SLIDES
Changes in scope, new requirements, significant increases in estimates… as we learn new things about what we are building either from a technical perspective or from a requirements perspective, how will we make decisions? In the heat of the moment will the team have the tools to think it through in order to make the most effective choice?
Bill
Bill - Most Agile methods tend to be silent on project chartering. Clearly we need to fill this gap!
Finding major gaps and misalignments after a project starts is painful, inefficient, expensive and “Not Fun”… in the worse case, you miss the point completely.
Bill - We’ve categorized project inception deck into exercises aimed at achieving three outcomes…
Creating a shared understanding
Understanding and managing risk
Product context and estimation
And yes, this is a workshop… so after each section’s inception activities are explained, you will get to work together in groups to practice the skills for yourself. A few ground rules for this…
Bill
Introduce activity, then give them time to share (5-10 minutes); ask people if they are willing to share their “hopes and stressors” with the group. We’ll use these to add to our presentation as we go (do we have a white board?)
Bill
Bill - It’s a “deck” not a document
Don’t get attached to the deck itself.
The 4 Cs:
Stimulate Conversations
Encourage Collaborations
Develop shared understanding – Consensus
Allow for Creativity
Emphasize:
Build relationships
Need everybody involved – find a way to have the conversations
Surface assumptions – “When you assume you make an ass of U and me!”.
{Use this slide for activity}
Bill - It’s a “deck” not a document
Don’t get attached to the deck itself.
The 4 Cs:
Stimulate Conversations
Encourage Collaborations
Develop shared understanding – Consensus
Allow for Creativity
Emphasize:
Build relationships
Need everybody involved – find a way to have the conversations
Surface assumptions – “When you assume you make an ass of U and me!”.
Caroline
The idea behind the inception deck is that if we can get the right people in the room and ask them the right questions, this will do wonders for collectively setting expectations about our project. Who are the right people? Customers, designers, developers, testers, documentation specialists… anyone who can contribute to the project and help with execution.
So considering our example in the opening of the presentation: “As a driver I want to buy a 4 door car for my family. It should be economical and reliable.” Consider… how can we build a shared understanding around this idea? Inception Deck offers 4 activities that are aimed at doing this…
{Use this slide for activity}
Caroline
The first is to ask, “Why are we here?” – Let’s consider who our customers are and why we decided to do this project in the first place?
If we cannot answer this question, what will happen when we need to make decisions and tradeoffs as the project proceeds?
We would be missing an important guiding light to help us make decisions as we proceed in the project… it also prevents us from making the most impactful decisions towards achieve this goal…
In addition, there is an intrinsic need for the team to understand why they are working?? This empowers self organization and motivates the team the most fundamental way.
The exercise is fundamentally this… as a team, define and understand the #1 reason for doing this project? Come to a shared understanding, ensure that everyone on the team is able to communicate it.
Caroline
The elevator pitch digs a little bit deeper into the “why are we here” exercise. The goal of the exercise is to force important conversations to happen WRT user experience… in the true sense of the word – not just in the use of your product, but in the anticipated use of your product as well..
Put another way, why would a user want what we have to offer compared to what else is out there?
{Use this slide for activity}
Caroline
An elevator pitch is a very brief synopsis of the project that usually follows this format…to be clear, it can be very difficult to fill in these blanks at the start of the project. One helpful trick is to actually revisit this elevator pitch throughout the inception process… it can be quite interesting to see how much this elevator pitch can change over time throughout the inception phase.
Again, elevator pitch is tricky but so very important for the whole team to understand and be able to express.
Caroline
Ok, let’s take that for a test spin on our car project…
Project Description: “As a driver I want to buy a 4 door car for my family. It should be economical and reliable.”
Caroline – So this activity tends to work quite well if you have sales, marketing and designers on your team… a pure backend development product will likely have more trouble with this one. The goal here is to build the product box… go through slides.
Caroline
Caroline
{Use this slide for activity}
Caroline
Once you complete the creation of your product box, you may want to try and go back and take another kick at the elevator pitch.
Caroline
This is where order of inception exercises get to be interesting… if you have done your job well up to this point, you’ll have a clearer sense of why your are building the product… this vision should help you to guide creation of a “Not List”. The idea here is to identify what’s in and what’s out.
{Use this slide for activity}
Caroline – Explain each section. The goal is to move stuff from “unresolved” to “in” or “out” piles as the project progresses… the beauty is that you are acknowledging upfront what know and don’t now here… and it’s a great visualization of the current state of the project and can be a living document that you carry with your throughout the course of the project.
Caroline
Each team will be given a different inception exercise to undertake… your job will be to define a “lego” desk accessory product that you will take through the inception process. Pick your desk object, then go through the exercise as a team… at the end of the activity, each team will have a chance to present the results of the exercise.
10 minutes for activity – 5 minutes to share… if time runs over, get people to react to how useful the activity was at surfacing shared understanding.
Caroline – This is personally my favourite section in the whole deck because YOU WILL LEARN new things about the project in this section. I’ve reviewed detailed proposals from clients… pages and pages of diagrams and documented vision… and going through these exercises always reveals new and critically important information. ALWAYS!
Caroline – Meet your neighbours! The goal of this activity is to extend and better understand who benefits from and will contribute to the project. This community is always larger than you think!!!
Caroline
Do this at the start of the project… hold a kickoff. Meet them before the critical milestone for integration happens. Talk about your perspective on the work to be done… ask them about theirs… create the face-to-face contact.
When you brainstorm on this, when you explicitly ask about additional stakeholders… you’ll usually be surprised to find a few that you didn’t consider initially. So while the core team may indeed include users, design, development, testing… there are additional stakeholders who contribute and consume this work that need to also be taken in to account.
To be clear, this isn’t just about being friendly.. These stakeholders can have a very real impact on your project. I’ve seen documentation specialists who turned out to be more knowledgeable than the Product Owner on the existing system. I’ve seen projects fall down at integration time because they failed to connect with important partners on the legal team – we are talking ship stopping failures here folks.
{Use this slide for activity}
Caroline
What you typically do here is work to define the core team and then “everyone else” outside the circle. Consider all the ancillary functions here..
Caroline - Now I know what you’re thinking. Enough context already! When will we get down to business and start talking about how we are going to build this thing? And the answer is right now.
Caroline… the goal here isn’t to create detailed architecture of the system… rather it’s about laying down some ground rules about what we are and aren’t going to do…. acknowledging explicitly what items are still in question. Why would we do this?
• It sets expectations around tools and technology.• It visualizes assumptions around project boundaries and scope
• It communicates risk.
Caroline… this is a question that I have used again and again on projects. I’ve put forth this question during sales call, during project inception, at retrospectives.
It’s amazing to think that people bottle all those worries inside and that…. by simply asking this question, usually all sorts of constraints and new requirements can come pouring out...
Caroline
Caroline – not all risk communicated is something that needs to be solved by the team and identifying what has value tackling and what doesn’t is very important. This becomes a case of “what do we control vs what we can’t control kind of thing…
{Use this slide for activity}
Caroline – once you have identified the risk factors, confront them head on by holding a “pre-mortem” on the project. Here’s how this works… the idea is to develop strategies to mitigate the risk factors up front. It’s also prepares people for the worst… imagine the worst thing happens… what would have done differently? Love this meeting…
Teams will be begin with a meet the neighbors exercise… define your core group of stakeholders and then supporting stakeholders required for you to build your project. Visualize this…
Everyone will conduct a pre-mortem on their project… 5-10 minutes Imagine the fiasco. Surface what happened to get you there… prioritize this list of concerns. This is what will keep you up at night… You’ll again be expected to present your outcomes to the group. If time permits we will also talk about how effective the activity was at surfacing risk.
Bill
Bill
The “Law of large Numbers” in estimating is counter-intuitive, but a key concept in Agile estimating.
Its one of many reasons why you want to have fine-grained User Storys.
Think… if 1/3 of the estimates are about right, 1/3 are underestimated by 50% and 1/3rd overestimated by 50%… then our over overall project estimate will be bang on!
We know all kinds of changes of all sorts will happen during the project, and we know that estimating is guessing … so its simple a waste of time to agonize endlessly over an individual Story estimate…
In fact… we don’t even need to be unbiased, as measuring our team’s velocity will take care of any biases in estimating.
You should run a few sprints before making a final “commitment” to a schedule so you can calibrate your team’s velocity.
Bill
Bill
Bill
{Use this slide for activity}
Bill
{Use this slide for activity}
Bill
This is a good time to talk bit about “quality” as a slider… “Negotiating quality” is almost always a bad idea.
“You can pay me now, or you can pay me (much more) later”
Its been known for 30 years that’s its cheaper to prevent, detect and remove defects as close to where they are injected as possible:
User Story reviews
Design Reviews
Code Inspections [The single most productive thing you can do to remove defects]
Design testing/TDD
Early acceptance testing
It will be much cheaper and faster in the long run to not skimp on quality.
Its better to skimp on features.
[Eg I had one project where we went from a first sprint to an in service system in a hospital in under 4 months with a team of 5 people To do this we dropped all features for configuration & set-up, among other features. We sent a developer on-site to manually create the configuration in XML files! We got the essential product into the hands of the customer. The customer was happy, and we got great feedback… Server, web client, and iOS client were all high quality… pretty much zero field reported defects]
{Use this slide for activity}
Bill
Bill - It’s a “deck” not a document
Don’t get attached to the deck itself.
The 4 Cs:
Stimulate Conversations
Encourage Collaborations
Develop shared understanding – Consensus
Allow for Creativity
Emphasize:
Build relationships
Need everybody involved – find a way to have the conversations
Surface assumptions – “When you assume you make an ass of U and me!”.
Bill
Bill
Bill
Bill
Bill
Bill
Bill
Changes are not always negative:
We can make a $25M sale to a new customer if we do an additional epic… we can do this by adding a sprint
We found a way to avoid making that major purchase of a 3rd-party S/W library… its saving us $100K. What should be do with the savings?
Etc.