Intro to Agile, Scrum and Kanban

Transcription

1 Intro to Agile, Scrum and Kanban University of Southern Maine Day 2

2 Agenda Day/Sprint 2 Recap from Day 1 Agile Planning Scrum Framework Day 2 Retro

3

4 Recap from Day 1

5 Our world is changing and becoming increasingly complex.

6 Management Theories

7 Push vs. Pull Systems Align inventory levels with actual consumption

8 Lean Manufacturing

9 Process Models Defined (known steps) Empirical (unknown) Waterfall Kanban Scrum Lean Startup

10 Stacey Matrix No Certainty Chaos Requirements Complicated Complex Best suited for the Empirical process control approaches Simple Complicated Technology No Agreement

11 Stacey Matrix No Certainty Empirical x xx Defined Waterfall Scrum Lean Startup No Agreement

12 What is Agile? It s not a process nor a methodology. Agile is a mindset defined by values guided by principles and manifested through many different practices. frameworks XP Scrum Kenban practices Refactoring Pairing User Stories Story Points not required but work well

13 What is Agile? Agile Adaptive FDD TDD Scrum Crystal Scrumban DSDM Lean Kanban Lean Startup XP Agile Unified Proces SAFe

14 Agile Manifesto Values & Principles

15 Agile Values Individuals & interactions over processes and tools Working software (product) over comprehensive docs Customer collaboration over contract negotiation Responding to change over following a plan WE VALUE THESE MORE WE RECOGNIZE THE VALUE HERE

16 Agile Principles

17 - 1 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

18 - 2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

19 - 3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

20 - 4 - Business people and developers must work together daily throughout the project.

21 - 5 - Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

22 - 6 - The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

23 - 7 - Working software is the primary measure of progress.

24 - 8 - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

25 - 9 - Continuous attention to technical excellence and good design enhances agility.

26 Simplicity the art of maximizing the amount of work not done is essential.

27 The best architectures, requirements, and designs emerge from self-organizing teams.

28 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

29 Table Discussion How easy will it be to follow the Agile Manifesto in your organization?

30 Questions Backlog Write up your questions To do One per post-it Create a task board Prioritize Busy Done

31 Agile Planning

32 Agile Planning Sense & Respond vs. Predict and Plan Difficult to know everything ahead of time Change is expected, inspect and adapt

33 Iron Triangle

34 The Planning Onion Vision & Strategy Roadmap Release Sprint Daily

35

36 Agile Planning Vision & Strategy Strategy & Roadmap Planning Roadmap Release Sprint Daily

37 Vision/Strategy & Roadmap

38 Vision/Strategy & Roadmap

39 Vision/Strategy Board

40 Let your vision guide you Product or service vision describes your overarching goal. Your vision should not restate your product or service idea. It should rather go beyond it. Try to come up with an altruistic vision, a vision that focuses on the benefits created for others, can help you with this.

41 Put the Users First Choose a clear-cut and narrow target group. Describe the users and customers as clearly as you can and state the relevant demographic characteristics.

42 Clearly State the Main Problem or Benefit Once you have captured your target users, describe their needs. Why they would purchase and use your product or service? What problem will your product or service solve? What pain or discomfort will it remove? What tangible benefit will it create?

43 Describe the Essence of Your Product or Service Once you have captured the needs, describe your actual product or service idea. Identify those features that really matter to the target group.

44 State Your Business Goals Make explicit why it is worthwhile for your company to invest in the product or service. Prioritize the business goals and state them in the order of their importance.

45 Extend your Board The Vision Board s simplicity is one of its assets, but it can sometimes become restricting. competitors partners revenue sources

46 Put it to Test Your initial board is likely to be wrong.

47 How clear is the vision and strategy for the initiatives that you work on?

48 Roadmap Planning

49 Product or Service Roadmap A high-level plan that shows how a product or service is likely to evolve It typically covers several major releases or service versions

50 Initiative Kick-off Attendees: Product Owner, ScrumMaster, Team, and Stakeholders Input: Vision/Strategy Board Steps: Create personas, outline features, select a goal and create actionable items. Outcome: Product or Service Canvas, Initial Product Backlog

51 Personas

52 Personas

53 Personas, Epics, & Storyboards

