Agile and the Service Desk ripplerock

Transcription

1 Agile and the Service Desk 1

2 Agile Accelerates Value Delivery 2

3 Agile By the Numbers PMP: 500,000 CSM: 200,000 CSPO: 20,000 SCRUM.ORG 15,000 PMI-ACP 4,000 SAFE: < 1,000 3

4 Waterfall Predictable, few changes Light Risk Low Ceremony Light documentation Light process Agile Processes Scrum Kanban XP Lean Iterative Risk Driven Continuous Integration and Testing High Ceremony Well documented Traceability

5 30 roles 20 activities 70 artifacts Scrum + Engineering Practices

6 Agile Manifesto The 4 Values Individuals & Interactions Working Software Customer Collaboration Responding to Change over over over over Processes & Tools Comprehensive Documentation Contract Negotiation Following a Plan That is, while there is value in the items on the right, we value the items on the left more.

7 Agile Frameworks: Scrum Timeboxes Artifacts Roles Sprint (Heart of Scrum) How often can we deliver? Sprint Planning What are we doing next? Daily Scrum How are we doing? Sprint Review How did we do? Sprint Retrospective How do we get better? Product Backlog What are we doing? Sprint Backlog What are we doing right now? How are we going to do it? Burndown Chart How are we doing? Product Owner Who decides what we do? Team Members Who will do it? ScrumMaster Who will help us do it?

8 PMI Official Reading Reference Agile Retrospectives: Making Good Teams Great. Derby, Larsen, Schwaber. Agile Software Development: The Cooperative Game 2nd Edition. Cockburn. The Software Project Manager s Bridge to Agility. Sliger, Broderick. Coaching Agile Teams. Adkins. Agile Project Management: Creating Innovative Products 2nd Edition. Highsmith. Becoming Agile:...in an imperfect world. Smith, Sidky. Agile Estimating and Planning. Cohn. The Art of Agile Development. Shore. User Stories Applied: For Agile Software Development. Cohn. Agile Project Management with Scrum. Schwaber. Lean- Agile Software Development: Achieving Enterprise Agility. Shalloway, Beaver, Trott. Facilitation, Process Improvement Contracts, Failure Modes, Crystal Method PMP vs. Agile, Stakeholder Mgmt, Communications Mgmt Soft Skills, Coaching, Mentoring, Active Listening Agile Principles, Participatory Decision Making Adopting Agile Practies Estimation, Velocity XP Progressive Elaboration, Agile Requirements Scrum Lean Portfolio Management, Value Stream Mapping

9 9

10 Snapshot of Lean Thinking Work Station ( Chaku Chaku ) Removing Waste ( Muda ) Inventory Signals ( Kanban ) Mistake Proofing ( Poka Yoke ) Continuous Improvement ( Kaizen ) Just In Time Stop The Line 10

11 The Story Lean Thinking is a management revolution beginning in post- WWII Japan Inspired a wave of process improvement methodologies in 1980s and 1990s TQM Six Sigma ISO 9001 CMMi Although intended to be Lean, these methodologies have been implemented in a very heavy fashion. In response, several software thought leaders met to discuss their own lightweight methodologies, and thus crafted the Agile Manifesto 11

12 Core Agile Values from agilemanifesto.org Individuals & Interactions Working Software Customer Collaboration Responding to Change Value Generators over over over over over Processes & Tools Comprehensive Documentation Contract Negotiation Performing to Plan Management Controls 12

13 Core Agile Principles from agilemanifesto.org 1. Satisfy the customer through early and continuous delivery 2. Welcome changing requirements 3. Deliver frequently, preferring a shorter timescale 4. Business & Technical work together daily 5. Build teams with motivated individuals & trust them 6. Face- to- Face Communication 7. Working software is the primary measure of progress 8. Sustainable pace 9. Technical excellence and good design enhances agility 10. Simplicity, maximizing the amount of work not done 11. Best results emerge from self- organizing teams 12. The team regularly reflects to become more effective 13

14 Agile projects implement iterative and incremental delivery Incremental Divide the project into incremental phases Iterative Each phase is progressively more refined * 14

15 Iterative and incremental delivery achieves business value sooner Value Iterative Delivery Traditional Delivery Time 15

16 Benefits: Productivity Agile projects are 16% more productive at a statistically significant level of confidence. Over 80% practitioners report improved productivity * 16

