10 Questions Agile Project Inception #GOAT14
•Descargar como PPTX, PDF•
8 recomendaciones•4,863 vistas
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (17)
Similar a 10 Questions Agile Project Inception #GOAT14
Similar a 10 Questions Agile Project Inception #GOAT14 (20)
10 Questions Agile Project Inception #GOAT14
- 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
- 8. Four door, Economical, Reliable Agile Project Inception #GOAT14 8
- 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
- 21. Create Shared Understanding 2. Create an Elevator Pitch – 30 seconds Agile Project Inception #GOAT14 21
- 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……
- 49. Exercise Lego Desk Accessory Builder Kit Create Project Sliders Agile Project Inception #GOAT14 49
- 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
- 61. Thank you Agile Project Inception #GOAT14 61
Notas del editor
- 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.
- Caroline
- Caroline
- Bill
- Bill