Agile Project Management SD Best Practices Before We Start

Transcription

1 Presentation Copyright , 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 2 1

2 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, Project Manager, VP Started with agile in Blog at 4 2

3 Discussion: Who are you? Please introduce yourself including: Name Company and Role Agile experience 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: 6 3

4 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 minutes in length, so we will be covering things VERY quickly! 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. 8 4

5 Vision statement template From Crossing the Chasm by Geoffrey Moore 9 Our product backlog (not prioritized!) Iteration Title 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 Votes 10 5

6 Release planning meeting Go from to Everyone that will work on the project should attend in order to have their input heard 1 st part of meeting 2 nd 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 11 Discussion: Release planning What should our release backlog look like for this workshop? 12 6

7 Purpose is to get ready to start coding iterations Gather people resources Get organized Iteration 0 Identify early risks 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 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 14 7

8 Iteration planning meeting Team, Product Champion and Scrum Master Purpose is for team to make commitment for what will be done during the iteration 1 st part: Ask questions and size stories. Make initial guess at commitment 2 nd part: Break down stories Team does this without Product Champion 3 rd part: explain commitment (based on prior velocity) 15 8

9 Discussion: What Do We Know What are some ways to define agile software development? 18 9

10 Dilbert knows agile! Dilbert on agile Or, maybe not 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 20 10

11 Agile is A more purposeful definition building the highest value software with high quality as fast as possible. 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 22 11

12 Agile process diagram 23 Another agile process diagram 24 12

13 Agile Roles 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!!! 26 13

14 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? 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 2 nd extra question

15 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 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 30 15

16 Usual method of assigning tasks US1 US2 Task 1 Task 2 Task 3 Task 1 Task 2 Task 3 Bob Jill Don US3 Bob will do US1 Jill will do US2 Don will do US3 Task 1 Task 2 Task 3 31 Usual method of assigning tasks US1 US2 US3 Bob Task 1 Task 2 Task 3 Jill Task 1 Task 2 Task 3 Don Task 1 Task 2 Task 3 Bob Jill Don Bob will do US1 Jill will do US2 Don will do US

17 Stop here Do we deliver value? US1 Bob Bob Task 1 Task 2 Task 3 US2 US3 Jill Jill Task 1 Task 2 Task 3 Bob will do US1 Jill will do US2 Don will do US3 Don Don Task 1 Task 2 Task 3 33 Swarming example - start US1 US2 Task 1 Task 2 Task 3 Task 1 Task 2 Task 3 Bob Jill Don US3 Task 1 Task 2 Task

18 Swarming example 1st tasks US1 US2 Task 1 Task 2 Task 3 Task 1 Task 2 Task 3 Bob Jill Don US3 Task 1 Task 2 Task 3 35 Swarming example 2nd tasks US1 US2 Bob Task 1 Task 2 Task 3 Jill Don Task 1 Task 2 Task 3 Bob Jill Don US3 Task 1 Task 2 Task

19 Stop here - Do we deliver value?? US1 Bob Don Don Task 1 Task 2 Task 3 US2 Jill Bob Jill Task 1 Task 2 Task 3 US3 Task 1 Task 2 Task 3 37 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return 38 19

20 Discussion: Why agile? If someone asks you Why agile? how do you respond? 40 20

21 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 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? 42 21

22 Creating better products Question: What percentage of software features are NEVER used? Often 13% Always 7% Sometimes 16% Never Used 45% Rarely 19% 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? Often 13% Always 7% Sometimes 16% Never or Rarely Used 64% 44 22

23 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??? 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 46 23

24 Planning improvements Retrospections for correction and improvement Accurate management visibility Better predictability leading to success 47 Discussion: Other Reasons What other reasons exist for using agile? 48 24

25 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return 49 25

26 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! 51 Unwavering guides Always good Foundational Never change What are principles? Principles are underlying truths that don t change over time or space... Tom and Mary Poppendieck, Implementing Lean Software Development From Concept to Cash 52 26

27 Things we do Fit the situation Apply principles Change as needed What are practices? while practices are the application of principles to a particular situation. Tom and Mary Poppendieck, Implementing Lean Software Development From Concept to Cash 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. Practices can and should differ as you move from one environment to the next, and they also change as a situation evolves. This section talks about PRINCIPLES (entire quote from Tom and Mary Poppendieck s book Implementing Lean Software Development: From Concept to Cash ) 54 27

28 Agile Principles in a Nutshell Eliminate waste Build Quality In Deliver Fast Improve the System Defer Commitment Respect People Create Knowledge 55 Why these particular principles? Following these principles avoids many of the errors that plague the software industry today 56 28

29 Boiling it down to a single thought 57 Even better is This is at the heart of continuous improvement the heart of agile. This is the one big thing to remember

30 Agile Practices vs. Principles Building in iterations Daily stand-up Automated testing Nightly build Iteration planning Product Champion (Product Owner) Release planning Retrospectives 59 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return 60 30

31 Dilbert 62 31

32 Discussion: Agile Requirements Are agile requirements different? If so, how are they different? 63 The prioritized backlog(s) Iteration backlog List of STORIES for an iteration Product backlog All possible features in priority order Release backlog List of features for a given release 64 32