17 Benefits: Time To Market Agile projects are 37% more productive 97% practitioners report improved time to market. * 17

18 Benefits: Quality Rico Study Minimum quality improvement of 10% Median quality improvement of 63% VersionOne Study: 68% said quality had improved somewhat or significantly 84% reduced defects by 10%. 30% reduced defects by 25% or more Case Study for eplan Services In 9 months, defect rate reduced 70% (defects per KLOC) 18

19 Benefits: Employee Satisfaction Salesforce.com In 15 months, employees having a good time or the best time improved from 40% to 86% 90% would recommend agile University of Calgary Research reveals 2/3 less overtime * 19

20 Benefits: Customer Satisfaction Benefit Enhanced ability to manage changing priorities Improved Significantly Improved 41% 51% Improved project visibility 42% 41% Improved alignment of IT and business goals 39% 27% Reduced project risk 48% 17% * 20

21 Scrum Reference 21

22 Scrum is one of many agile methodologies: Scrum Crystal Clear Dynamic Systems Development Model (DSDM) Atern Evolutionary Project Management (Evo) extreme Programming (XP) Feature Driven Development (FDD) Lean Kanban 22

23 A Simple Definition of Scrum Scrum is based on 3 Key Tenets Deliver Early. Deliver Often Empower Your Teams Inspect and Adapt Scrum contains 14 Techniques: 6 Timeboxes 5 Artifacts 3 Roles 23

24 3 Key Tenets of Scrum: Deliver 1. Deliver Early & Often Nature delivers a new, fully-completed increment of tree each year. This allows people to enjoy the business benefits earlier than waiting the full lifecycle of a tree 24

25 3 Key Tenets of Scrum: Empower 2. Empower Your Teams Innovation does not come from compliance. Those doing knowledge work are best qualified to organize that work. Scrum requires teams to enforce professional boundaries, so they can achieve results. 25

26 3 Key Tenets of Scrum: Adapt 3. Inspect & Adapt High performing teams are those that adjust their work to meet the current reality. Scrum offers both quantitative and qualitative techniques to assess how we can avoid disaster and improve performance. 26

27 6 Timeboxes Sprint Release Planning Sprint Planning Daily Scrum Sprint Review Sprint Retrospective A timebox is a fixed period of time, during which something must be done. How often can we deliver something? What do we do when? How do we do it? How are we doing? How did we do? How do we get better? 27

28 The Scrum timeboxes are nested Planning Project Planning Release Planning Release Planning Sprint Review Retro Planning Sprint Review Retro Day Day Day Daily Scrum Time 28

29 How long are the timeboxes? Maximum Duration For Sprints of 6 Weeks For Sprints of 4 Weeks For Sprints of 2 Weeks For Sprints of 1 Week Release Planning 1.5 Days 1 Day Half- Day 2 Hours Sprint Planning 1.5 Days 1 Day Half- Day 2 Hours Sprint Review 6 Hours Half- Day 2 Hours 1 Hours Sprint Retrospective 6 Hours Half- Day 2 Hours 1 Hours Daily Scrum 15 Minutes 15 Minutes 15 Minutes 15 Minutes These are the maximum durations of each timebox. Meetings may adjourn early, if the agenda is completed before the allotted time expires. 29

30 Sprint Defined Purpose To facilitate frequent delivery through a cycle of regular short- term deadlines, thus answering How often can we deliver something Outputs Working Software consisting of new features, stories, or bug fixes Potentially Shippable Increment of Work Rules Team and Product Owner collaborate on a Sprint duration that is quick enough to meet the PO s needs, and long enough for the Team to deliver on those needs The Team may NEVER extend the Sprint to accommodate late work. Instead, late work is slipped to the next Sprint 30

31 Commitments should be completed as early in the Sprint as possible 31

32 Sprint Planning Defined Purpose To determine how much work can be accomplished in the upcoming sprint, and answer How do we do it. Outputs Commitment of several features, stories, or bug fixes Sprint Backlog describing how to accomplish the commitment Rules Product Owner must come prepared with clearly defined prioritized backlog items Product Owner has authority over the priorities for the next Sprint Team has authority over the amount of work that can be accomplished the next Sprint Team must make a commitment before the end of the meeting 32