54 Product or Service Roadmap Benefits Continuity of purpose Stakeholder alignment and collaboration Help with prioritization Helps with portfolio management Complements the product backlog

55 Product or Service Roadmap Common Mistakes View it as a fixed plan or a commitment Review and change your roadmap frequently Too much focus on features Focus on goals instead of features List largely unrelated features to please individuals or groups

56 Product or Service Convas

57 Product or Service Roadmap

58 Product or Service Convas

59 Roadmap and Product Backlog

60 Roadmap Planning

61 How clear is your roadmap? not clear very clear

62 Visualize Current Roadmap This exercise is about visualizing your roadmap for the next year. Take a bunch of index cards. Each index card should state a project name (or feature if you only have 1 product). If any commitments have been made on when it will be delivered then put that date on the card as well. Think of current projects or features that you are supporting and not just new items. List everything you can think of. Project / Feature Name Due Date

63 Visualize Current Roadmap Project / Feature Name % done & size Due Date Indicate percentage complete, and a rough size (weeks or months).

64 Is your current list of work realistic?

65 How do you decide whether to do a project/feature or not?

66 Functions / Features used on a typical system. Sometimes 16% Often Never 13% 45% Always 7% Rarly Agile was created to help 19 identify that 64% early and not build it. The Standish Group Chaos Report

67 Here are some questions which can help decide if a feature or project should be done: How many customers will use this? How much revenue will this generate?? Will it impact our reputation if we don t do this? Are there penalties for not doing this? Is this aligned with the company/product vision or strategy? $

68 Cross out products/features that are not candidates for the next year based on what you have just learned.

69 Cross out products/features that are not candidates for the next year based on what you have just learned. Order what s left. Only one thing can be priority 1!

70 Group Discussion: How can you prevent the wrong project/features getting on your roadmap?

71 Scrum Framework Product Vision

72 Roles, Meetings, Artifacts 3 Roles -ScrumMaster, Product Owner, and Team 3 Artifacts - Product Backlog, Sprint Backlog, Increment 5 Meetings - Daily, Planning, Review/ Demo, Retrospective, and Grooming

73 Roles, Meetings, Artifacts 3 Roles Team ScrumMaster Product Owner

74 Product Ownership

75 Roles Exercise

76 Roles, Meetings, Artifacts 5 Meetings Grooming Planning Daily Stand-up Review/Demo Retrospective

77 Scrum Framework Product Vision

78 Backlog Grooming Understand requirements Estimating Acceptance Criteria Shared Understanding When Before the sprint (during the previous sprint) Time: For 2 week sprint: 2 x 1 hrs Looked at 3x Vertical Slice Design DEV QA Who? Product Owner, ScrumMaster, team, anyone with knowledge

79 Backlog Grooming

80 Sprint Planning

81 Who should attend the Sprint Planning meeting?

82 Scrum Framework Product Vision

83 Sprint Planning

84 Sprint Planning Part 1 What Commitment Check acceptance criteria SM reminds Leave Public Holidays Previous velocity When? 1st thing of the sprint Time? 1h per week of sprint (2 week sprint = 2 hours) Who? Team, PO, SM, anyone with knowledge

85 Sprint Planning Part 2 How Design session Solutions identification session (Whiteboarding) When? After SP1 Time? 1h per week of sprint How team will deliver this Create tasks Who? Team, SM, PO on call

86 What is the maximum length of a sprint?

87 Sprint Execution

88 Scrum Framework Product Vision

89 Sprint Execution

90 Sprint Burndown Amount of work remaining Hours Tasks Story points Ideal line Owned and updated by team Time -> days

91 Sprint Review

92 What is the purpose of a Sprint Review meeting?

93 Scrum Framework Product Vision

94 Review Product Only show working product < 1hr to prepare Only DONE stories Feedback -> State of release When? End of sprint Time? 1-2 hrs (more with multiple teams) Who? People who have feedback, Team, SM, PO

95 Review

96 Sprint Retrospective

97 What s the goal of the Sprint Retrospective meeting?

98 Scrum Framework Product Vision

99 Retrospective Process How are we working as a team Data -> Analyse -> 1 Action (facts) (root cause) (team) Safety SM Prepares & facilitates When? After sprint review Time? 90 min Who? Team + SM PO if trust Anyone team invites