Presentation is loading. Please wait.

Presentation is loading. Please wait.

© Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices3 Roles, 3 Ceremonies, 3 Artifacts,

Similar presentations


Presentation on theme: "© Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices3 Roles, 3 Ceremonies, 3 Artifacts,"— Presentation transcript:

1 © Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices –Speaker: –Speaker: Dan Mezick – – –Phone: –URL: –URL: NewTechUSA.com

2 © Copyright 2002: All rights reserved Agile ASAP- RoadMap PART1: Quick Overview of Scrum’s ideas PART2: Three Roles Defined Three Ceremonies Defined Three Best Practices Defined PART3: Scrum in Practice PART 4: Next Steps & Resources

3 © Copyright 2002: All rights reserved PART1: Quick Overview of Agile & Scrum The term Agile is an umbrella xP, Scrum, Test Driven Development (TDD) Agile is Empirical and Adaptive –“Iterative” Waterfall is Predictive –Prediction is error prone; assumptions are ‘snapshots’ that can expire over time Agile is “planning, with ‘outs’.”

4 © Copyright 2002: All rights reserved The Case for a New Approach Huge number of statistics on FAILED PROJECTS Huge amounts of WASTE Systems are often NOT deployed to production Users and software developers are polarized Software is almost always delivered late Research shows clearly that software development IS NOT manufacturing

5 © Copyright 2002: All rights reserved Agile Software Development: What is It? The term Agile is an umbrella term It is xP: ExTreme programming (pairs) It is Scrum: A radical project management method It is Test Driven Development (TDD)

6 © Copyright 2002: All rights reserved Agile Software Development: What is It? Agile is EMPIRICAL and ADAPTIVE –Empirical: based on most recent experience –Adaptive: responds to feedback Agile is ITERATIVE –Iterative: Cuts processes and experience into small, manageable chunks Agile is PLANNING– with “outs” –A common misconception is that Agile’s lack of prediction = “lack of planning”. This is WRONG.

7 © Copyright 2002: All rights reserved Empirical Process Overview Good for high-change, inherently unstable environments Terminology comes from industrial manufacturing theory Empirical approaches are adaptive. –Frequent Measurement –Dynamic (adaptive) response

8 © Copyright 2002: All rights reserved Empiricism: Planning vs. Prediction Empirical processes DO plan –But empirical processes DO NOT predict KEY POINT: Planning is NOT prediction –Prediction is not planning Prediction creates a “comforting illusion”

9 © Copyright 2002: All rights reserved Empirical Process vs. Defined Processes Teams have unique and complex human chemistry Organizations have a unique history and culture SOFTWARE IS COMPLEX. BUSINESS SOFTWARE DEFINITIONS ARE OFTEN VERY COMPLEX Complex tasks with unique 1-time objectives are best solved empirically (adapting to experiential feedback)

10 © Copyright 2002: All rights reserved Empirical Process vs. Defined Processes Empirical approach incorporates planning but not prediction –List all the likely tasks –Prioritize some and define a first step –Execute, and remain open to learning from experience New tasks emerge, prioritize higher Others go lower in priority –Summarize findings You have ability to pull plug quickly at low cost

11 © Copyright 2002: All rights reserved Defined Processes Defined approach incorporates planning AND prediction Works for well-understood solutions –Does not work so good for delivering software Assumes your product is a repeatable thing –Example: manufacturing an automobile or part Same thing over and over You have no ability to pull plug quickly at low cost –“Stopping the production line” is expensive

12 © Copyright 2002: All rights reserved Defined Processes Defined approach incorporates planning AND prediction –List all the likely tasks –Prioritize all, and define ALL of the steps, to the Nth degree Define all predicted steps AND predicted detailed content of each step –Any experience is distorted to fit the plan New tasks emerge: ignore them (not part of spec) Others go or higher lower in priority: ignore (plan is fixed)

13 © Copyright 2002: All rights reserved Defined Processes Definition of length and breath of steps becomes a goal. Assumes all predictions are 100% accurate Long delay in finding out what is working Huge changes in assumed environment as a function of time. You have no ability to pull plug quickly at low cost when using a Defined process such as predictive ‘waterfall’ software development.

14 © Copyright 2002: All rights reserved Empirical vs. Defined Approach Defined approach pretends to define time and cost parameters. Actually this is a prediction. Defined approach provides illusion that all actors completely understand the problem. Defined approach provides illusion that all actors completely understand the solution space Defined approach tends to ignore new information that is generated as the actors focus on the work.