33 Sprint Planning by the numbers 1 5 people x 2 wks x 6hrs/day: Calculate the team s Minus vacation: total manhour capacity for Minus 20% Slack/ Risk Buffer: the upcoming Sprint Commitment Cap: Add the manhour estimates for all the Sprint Backlog tasks 3 Compare the 2 numbers to help the team confirm the commitment is reasonable è J

34 Sprint Planning Best Practices Divide the Planning into 2 Halves In the first half, the Product Owner briefs the team on the next priorities from the Product Backlog, and the Team selects a set of items they deem reasonable In the second half, the team decomposes the commitments into the Sprint Backlog of action items and tasks needed to accomplish those commitments Defer Task Assignments Many teams spend too much effort pre- assigning Sprint Backlog action items to Team Members, often causing the Sprint Planning to last many hours too long. Consider leaving the task assignments until later. This will allow Team Members the opportunity to self- assign the tasks, generating more buy- in. Defer Unknown Details The Sprint Backlog is an imperfect living work plan % of the Sprint Backlog tasks will change over the course of the Sprint. Consider deferring the task definition for those things that are not fully understood, and simply 34

35 Daily Scrum Defined Purpose To review quickly the Team s progress on Sprint commitments, thus answering How are we doing Output Action Items needed to bring the Sprint back on track Updated Sprint Backlog Rules Each Team Member comes to the meeting prepared to offer his/her progress. Each Team Member takes a turn speaking for 60 seconds to: Offer his/her progress Offer to help another Team Members Hold another Team Member accountable for limited progress Each Team Member remains quiet until their turn ScrumMaster remains quiet, except to enforce the rules. 35

36 Daily Scrum Format Three Standard Questions What did I did I since the last Daily Scrum? What will I do before the next Daily Scrum? What is slowing my progress? This is not a status report for the ScrumMaster. It is a risk management & accountability meeting around Sprint Commitments Consider the following alterations: How confident are you we will meet our Sprint commitments? Everyone must report at least 1 impediment slowing progress. 36

37 EXAMPLE: Daily Scrum Sprint Backlog from the enterprise intranet As people explain their progress, the ScrumMaster updates the Sprint Backlog Remote team members dialing in 37

38 Sprint Review Defined Purpose To demonstrate work completed by the team during the Sprint. Output PO Approval or Rejection for each committed feature, story, or bug fix PO feedback for completed work Rules The Product Owner must base his approval or rejection on the agreed- upon acceptance criteria for each commitment. The Team gives the demonstration, not the ScrumMaster. The Team is held collectively accountable for failed commitments, not the ScrumMaster 38

39 Sprint Retrospective Defined Purpose To reflect upon the team s performance in the previous Sprint, thus answering How can we get better Output List of impediments, roadblocks, and issues slowing the team s progress List of action items to escalate or directly address those impediments Rules The Team has full authority over whether the Product Owner or other authority figures may participate, so as to create a safe environment. Team Members are to be candid, but respectful 39

40 Sprint Retrospective Formats Suggested Topics What went well, What could be better, What will we do about it What should be continue doing, What should we start doing, What should we stop doing Suggested Tools Whiteboards, Flipcharts, Index Cards, Sticky Notes 40

41 EXAMPLE: Sprint Retrospective Team mind-map exercise to understand relationships of project issues 41

42 5 Artifacts An artifact is a management document that tells you what we are doing and how well things are going. Product Backlog Release Plan Sprint Backlog Burndown Chart Scrum Board What are we doing? When will we do it? How do we do it How are we doing? How are we doing? 42

43 5 Artifacts Product Backlog Release Plan Burndown Chart Sprint Backlog n n n n n n n n n n n n n n n n n n n n n n Scrum Board 43

44 Product Backlog Defined Owned by Rules Best Practices A single, integrated, prioritized, living That answers what are we doing Product Owner Anyone can add a new request to the backlog Only the PO can prioritize the backlog Only the highest priority backlog items may be worked on The backlog items must have estimates Lightweight More detail for next items; less detail for later items. Living More requests and more information is added as the project progresses. 44

45 Product Backlog Annotation Product Backlog items (user stories, features, or bugs) Items are listed in top-down priority order Estimate for each backlog item 45