33 Making things agile ready Product Champion creates these items EPIC/FEATURE (EPIC:Reporting System) Minimally Releasable Feature (MRF:Canned Reports) Minimally Releasable Feature (MRF:Template Reports) Minimally Releasable Feature (MRF:Direct Queries) User Story User Story User Story User Story Tasks Tasks Tasks User Story Team creates these Product Champion and dev team create these items Notice the elimination of waste (agile principle) by not spending time on pieces that aren t needed for the release/iteration. 65 User Story Template 66 33

34 Another way to look at it 67 Some rules for the backlog 68 34

35 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. 69 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return 70 35

36 Discussion: Testing How do we do testing today? How is that working for us? 72 36

37 Support Programming Critique Product 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 73 Defining the types of testing Automated (QA) Business Facing Manual (Anyone) Acceptance Tests Business Intent (Design of the Product) Unit Tests Developer Intent (Design of the Code) Usability Testing Exploratory Testing Property Testing Response, Security Scaling, Automated (Developer) Technology Facing Tool-Based (Expensive) from Brian Marick 74 37

38 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 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

39 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 77 Remember 78 39

40 Open source tools for automated testing FIT: Framework for Integration Tests (html) FitNesse (wiki) fit.c2.com/ 79 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return 80 40

41 Measure appropriately Remember, be careful what you measure!!! DILBERT: Scott Adams/Dist. by United Feature Syndicate, Inc

42 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) 83 Iteration status board Committed In Process Completed User Story Task Task Task User Story Task Task Task Task User Story Task Task 84 42

43 Burn-down chart 70 Burn-down Chart S t o r y P o i n t s Remaining Day 85 Burn-up chart 70 Burn-up Chart S t o r y P o i n t s Committed Completed Day NOTE: This shows a very bad practice. A team should NEVER drop scope from an iteration! 86 43

44 Additional artifacts prior to release Burn-up/burn-down charts at the release level Impediment list (and results) Retrospective action items, owners and results 87 Performance Related Metrics We often need to measure the performance of people 88 44

45 Measure UP Span of control (dev): Coded story points Span of control (QA): Number of tests run Span of influence must have teamwork and rely on others to succeed Span of control (dev) items directly controlled Span of control (QA) items directly controlled Span of influence: Features in the field with no reported bugs in 90 days 89 Discussion: Metrics What other metrics could you use that make sense in an agile environment? 90 45

46 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return 91 46

47 Product Champion (Product Owner) Owner of the backlog (prioritizes and makes decisions) Represents users and stakeholders when talking to team Represents team when talking to users and stakeholders Agile (Scrum) roles Agile Project Manager (Scrum Master) Facilitates of meetings Removes impediments Runs interference for the team (firewall for team) Users/Stakeholders Those that are going to use the product or have a vested interest in how it turns out Team The team that will create the product Includes EVERYONE that is part of product creation 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 94 47

48 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. 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 96 48

49 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 97 Communication is perhaps the most important aspect of software development Used for Planning Why We Communicate Laying out scope Getting feedback Explaining paths taken 98 49

50 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! 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

51 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! 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

52 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return

53 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 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

54 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 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!

55 After iteration 3 After the 3 rd 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 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

56 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 111 What others are seeing

57 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% 113 Agile is a Proven Approach Some Agile Companies (there are MANY more)

58 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return

59 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 Backlog Release Backlog Iteration Backlog 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

60 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 119 Starting Feature List (non-agile) To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature

61 At Project Completion To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature At Project Completion To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature

62 What Was Actually Desired To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature What Was Actually Desired To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Feature

63 Why Reprioritization is Important (start list - agile) To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature st Iteration To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature

64 Reprioritize After Iteration To be implemented Completed Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature nd Iteration To be implemented Completed Feature 1 Feature 4 Feature 2 Feature 3 Feature 5 Feature

65 Reprioritize After Iteration To be implemented Completed Feature 1 Feature 4 Feature 2 Feature 3 Feature 5 Feature rd Iteration To be implemented Completed Feature 1 Feature 4 Feature 6 Feature 7 Feature 2 Feature 3 Feature

66 3rd Iteration To be implemented Completed Feature 1 Feature 4 Feature 6 Feature 7 Feature 2 Feature 3 Feature Discussion: Prioritizing How can we properly prioritize our backlog?

67 The bottom line on prioritization 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)

68 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??? 135 Sometimes simple works well Business Value Calculation Story Customer Internal Biz risk Tech risk Biz Adv Biz Value Reporting system Admin section Startup wizard Server O/S upgrade (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

69 An important point 137 Discussion: Planning When are we done? Feature driven, date driven, or something else?

70 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return

71 Discussion: Being a PM What do traditional project managers do? 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

72 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 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

73 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 145 Demonstration Making spaghetti can teach us a lot about why directing is harder than letting the team solve problems on their own

74 Discussion: Retrospective What did we learn? Any changes to the rest of the release plan? Return

75 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! 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?

76 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?

77 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 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!

78 Discussion: 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? Our Retrospective

79 79