15 © Copyright 2002: All rights reserved Empirical vs. Defined Approach Empirical approach avoids prediction and instead creates a ‘timebox’ for generating an iteration of experience –Using highly detailed measurement tools Empirical approach assumes the whole problem cannot be understood up front Empirical approach assumes all actors learn more about the solution as part of experience Empirical approach incorporates new information as it becomes available

16 © Copyright 2002: All rights reserved Agile: Entrepreneurship Aspects Testing with small investment Probing for solutions Deferring irrevocable decisions till the last responsible moment. Self-organizing teams Managing risk relative to reward at all times

17 © Copyright 2002: All rights reserved Empiricism & Adaptation: Summary Software development is not manufacturing Software development is about creating 1 and only 1 instance of the product Teams are unique Technology changes Businesses change (mergers, new products etc) This is high-change, unstable setup that is IDEAL for using Empirical, adaptive approaches.

18 © Copyright 2002: All rights reserved Agile Development: What is It NOT? Agile is NOT WATERFALL –Waterfall is Predictive –Prediction can filter and distort reality –Prediction is error prone When new information comes in, that new info is often DISTORTED to fit the plan, rather than adapting the plan to the new information.

19 © Copyright 2002: All rights reserved Agile Development: What is It NOT? Agile is NOT PREDICTION –Managing to a predicted outcome has several drawbacks –Predicting time, money, effort works for well-understood, repeatable and relatively simple processes. Manufacturing is a defined process Software development is a complex process

20 © Copyright 2002: All rights reserved Agile Development: What is It? Agile confronts reality and does not pretend Agile radically redefines the Project Lead role. Agile radically redefines the Development Team role. Agile radically redefines the Product owner role. –What is the #1 cause of software development project failure? Agile confronts the reality of software development –Coding business apps is easy –Defining business apps is difficult. Why?

21 © Copyright 2002: All rights reserved PART 2 Scrum’s 3 Roles, 3 Ceremonies and 3 Best Practices

22 © Copyright 2002: All rights reserved Scrum’s THREE ROLES The actors in Scrum: Product Owner, Scrum master, Team. Product Owner: Own and prioritizes the Product Backlog Scrum Master: Facilitates the Scrum process –NOT a traditional Project Manager !! Team: Produces Increments of Shippable Product Functionality

23 © Copyright 2002: All rights reserved Scrum’s THREE ROLES The Product Owner: –Defines and Prioritizes Features Owns the gathering of requirements –Agrees to Iteration Ground Rules Set length of calendar time for Sprint – (2,3,4 weeks typical) Does not interfere with Sprint (no scope creep) Can pull the plug at any time (has the power) Honors rules and the Scrum process during Sprints

24 © Copyright 2002: All rights reserved Scrum’s THREE ROLES Scrum Master: A Boundary Manager –Supports the Team –Facilitates the Daily Scrum meeting. Asks each developer: What did you do yesterday? What are you doing today? What is in your way? Listens and watches carefully during Scrum meeting –Pays careful attention to non-verbal cues –Removes Impediments in Way of Team Secures resources (monitors, rooms, etc) –Communicates to Product Owner

25 © Copyright 2002: All rights reserved Scrum’s THREE ROLES The Team: –Participates in design To gain understanding of problem/solution space

26 © Copyright 2002: All rights reserved Scrum’s THREE ROLES The Team: –Selects subset of prioritized Product Backlog for Sprint commitment Estimates the effort Fills the timebox with work Commits to the work as a team

27 © Copyright 2002: All rights reserved Scrum’s THREE ROLES The Team: –Self organizes: Everyone commits to ALL TASKS necessary during the Sprint Determines the nature of self-organization –Teams select work for each Sprint –Teams self-organize –Teams have a ‘velocity’

28 © Copyright 2002: All rights reserved Scrum’s THREE ROLES Team Velocity: How much work the team can average per iteration, FOR THAT TEAM –Each time has a personality –Each team is unique –Teams ‘velocity’ becomes very predictable over time

29 © Copyright 2002: All rights reserved Scrum’s THREE CEREMONIES Sprint Planning Daily Scrum Sprint Review (retrospective)

30 © Copyright 2002: All rights reserved Scrum’s THREE CEREMONIES Ceremony #1: Sprint Planning Meeting –Product Owner reviews: Vision, Roadmap, Release Plan –Team reviews: Estimates for each item on Backlog that is a candidate for the Sprint –Team pulls the work: From the Product Backlog onto the Sprint Backlog

31 © Copyright 2002: All rights reserved Scrum’s THREE CEREMONIES Ceremony #2: The Daily Scrum –By and for the Team –Other may attend and NOT speak –Team members speak, others listen –Team stays on task with the 3 questions, divergences are addressed offline outside of this meeting –Visibility, clear understanding on a day-by-ay basis Product owners know the score on a daily basis –Can pull the plug at ANY time