46 Release Plan Defined Owned by Rules Best Practices A high- level roadmap that forecasts when we will do what Product Owner Only the PO can prioritize the backlog Dependencies are offered by the team, must be considered Velocity (average output per sprint) is required to know how much to forecast for future sprints Realistic Explains delivery dates as best case, worst case, most likely scenarios Fresh Updated after each sprint 46

47 Velocity Chart An optional graph visualizing the output per Sprint. Used to improve accuracy of Release Plans Features completed per Sprint Team velocity does not improve indefinitely, but stabilizes over time Sprint 1 Sprint 2 Sprint 3 Sprint 4 47

48 Release Plan Annotation The Product Backlog is organized into a forecast of 1 or more releases, each having 1 or more sprints Product Backlog Release A Release B Sprint 1 Sprint 2 Sprint 3 Sprint 4 Release Plan 48

49 Sprint Backlog Defined Owned by Rules Best Practices A single list of action items & tasks that answers How will we do the work Team Collectively planned by the whole team Updated every day to reflect the team s latest decisions Estimated Manhour estimates on each task allow for creation of a burndown chart 49

50 Burndown Chart Defined Owned by Rules Best Practices A chart visualizing how much work is remaining in a timebox, thus answering how are we doing Team Based on backlog data Release Burndown for Product Backlog items remaining in a Release Sprint Burndown for Sprint Backlog items remaining in a Sprint Updated Often to reflect progress Focus on trends, not values 50

51 How Burndowns Work Backlog A backlog is measured by a burndown Burndown 51

52 Release Burndown Story Units Remaining Velocity Sprints in Release 52

53 Sprint Burndown Task Hours Remaining Days in Sprint 53

54 EXAMPLE: Sprint PMI 54

55 Scrum Board Defined Owned by Rules Best Practices A grid that visualizes the state of the Sprint Backlog, thus answering how are we doing Team The layout and meaning of the board is designed by the team Updated every day to reflect the team s progress Highly Visible Displayed in the team area 55

56 EXAMPLE: Scrum GE Issue Revealed: Lower priorities are in progress, while higher priorities are pending 56

57 EXAMPLE: Scrum Tesco Issue Revealed: Concern this feature will not be done by the end of the Sprint Solid Progress on these two features 57

58 3 Roles Product Owner Team Member ScrumMaster Who decides what we do? Who will do it? Who will help us do it? 58

59 3 Roles The Decider Product Owner The Workers Team Members The Catalyst ScrumMaster 59

60 Product Owner Function Responsible For Artifact Best Practices The person who decides what we are doing? Defines what work needs to be done! Prioritizes which work gets done first ü Validates whether work meets expectations Product Backlog Release Plan Burndown Chart (Release Burndown) Single Person with Strategic Authority Collaborative, Representative, Accountable, Committed, Knowledgeable 60

61 Team Function Responsible For Artifact Best Practices The People who actually do the work Determining how much work can be done in the sprint Planning how to do the sprint work Delivering all the sprint commitments Sprint Backlog Burndown Charts (Sprint Burndown) Scrum Board Empowered, Authorized, & Self- Organizing Cross Functional = All skills needed to deliver business value 61

62 ScrumMaster Function Responsible For Artifact Traits The person dedicated to the team Proper implementation of Scrum Challenging the project to improve Accountable that all artifacts are implemented properly, regardless of who implements them Servant Leader Enforces Scrum values, practices, and rules Teaches and coaches, but does NOT manage 62

63 ScrummasterChecklist.org How is my Product Owner doing? Is the Product Backlog prioritized according to his/her latest thinking? Are all the requirements and from all stakeholders for the product captured Is the Product Backlog a manageable size? Could any requirements better implement the INVEST principle? Have you educated your Product Owner about technical debt and how to avoid it? Is the backlog an information radiator, highly visible to all stakeholders? Does everyone know how to use the backlog tool? Is the backlog tool used to to its fullest capacity? Can you help radiate by showing everyone printouts? Can you help radiate by creating big visible charts? Are backlog items organized into appropriate releases? Do all stakeholders know whether the release plan still matches current velocity? Did your Product Owner adjust the release plan after the last Sprint Review Meeting? 63

