Agile Simulation

4,754 views

Published on

Published in: Technology, Business

Agile Simulation

  1. 1. Agile Project Management – SD Best Practices 2008 Presentation Copyright © 2008-2009, Agile For All, LLC. All rights reserved. Use by IACA permitted. Before We Start • Cell phones, pagers, PDA’s, etc. to silent • If you have a question, please ask it. Don’t wait! It is better to answer the question while we are still in the same area than to go back. • We will take a break after about 90 minutes Agile for Project Managers 2 1
  2. 2. Agile Project Management – SD Best Practices 2008 Bob Hartman (Agile Bob) • 30+ years of software industry experience • Scrum Alliance Certified Scrum Coach (CSC) • Bachelor and Masters degrees in Computer Science • Roles included Tester, Developer, Dev Manager, QA Manager, Product Manager, bob.hartman@agileforall.com 303-766-0917 Project Manager, VP… Blog at www.agilebob.com • Started with agile in 1999 Agile for Project Managers 4 2
  3. 3. Agile Project Management – SD Best Practices 2008 Discussion: Who are you? • Please introduce yourself including: – Name – Company and Role – Agile experience Agile for Project Managers 5 Discussion: Our Goal • This workshop is to learn about agile, while participating in an agile project • In other words, this workshop IS an agile project! • What should the goal be? • How about: Agile for Project Managers 6 3
  4. 4. Agile Project Management – SD Best Practices 2008 How the Workshop Will Function • This is going to be just like an agile project • All of you represent certain roles – Customer/Stakeholder – Team Members • I represent certain roles – Product Champion – Team Member – Agile Project Manager • We will go through an entire release, including planning, iterations, retrospectives, etc. • Our iterations will each be 20-30 minutes in length, so we will be covering things VERY quickly! Agile for Project Managers 7 Starting the Project • In an agile project you need two things to get started on a project: – Vision Statement – Prioritized Product Backlog • Our vision statement will be: FOR the attendees of this workshop WHO want to learn more about agile software development THE workshop IS AN agile project THAT will help them understand agile with real examples. UNLIKE other workshops about agile OUR WORKSHOP will teach agile by being agile. Agile for Project Managers 8 4
  5. 5. Agile Project Management – SD Best Practices 2008 Vision statement template From “Crossing the Chasm” by Geoffrey Moore Agile for Project Managers 9 Our product backlog (not prioritized!) Iteration Title Votes Expectations of Agile Why Consider Agile? Agile Metrics Agile Process Basics Agile Principles Agile People and Roles Agile PM vs. Traditional PM Agile Planning Agile Requirements Agile Testing Release Agile for Project Managers 10 5
  6. 6. Agile Project Management – SD Best Practices 2008 Release planning meeting • Go from to • Everyone that will work on the project should attend in order to have their input heard • 1st part of meeting • 2nd part of meeting ask questions • Last part of meeting for initial planning – Non-core team members should use this time to make sure their needs are addressed Agile for Project Managers 11 Discussion: Release planning • What should our release backlog look like for this workshop? Agile for Project Managers 12 6
  7. 7. Agile Project Management – SD Best Practices 2008 Iteration 0 • Purpose is to get ready to start coding iterations • Gather people resources • Get organized • Identify early risks Agile for Project Managers 13 Workshop Iteration 0 • Some definitions: – Release – Final output of the development process – Iteration – Small piece of the development time. Fixed length, usually 2 weeks, but can range from 1-4 weeks – Backlog – list of work items for the product, release or iteration • Our risk today is that we may run out of time – We will limit each section to no more than 25-30 minutes – That should give us time for 4-6 iterations during the workshop – We will re-evaluate after each iteration to make sure we get “the right 10 pounds of stuff in our 10 pound bag” Agile for Project Managers 14 7
  8. 8. Agile Project Management – SD Best Practices 2008 Iteration planning meeting • Team, Product Champion and Scrum Master – Purpose is for team to make commitment for what will be done during the iteration • 1st part: Ask questions and size stories. Make initial guess at commitment • 2nd part: Break down stories Team does this without Product Champion • 3rd part: explain commitment (based on prior velocity) Agile for Project Managers 15 8
  9. 9. Agile Project Management – SD Best Practices 2008 Discussion: What Do We Know • What are some ways to define agile software development? Agile for Project Managers 18 9
  10. 10. Agile Project Management – SD Best Practices 2008 Dilbert on agile Dilbert knows agile!  Or, maybe not  Agile for Project Managers 19 What others commonly say Agile is… Building software in iterations typically 1-4 weeks most teams use 2 weeks Teams work from a prioritized backlog prioritized by Product Owner consists of “user stories” of 1-3 days duration Teams are self-organizing and self-directing agile project manager (Scrum Master) facilitates meetings and removes impediments teams make commitments and work as a team Every day starts with a daily stand-up 3 questions answered by everyone no one else allowed to participate Agile for Project Managers 20 10
  11. 11. Agile Project Management – SD Best Practices 2008 A more purposeful definition Agile is… building the highest value software… with high quality… as fast as possible. Agile for Project Managers 21 Typical agile project flow 1. Project is approved (generally outside agile) 2. Release planning meeting 3. Iteration 0 4. Iteration planning meeting 5. Execute iteration (daily stand-up meetings) 6. Iteration demo and retrospective 7. If release not complete go to step 4 8. Release 9. Release retrospective 10.Repeat Agile for Project Managers 22 11
  12. 12. Agile Project Management – SD Best Practices 2008 Agile process diagram Agile for Project Managers 23 Another agile process diagram Agile for Project Managers 24 12
  13. 13. Agile Project Management – SD Best Practices 2008 Agile Roles Agile for Project Managers 25 Iteration – the basic unit of agile Iterations create a “product increment” of “potentially shippable software.” This means everything is working. It DOES NOT mean we can get it wrong in an iteration and then fix it all up in the next iteration!!! Agile for Project Managers 26 13
  14. 14. Agile Project Management – SD Best Practices 2008 Daily stand-up – Part I • Team and Scrum Master attend – Others can attend but it is not necessary – This is team time, others should not participate unless it is by agreement with the team • 3 questions are answered by each person – What did I do since we last met? – What will I do before we meet again? – What is blocking me? Agile for Project Managers 27 Daily stand-up – Part II • Best is to add 3 more questions at the end of the meeting – Do anyone have any tasks that need to be added? – Does anyone have anything we all need to know? – Do any follow-up meetings need to be scheduled? • NOTE: this part of the meeting is NOT a strict Scrum/Agile practice. It just seems to make things work better! People not on the team can participate here, especially during the 2nd extra question. Agile for Project Managers 28 14
  15. 15. Agile Project Management – SD Best Practices 2008 Things to remember • Everyone on the team participates in part I • No one outside the team participates in part I • In part II only items that are necessary for the entire team to know are addressed • THIS IS NOT A STATUS MEETING!!! This is a time for the team to interact – Hold each other accountable for results – Work better together by helping each other – Together make sure they are on track to meet the iteration commitment Agile for Project Managers 29 Assigning tasks – DON’T! • Everyone always follows the same rule for what to do next: – Go to the highest priority story and if you can do one of the tasks, do that – If you can’t do any of those tasks, find the highest priority story where you can do a task and do that • Things are always being worked from the top of the list down, so highest value will be delivered as fast as possible • These two things done together create “swarming” on stories Agile for Project Managers 30 15
  16. 16. Agile Project Management – SD Best Practices 2008 Usual method of assigning tasks US1 Task 1 Task 2 Task 3 Bob Jill US2 Don Task 1 Task 2 Task 3 Bob will do US1 Jill will do US2 US3 Don will do US3 Task 1 Task 2 Task 3 Agile for Project Managers 31 Usual method of assigning tasks US1 Bob Task 1 Task 2 Task 3 Bob Jill US2 Don Jill Task 1 Task 2 Task 3 Bob will do US1 Jill will do US2 US3 Don will do US3 Don Task 1 Task 2 Task 3 Agile for Project Managers 32 16
  17. 17. Agile Project Management – SD Best Practices 2008 Stop here – Do we deliver value? US1 Bob Task 1 Bob Task 2 Task 3 US2 Jill Task 1 Jill Task 2 Task 3 Bob will do US1 Jill will do US2 US3 Don will do US3 Don Don Task 1 Task 2 Task 3 Agile for Project Managers 33 Swarming example - start US1 Task 1 Task 2 Task 3 Bob Jill US2 Don Task 1 Task 2 Task 3 US3 Task 1 Task 2 Task 3 Agile for Project Managers 34 17
  18. 18. Agile Project Management – SD Best Practices 2008 Swarming example – 1st tasks US1 Task 1 Task 2 Task 3 Bob Jill US2 Don Task 1 Task 2 Task 3 US3 Task 1 Task 2 Task 3 Agile for Project Managers 35 Swarming example – 2nd tasks US1 Bob Task 1 Don Task 2 Task 3 Bob Jill US2 Don Jill Task 1 Task 2 Task 3 US3 Task 1 Task 2 Task 3 Agile for Project Managers 36 18
  19. 19. Agile Project Management – SD Best Practices 2008 Stop here - Do we deliver value?? US1 Bob Task 1 Don Don Task 2 Task 3 US2 Jill Task 1 Bob Task 2 Jill Task 3 US3 Task 1 Task 2 Task 3 Agile for Project Managers 37 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 38 19
  20. 20. Agile Project Management – SD Best Practices 2008 Discussion: Why agile? • If someone asks you “Why agile?” how do you respond? Agile for Project Managers 40 20
  21. 21. Agile Project Management – SD Best Practices 2008 Building a business case for agility • Business case essentials: – Bottom line dollars and cents – Improvements • For this business case we should include: – Business value created quickly – Creating better products – Team dynamics – Planning improvements Agile for Project Managers 41 Adding Business Value Quickly – A Simple Example • Stuffing envelopes can tell us a lot about agile  • What are the advantages of getting something released more quickly? Agile for Project Managers 42 21
  22. 22. Agile Project Management – SD Best Practices 2008 Creating better products Question: What percentage of software features are NEVER used? Always 7% Often 13% Never Used 45% Sometimes 16% Rarely 19% Agile for Project Managers 43 Delivering business value quickly Question: If we get rid of the 64% of software that is rarely or never used, what happens to our overall software development efforts? Always 7% Often 13% Sometimes Never or 16% Rarely Used 64% Agile for Project Managers 44 22
  23. 23. Agile Project Management – SD Best Practices 2008 Discussion: Expectations • When does the customer know what they really want in a product? • How can we help them know earlier? • Does that sound agile to anyone??? Agile for Project Managers 45 Changes to team dynamics • Morale improves – Team succeeds more often – Teams work together – Teams empowered to succeed • Failures are very limited – A single iteration – Correction happens immediately – Team fails together so no blame – Happens quickly rather than bleeding to death from a papercut Agile for Project Managers 46 23
  24. 24. Agile Project Management – SD Best Practices 2008 Planning improvements • Retrospections for correction and improvement • Accurate management visibility • Better predictability leading to success Agile for Project Managers 47 Discussion: Other Reasons • What other reasons exist for using agile? Agile for Project Managers 48 24
  25. 25. Agile Project Management – SD Best Practices 2008 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 49 25
  26. 26. Agile Project Management – SD Best Practices 2008 Agile Principles • Based on lean manufacturing principles • Often called Lean Software Development principles • Form the backbone of all agile practices • Ignore at your own risk! Agile for Project Managers 51 What are principles? • Unwavering guides • Always good • Foundational • Never change “Principles are underlying truths that don’t change over time or space...” Tom and Mary Poppendieck, “Implementing Lean Software Development – From Concept to Cash” Agile for Project Managers 52 26
  27. 27. Agile Project Management – SD Best Practices 2008 What are practices? • Things we do • Fit the situation • Apply principles • Change as needed “… while practices are the application of principles to a particular situation.” Tom and Mary Poppendieck, “Implementing Lean Software Development – From Concept to Cash” Agile for Project Managers 53 This sums it up best “Principles are underlying truths that don’t change over time or space, while practices are the application of principles to a particular situation. This section talks Practices can and should differ as you move from one about PRINCIPLES environment to the next, and they also change as a situation evolves.” (entire quote from Tom and Mary Poppendieck’s book “Implementing Lean Software Development: From Concept to Cash”) Agile for Project Managers 54 27
  28. 28. Agile Project Management – SD Best Practices 2008 Agile Principles in a Nutshell • Eliminate waste • Build Quality In • Deliver Fast • Improve the System • Defer Commitment • Respect People • Create Knowledge Agile for Project Managers 55 Why these particular principles? • Following these principles avoids many of the errors that plague the software industry today Agile for Project Managers 56 28
  29. 29. Agile Project Management – SD Best Practices 2008 Boiling it down to a single thought Agile for Project Managers 57 Even better is… This is at the heart of continuous improvement – the heart of agile. This is the “one big thing” to remember. Agile for Project Managers 58 29
  30. 30. Agile Project Management – SD Best Practices 2008 Agile Practices vs. Principles • Building in iterations • Daily stand-up • Automated testing • Nightly build • Iteration planning • Product Champion (Product Owner) • Release planning • Retrospectives Agile for Project Managers 59 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 60 30
  31. 31. Agile Project Management – SD Best Practices 2008 Dilbert Agile for Project Managers 62 31
  32. 32. Agile Project Management – SD Best Practices 2008 Discussion: Agile Requirements • Are agile requirements different? If so, how are they different? Agile for Project Managers 63 The prioritized backlog(s) Iteration backlog List of STORIES for an iteration Product backlog Release backlog All possible features List of features for in priority order a given release Agile for Project Managers 64 32
  33. 33. Agile Project Management – SD Best Practices 2008 Making things “agile ready” Product Champion EPIC/FEATURE creates these items (EPIC:Reporting System) Minimally Minimally Releasable Minimally Releasable Feature Feature Releasable Feature (MRF:Canned Reports) (MRF:Template Reports) (MRF:Direct Queries) User User User User User Product Champion and Story Story Story Story Story dev team create these items Notice the elimination of Team waste (agile principle) by Tasks Tasks Tasks creates not spending time on these pieces that aren’t needed for the release/iteration. Agile for Project Managers 65 User Story Template Agile for Project Managers 66 33
  34. 34. Agile Project Management – SD Best Practices 2008 Another way to look at it Agile for Project Managers 67 Some rules for the backlog Agile for Project Managers 68 34
  35. 35. Agile Project Management – SD Best Practices 2008 Guidelines 15% of backlog is iteration ready as user stories 25% of backlog is in the form of minimally releasable features The rest of the backlog is still in the form of epics or high level features DO NOT BE OVERLY PRECISE ABOUT THIS!!! These are just guidelines. Do whatever works best for the team. Agile for Project Managers 69 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 70 35
  36. 36. Agile Project Management – SD Best Practices 2008 Discussion: Testing • How do we do testing today? • How is that working for us? Agile for Project Managers 72 36
  37. 37. Agile Project Management – SD Best Practices 2008 What does “done” mean? • Gold standard for agile is that each iteration creates potentially shippable code, which means – All unit tests pass – All acceptance tests pass • To meet this standard means that testing needs to be done DURING the iteration, not after – Tests must be written before or concurrently with developing the software Agile for Project Managers 73 Defining the types of testing Automated Manual (QA) Business Facing (Anyone) Acceptance Usability Support Programming Tests Testing Critique Product Business Intent Exploratory (Design of the Product) Testing Unit Property Tests Testing Response, Developer Intent Security (Design of the Code) Scaling,… Automated Tool-Based (Developer) Technology Facing (Expensive) from Brian Marick Agile for Project Managers 74 37
  38. 38. Agile Project Management – SD Best Practices 2008 Timeline for Acceptance Tests • Product Champion refines stories and acceptance tests from Release Planning meeting, a few days before the Iteration Planning meeting • Developers/Testers add more detailed tests in the Iteration Planning meeting • Developers/Testers continue to build out in the Iteration – failing tests until code is implemented • Developers get tests to pass • Becomes part of the Regression test suite when story is accepted Agile for Project Managers 75 Build quality in (agile principle) in action Cost to fix defects based on when they are found C o s t Time Finding and fixing defects as soon as they are created is much cheaper than finding and fixing them further along in the process. Agile for Project Managers 76 38
  39. 39. Agile Project Management – SD Best Practices 2008 Validation and testing • We have to validate – That we understand what is needed – That we did what we wanted – That the product is of sufficient quality • We must push testing up early – Tests improve the conversation between customers and developers – Tests become executable specifications Agile for Project Managers 77 Remember… Agile for Project Managers 78 39
  40. 40. Agile Project Management – SD Best Practices 2008 Open source tools for automated testing • FIT: Framework for Integration Tests (html) fit.c2.com/ • FitNesse (wiki) www.fitnesse.org/ Agile for Project Managers 79 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 80 40
  41. 41. Agile Project Management – SD Best Practices 2008 Measure appropriately Remember, be careful what you measure!!! DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc. Agile for Project Managers 82 41
  42. 42. Agile Project Management – SD Best Practices 2008 Metrics During Iterations • Need to know only a few things: – What items have been completed and what items are not completed – How are we doing in relation to our plan for the iteration • Do not want to track metrics that will create waste – Processing raw data into status reports – Generating reports that aren’t useful • Remember, you get what you measure (Dilbert comic) Agile for Project Managers 83 Iteration status board Committed In Process Completed User Story Task Task Task Task User Story Task Task Task User Story Task Task Agile for Project Managers 84 42
  43. 43. Agile Project Management – SD Best Practices 2008 Burn-down chart Burn-down Chart 70 S 60 t o 50 r y 40 P 30 o Remaining i 20 n t 10 s 0 1 2 3 4 5 6 7 8 9 10 Day Agile for Project Managers 85 Burn-up chart Burn-up Chart 70 S 60 t o 50 r y 40 P Committed 30 o Completed i 20 n t 10 s 0 1 2 3 4 5 6 7 8 9 10 Day NOTE: This shows a very bad practice. A team should NEVER drop scope from an iteration! Agile for Project Managers 86 43
  44. 44. Agile Project Management – SD Best Practices 2008 Additional artifacts prior to release • Burn-up/burn-down charts at the release level • Impediment list (and results) • Retrospective action items, owners and results Agile for Project Managers 87 Performance Related Metrics • We often need to measure the performance of people Agile for Project Managers 88 44
  45. 45. Agile Project Management – SD Best Practices 2008 Measure UP Span of influence – Span of control (dev): Coded story points must have teamwork Span of control (QA): Number of tests run and rely on others to succeed Span of Span of control (dev) control (QA) – items – items directly directly controlled controlled Span of influence: Features in the field with no reported bugs in 90 days Agile for Project Managers 89 Discussion: Metrics • What other metrics could you use that make sense in an agile environment? Agile for Project Managers 90 45
  46. 46. Agile Project Management – SD Best Practices 2008 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 91 46
  47. 47. Agile Project Management – SD Best Practices 2008 Agile (Scrum) roles Product Champion Agile Project Manager (Product Owner) (Scrum Master) •Owner of the backlog •Facilitates of meetings (prioritizes and makes •Removes impediments decisions) •Runs interference for •Represents users and the team (firewall for stakeholders when talking team) to team •Represents team when talking to users and stakeholders Users/Stakeholders Team •Those that are going to •The team that will create use the product or have the product a vested interest in how •Includes EVERYONE it turns out that is part of product creation Agile for Project Managers 93 Self-Organizing Team • Scrum Teams are filled with people who have skills, not people playing roles • The individuals on a team self-organize for the task at hand • The basic unit is the “Teamlet” or “Work Cell” – The Teamlet has all the skills it needs (analysis, development, design, test, documentation, …) – It typically consists of 2-4 people to get all the skills “covered” – It swarms on one thing at a time Agile for Project Managers 94 47
  48. 48. Agile Project Management – SD Best Practices 2008 “Good” Team Philosophies, Found in Agile • One Bite at a Time – Do things a little at a time, with planning, validation, and management of the pieces. • Validation Centricity – The activities of validation, verification and test are “more important” than those of analysis, design, and construction; and that we must actively look for things that cause us to change. • Avoid and Eliminate Waste – Work on those things with the most value; have retrospectives to evaluate process, etc • Risk Awareness – Base decisions on risk analysis and mitigation – requirements risk, architectural risk, technical risk, quality risk, people risk, etc • Let Business Value Lead – Decisions must be based on the product, not documented plans, analyses, requirements, or designs. The process doesn’t lead. Agile for Project Managers 95 Personal Qualities We Want • There are also personal qualities we like to see in the members of our team. We call them the “team values” – Play To Win – Communication – Cooperation – Trust Agile for Project Managers 96 48
  49. 49. Agile Project Management – SD Best Practices 2008 Play to Win • Many people play "not to lose" • Playing to win beats playing "not to lose" almost every time • Symptoms of playing "not to lose" – Lots of paper – Lots of meetings – "by the book" development – It's CYA time… • Playing "not to lose" usually creates waste Agile for Project Managers 97 Why We Communicate • Communication is perhaps the most important aspect of software development • Used for – Planning – Laying out scope – Getting feedback – Explaining paths taken Agile for Project Managers 98 49
  50. 50. Agile Project Management – SD Best Practices 2008 Cooperate and Trust • We are a team – a group of individuals that work together to be better than any of its parts • Communication between members of the team is absolutely essential • But even more important are – Cooperation – the willingness to subvert ones own interests to those of the team, and work together to achieve them – Trust – knowing that other members of your team are doing the best they can to do what is good for the team • No individual blame – the process allowed it, so improve the process! Agile for Project Managers 99 Agile Project Manager (Scrum Master) • Removes barriers to help team become more efficient and productive • Facilitates close cooperation and creativity across all roles and functions • Helps team remain focused on doing the most important things • Can play role of process coach or help the team evolve their process • Keeps Daily Scrum/Standup on task and on track • Helps resolve the impediment issues list, provides status Agile for Project Managers 100 50
  51. 51. Agile Project Management – SD Best Practices 2008 Product Champion Represents (is a champion for) anyone that is not present during interactions that occur throughout the process Needs to… Empathize with customers Understand the technology Know when to listen! Agile for Project Managers 101 Remember, values are key • Agile development is not obvious: – It relies on its people – It takes extraordinary discipline • Your individuals must have personal values that support agility – Developers – Managers – Customers • These values are crucial – Without them you have no chance with any process – With them you can make almost any process work Agile for Project Managers 102 51
  52. 52. Agile Project Management – SD Best Practices 2008 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 103 52
  53. 53. Agile Project Management – SD Best Practices 2008 Common myths about agile • You will release more software faster – You will release the highest value software as quickly as possible – More code will NOT be written in less time, but when you are continuously releasing high value software it APPEARS that you are going faster • Agile doesn’t need any documentation – The phrase to keep in mind is “just enough, just in time” and this applies to most agile myths • The developers run the show in agile – The developers follow the rule of finding the highest priority task to work on and doing that – The Product Champion role defines the priorities, not the development team Agile for Project Managers 105 Immediate expectations • The team will have a lot of questions – Questions should generally be funneled through a small number of people – This is where it is very useful to have a coach! • The worst thing to do is to try and make up an answer on the fly • Even if you are “somewhat sure”, use your coach • The team will want to know how/when they will be getting started with what they learned – This needs to be communicated clearly – There will be some questions about how other groups are going to be integrated – again, communicate clearly Agile for Project Managers 106 53
  54. 54. Agile Project Management – SD Best Practices 2008 Iteration 1 • Planning will be completely different – People will be uncomfortable with new methods – Stick with it, this stuff really does work! • There will be some confusion – This is entirely normal! – Work through it and improve your understanding of the process – Again, get your coach involved if there are significant issues • Don’t trust the results of this first iteration! – It is the first time people are doing this and it will almost certainly be wrong Agile for Project Managers 107 Iterations 1-3 • The bad news: results may not be what you expect – Iteration 1 • Team will likely only achieve 65% of what they believe they will achieve • Plan on this and only allow the team to commit to about 65% of what they think they will be able to complete – Iteration 2 • Percentage of achievement is likely to be 80% of what the team believes they can complete – Iteration 3 • Percentage increases to approximately 90% – All of these iterations • Warts in the current system and assumptions will be exposed • There is no place to hide the elephant in the room! • The good news: things will continue to improve! Agile for Project Managers 108 54
  55. 55. Agile Project Management – SD Best Practices 2008 After iteration 3 • After the 3rd iteration the team should be able to have an accurate assessment of how much work they can do in each iteration • It is important to use “yesterday’s weather” when deciding how much work can be done in an iteration • Teams will generate the same amount of software as they did previously, but… – The software they are creating will be more in line with expectations... assuming they are following what they learned – The software should be of higher quality if developers and testers work together in an agile way Agile for Project Managers 109 Long-term • It is common for the process to degrade over time – We don’t really need to do that part… – It takes too long to do that… – Why do we want to keep doing that… • DO NOT LET THIS HAPPEN! – The process should be improved, but that does not mean removing essential pieces – that is NOT improvement – If there is a temptation to remove pieces of the process, examine the agile principles and determine how else to solve the same problem Agile for Project Managers 110 55
  56. 56. Agile Project Management – SD Best Practices 2008 Potential results • What teams generally experience – Anywhere from 25-50% improvement in productivity • Some teams see as much as 300% improvement! • But be careful how this is measured – Often teams are producing the same amount of software in terms of lines of code generated – The features they are adding are the right features at the right time, which means… overall to get a release they generally need to create fewer features – Higher morale • They are succeeding and responding to change • What organizations generally experience – Software is created more quickly because… fewer features need to be created to satisfy the customer Agile for Project Managers 111 What others are seeing Agile for Project Managers 112 56
  57. 57. Agile Project Management – SD Best Practices 2008 VersionOne Survey Results (2008) Survey asked people: Please try to estimate SPECIFIC IMPROVEMENTS you have actually realized from implementing Agile practices. Improvement Noted >10% improvement >=25% improvement Increased productivity 89% 56% Reduced software defects 84% 56% Accelerated time-to-market 83% 54% Reduced cost 65% 30% Source: VersionOne 2008 State of Agile Development Survey NOTE: All 2008 data is within 2% of 2007 data implying these numbers are not one-time anomalies Biggest causes of company-wide agile failure: Company philosophy or culture could not be overcome – 23% Lack of experience with agile – 21% Agile for Project Managers 113 Agile is a Proven Approach Some Agile Companies (there are MANY more) Agile for Project Managers 114 57
  58. 58. Agile Project Management – SD Best Practices 2008 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 115 58
  59. 59. Agile Project Management – SD Best Practices 2008 Multi-Level Planning in Agile • In preparing for battle I have always found that plans are useless, but planning is indispensable,” – Dwight D. Eisenhower Release Planning Iteration Planning Product Release Iteration Backlog Backlog Backlog Agile for Project Managers 117 The Prioritized Backlogs • Exist at 3 levels: – Product backlog – everything that might go into the product – Release backlog – everything that is currently committed for a release of the product – Iteration backlog – everything that is committed for the current release • The Product Champion OWNS the backlogs!!! • Each backlog is kept in priority order at all times based upon the best information currently available Agile for Project Managers 118 59
  60. 60. Agile Project Management – SD Best Practices 2008 Why Prioritization is Important • Agile is all about adapting to change, and without constant reprioritization it is impossible to adapt • Does it make sense to develop iteratively, learn something, then not reprioritize based on what was learned? • Let’s look at a simple example of this in practice… Agile for Project Managers 119 Starting Feature List (non-agile) To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 120 60
  61. 61. Agile Project Management – SD Best Practices 2008 At Project Completion To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 121 At Project Completion To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 122 61
  62. 62. Agile Project Management – SD Best Practices 2008 What Was Actually Desired To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 123 What Was Actually Desired To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Feature 7 Agile for Project Managers 124 62
  63. 63. Agile Project Management – SD Best Practices 2008 Why Reprioritization is Important (start list - agile) To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 125 1st Iteration To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 126 63
  64. 64. Agile Project Management – SD Best Practices 2008 Reprioritize After Iteration To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Agile for Project Managers 127 2nd Iteration To be implemented Completed Feature 1 Feature 4 Feature 2 Feature 3 Feature 5 Feature 6 Agile for Project Managers 128 64
  65. 65. Agile Project Management – SD Best Practices 2008 Reprioritize After Iteration To be implemented Completed Feature 1 Feature 4 Feature 2 Feature 3 Feature 5 Feature 6 Agile for Project Managers 129 3rd Iteration To be implemented Completed Feature 1 Feature 4 Feature 6 Feature 7 Feature 2 Feature 3 Feature 5 Agile for Project Managers 130 65
  66. 66. Agile Project Management – SD Best Practices 2008 3rd Iteration To be implemented Completed Feature 1 Feature 4 Feature 6 Feature 7 Feature 2 Feature 3 Feature 5 Agile for Project Managers 131 Discussion: Prioritizing • How can we properly prioritize our backlog? Agile for Project Managers 132 66
  67. 67. Agile Project Management – SD Best Practices 2008 The bottom line on prioritization Agile for Project Managers 133 Components of business value • Customer value (what is it worth to customers) • Internal value (non-functional items) • Business risk (how bad is it if we don’t do it) • Technical risk (if we do it how risky is it) • Business advantage (what can we gain from it) Agile for Project Managers 134 67
  68. 68. Agile Project Management – SD Best Practices 2008 It is still a black art • Other pieces can be added to the basic components of business value • Somehow they have to be correlated in a way that allows ranking by business value • Any ideas??? Agile for Project Managers 135 Sometimes simple works well Business Value Calculation Story Customer Internal Biz risk Tech risk Biz Adv Biz Value Reporting system 60 10 2 1 3 420 Admin section 40 30 3 3 1 490 Startup wizard 90 0 4 1 2 630 Server O/S upgrade 10 90 2 4 1 700 (Customer value + Internal Value) x (Biz Risk + Tech Risk + Biz Adv) BUT… don’t rely just on numbers. Use your brain and make good business decisions based on what you know. Numbers only guide. Agile for Project Managers 136 68
  69. 69. Agile Project Management – SD Best Practices 2008 An important point Agile for Project Managers 137 Discussion: Planning • When are we done? • Feature driven, date driven, or something else? Agile for Project Managers 138 69
  70. 70. Agile Project Management – SD Best Practices 2008 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 139 70
  71. 71. Agile Project Management – SD Best Practices 2008 Discussion: Being a PM • What do traditional project managers do? Agile for Project Managers 141 Traditional project manager • Based on command and control • Heavy on planning – Gantt and Pert chart centric • Directs the work of the team to match the plan • Stereotype is a person that drives the team Agile for Project Managers 142 71
  72. 72. Agile Project Management – SD Best Practices 2008 Agile project manager • Supports the team rather than driving the team • Removes impediments for the team • Represents the team to those outside the team • Lets the team solve their own problems – Coaches the team and helps them improve Agile for Project Managers 143 More specifically… • In Scrum this role is called Scrum Master • This role facilitates all meetings – Release planning – Iteration planning – Daily stand-ups – Retrospectives • Responsible for removing impediments – Responsible for does not imply they have to do the work to remove the impediment! – This is a BIG piece of the role • Very short timeframes in agile • Short delays removing impediments have drastic effects • Supports the team by helping however necessary – Communicates on behalf of the team to allow them to focus – Keeps the team true to the agile process – Makes sure the team keeps grinding away and making progress • Tracks and reports status Agile for Project Managers 144 72
  73. 73. Agile Project Management – SD Best Practices 2008 What others say • Rather than plan, instruct and direct, the agile project manager facilitates, coaches and leads. - scrumalliance.org • One who uses the Scrum framework, by focusing on facilitation, leadership, report building and communication in place of prescribed command as process control. - wiki.answers.com • Unlike traditional project manager roles, the ScrumMaster does not assign individual tasks to the developers or QA but rather the development team self-organizes on each iteration and determines who will do each task. - Hector Correa in CoDe Magazine Agile for Project Managers 145 Demonstration • Making spaghetti can teach us a lot about why directing is harder than letting the team solve problems on their own. Agile for Project Managers 146 73
  74. 74. Agile Project Management – SD Best Practices 2008 Discussion: Retrospective • What did we learn? • Any changes to the rest of the release plan? Return Agile for Project Managers 147 74
  75. 75. Agile Project Management – SD Best Practices 2008 Normal Agile Release • Coding is finished, now time for release related activities which may include… – Final verification testing – Property tests not done during the iterations (due to cost or complexity). Things like security testing, compliance testing, response time testing, scalability testing, etc. – Complete documentation – Complete training – Complete rollout to production servers • Celebrate! Agile for Project Managers 149 Workshop Release: Tie Up Loose Ends • Any quick questions on what we covered? • What did we not cover that we could cover very quickly right now? Agile for Project Managers 150 75
  76. 76. Agile Project Management – SD Best Practices 2008 Retrospectives • Anyone can attend – Team members are REQUIRED! • Start with 5 easy questions 1. What did we do well? 2. What did we do less well? 3. How did we improve? 4. What actions can we take to address things we did less well (and who will own them)? 5. What can we do to improve next iteration (and who will own these items? Agile for Project Managers 152 76
  77. 77. Agile Project Management – SD Best Practices 2008 Remember • Create a document or wiki page with the results of every retrospective – Create knowledge (agile principle) to help others • “How did we improve?” question should at least address action items from previous iteration • Hold people accountable for items they own, BUT DON’T BLAME PEOPLE! – The process allowed it to happen – Change the process so it doesn’t happen again • This is a primary way for the team to improve so use it as effectively as possible Agile for Project Managers 153 Going further • Address a recurring problem – If the same problem keeps coming up, use the 5 why’s to get to the root cause • Ask additional questions – What would we change if we were in charge? • Interestingly, the team is more in charge than they believe and many of these items can be implemented – What types of feedback have been most useful? – What one question would we like users to answer? – What risks do we need to identify right now? • Think outside the box – don’t limit the team! Agile for Project Managers 154 77
  78. 78. Agile Project Management – SD Best Practices 2008 Discussion: Our Retrospective • How did this format work? – What went well, what didn’t go so well? • Did we get “the right 10 pounds of stuff in our 10 pound bag?” • What should I change for next time? Agile for Project Managers 155 78
  79. 79. Agile Project Management – SD Best Practices 2008 79

×