32 © Copyright 2002: All rights reserved Scrum’s THREE CEREMONIES Ceremony #3: Sprint Review Meeting –Part 01: Product Demo Led by Product Owner –Part 02: Sprint Retrospective Led by Scrum Master What worked? What didn’t? What adjustments can we make now?

33 © Copyright 2002: All rights reserved Scrum’s THREE ARTIFACTS Artifact #1: Product Backlog –A list of features, prioritized by business value –Each feature has an associated estimate, provided by the ACTUAL team who will do the work –Backlog items come in from diverse sources, including the Team

34 © Copyright 2002: All rights reserved Scrum’s THREE ARTIFACTS Artifact #2: Sprint Backlog –Topmost subset of the Product Backlog, loaded onto the Sprint’s “timebox” –Usually has more detail attached, including planned hours and primary person responsible to do the work during the Sprint –Is the list of work the Team is addressing during the current Sprint

35 © Copyright 2002: All rights reserved Scrum’s THREE ARTIFACTS Artifact #3: Burndown Chart –Provides visibility into the Sprint –Illustrates progress by the team –Work on the Horizontal, Time on the Vertical

36 © Copyright 2002: All rights reserved Scrum’s THREE ARTIFACTS Sample BurnDown Chart

37 © Copyright 2002: All rights reserved Scrum’ THREE BEST PRACTICES Best Practice #1: User Stories –Plain-english requirements, written on common 3X5 index cards –Form: As [a type of user] I want to [perform a specific action] such that [result] –Example: “As a web user, I want to make a reservation, such that I may secure my lodging” –Stories that are big are called EPICS –Acceptance criteria goes on card back

38 © Copyright 2002: All rights reserved Scrum’ THREE BEST PRACTICES Best Practice #2: Planning Poker –A way for the team to do estimates –Each participant has cards numbered 1,2,3,5,8,13,21 –Values represent ‘story points’ of effort –Players discuss feature, then throw down a card together –Differences are noted and discussed, then process repeats till a concensus estimate is formed

39 © Copyright 2002: All rights reserved Scrum’ THREE BEST PRACTICES Best Practice #3: Use of the Scrum Board –Scrum Board is a rows-and-columns depictions of work-in-progress –Items of work are rows, work status labels are columns –Work is addressed from top to bottom –Work migrates from left to right on the board

40 © Copyright 2002: All rights reserved Scrum’ THREE BEST PRACTICES Sample Use of the Scrum Board

41 © Copyright 2002: All rights reserved Scrum’ THREE BEST PRACTICES Sample Use of the Scrum Board

42 © Copyright 2002: All rights reserved Scrum’ THREE BEST PRACTICES Sample Use of the Scrum Board

43 © Copyright 2002: All rights reserved PART 4: Applying Scrum Managing a Release is managing tradeoffs in: –Cost –Date –Quality –Functionality

44 © Copyright 2002: All rights reserved Agile Software Development Best Practices Co-location of entire development team in one lab Co-location or CLOSE proximity to Product Owner –Or delegate Engaged Product Owner or Delegate –Team needs answers in 15 minutes Daily Scrum

45 © Copyright 2002: All rights reserved Agile Software Development Best Practices Daily build –Implies a deep testing infrastructure –Daily build encourages fast development Developers know it will be tested NOW Self-organizing Team Team involved in design stage –Builds understanding of problem and perception of the solution space

46 © Copyright 2002: All rights reserved Essential Web Sites AgileAlliance.org –National organization of Agile leaders Agile2007.org (www.Agile2006.org)www.Agile2006.org –Annual conference controlchaos.com –Scrum defined danube.com –Scrumworks newtechusa.com/agile/blog –My blog shmula.com/183/12-questions-with-mary- poppendieck

47 © Copyright 2002: All rights reserved Mythical Man-Month By Fred Brooks

48 © Copyright 2002: All rights reserved AgileSoftware by Schwaber & Beedle

49 © Copyright 2002: All rights reserved Agile Estimating by Mike Cohn

50 © Copyright 2002: All rights reserved Agile PM with Scrum by Schwaber

51 © Copyright 2002: All rights reserved Implementing Lean by Poppendieck

52 © Copyright 2002: All rights reserved Thanks ! Speaker:Speaker: Dan Mezick Phone: Phone: URL:URL: NewTechUSA.com


Download ppt "© Copyright 2002: All rights reserved Scrum 3 Roles, 3 Ceremonies, 3 Artifacts, & 3 Best Practices3 Roles, 3 Ceremonies, 3 Artifacts,"

Similar presentations


Ads by Google