64 ScrummasterChecklist.org How is my Team doing? Are team members spending some of their time in a groove or in a the state of flow? Do team members seem to like each other, goof off together, and celebrate each other s success? Do team members hold each other accountable to high standards, and challenge each other to grow? Are there issues/opportunities the team isn t discussing because they re too uncomfortable? Have you tried a variety of formats and locations for Sprint Retrospective Meetings? Has the team kept focus on acceptance criteria? Does the Sprint Task list reflect what the team is actually doing? Are your team s task estimates and/or your Scrum board up to date? Are the team artifacts (Scrum board, Sprint Burndown Chart, etc.) visible to the team, convenient for the team to use? Are these artifacts adequately protected from micromanagers? Do team members volunteer for tasks? Are technical debt repayment items captured in the backlog, or otherwise communicated with the Product Owner? Are team members checking their job titles at the door of the team room? Does the entire team consider itself collectively responsible for testing, user documentation, etc.? Is management measuring the team by collective success? 64

65 ScrummasterChecklist.org How are our Engineer Practices doing? Does your dev environment have a push to test button so anyone can detect when they ve broken a feature? Do you have an appropriate balance between automated functional tests and automated unit tests? Is the team writing both system functional tests and unit tests in the same language as the source code? Has your team discovered the useful gray area between functional tests and unit tests? Does a continuous integration server automatically sound an alarm within an hour of a new regression failure? Do all tests roll up into the continuous integration server result? Have team members discovered the joy of continuous design and constant refactoring, as an alternative to Big Up Front Design? Does your definition of done (acceptance criteria) for each functional Product Backlog Item include full automated test coverage and refactoring? Are team members refactoring early & often, or deferring it until a refactoring sprint? 65

66 ScrummasterChecklist.org How is the Organization doing? Is the appropriate amount of inter- team communication happening? Are your ScrumMasters meeting with each other, working the organizational impediments list? When appropriate, are the organizational impediments pasted to the wall of the development director s office? Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? Is your organization one of the few with career paths compatible with the collective goals of your teams? Answer no if there s a career incentive to do programming or architecture work at the expense of testing, test automation, or user documentation. Has your organization been recognized by the trade press or other independent sources as one of the best places to work or a leader in your industry? Are you helping to create a learning organization? 66

67 Agile Requirements 67

68 User Story Format [Title] As a <role>, I want <feature>, So that <benefit> The system shall provide <feature> User Stories are formatted from the perspective of the end user, rather than the system. They offer additional context than traditional shall statements

69 3 Principles of User Stories Card User Story information is lightweight. It fits onto a single index card. Conversation When the story is selected for a Sprint, further details are finalized in conversations with the Product Owner Confirmation Acceptance criteria are added to the User Story, to confirm the feature was implemented properly 69

70 User Story Examples As a user, I can backup my entire hard drive. As a user, I can indicate folders not to backup so that my backup drive isn t filled up with things I don t need saved. As a power user, I can specify files or folders to backup based on file size, date created, and date modified. 70

71 Avoid Poison Words As a user, I want the default behavior to backup all my files As a user, I don t want any virus- infected files to be backed up 71

72 Agile Estimation 72

73 PRECISION vs. Accuracy! Precise, but Inaccurate Imprecise, but Accurate As project leaders, we need to embrace the value of imprecise, yet sufficiently accurate estimates

74 T- Shirt Sizes Defined S M L XL XXL Feature Estimate Actual (manhours) Display profile data M 30 Forgot password M 23 Upload photo to User Profile M 18 Display photo in webpage header M 19 74

75 T- Shirt Sizes Quantified S M Average of actual effort for M Historical data converts the categories into data L 45.4 XL Confidence interval for L 74.3 Full range for XL 75

76 T- Shirt Sizes Example (in manhours) Feature Est. Lower CI Avg Upper CI Display profile data M Configure new XML feed S Forgot password M Import legacy data XL Upload photo to User Profile M Display photo in webpage header M Export data into Report L Total Best Case Most Likely Worst Case 76

77 Rules for Planning Poker 1 Pick a medium- sized user story, and assign it second story description 3 Vote simultaneously on size, relative to the first Medium 4 Process Votes 4.1 If values differ by only 1 scale (e.g. 8pts versus 13pts), take the higher 4.2 If values differ by 2 scales (e.g. 5pts vs. 8 vs. 13 pts), take the middle 4.3 Otherwise, have 60 second debate. Return to step 3 5 If no resolution after 3 votes, the team does not have enough information to take the story. Task the team to get more clarification / information to take the story on the next sprint.