AN INTRODUCTION TO SCRUM GUIDE SLIDERS

Transcription

1 NO ONE DOES SCRUM BY THE BOOK AN INTRODUCTION TO SCRUM GUIDE SLIDERS

2 Zach agileoutloud.wordpress.com

3

4 We Tried Baseball and It Didn t Work I wrote this in 2006! ft

5 When [people] are not able to overcome the dysfunctions, they tend to tweak the framework to accommodate the dysfunctions. Ashok Singh I dub it, Singh s Inevitable Avoidance Principle. Let it be noted. Tim Ottinger

6 No one does Scrum by the book! -- The World at Large Risk #1: Playing not-baseball" is so common, we ve started accepting all of it as fact. I ve seen Scrum kill a company!

7 Existing structures, often managed by metrics ensure that the Inevitable Avoidance Principle is Risk #2: Existing approaches to management and metrics lead us astray. inevitable.

8 Risk #3: Sometimes, what matters most is hard to see (and even harder to measure).

9

10 Sharing insights and ideas from down under: Organizational behaviors Agile systems of work Estimation and decision making

11 Neil s method to facilitating conversation and shared understanding for organizational mindset triggered an idea: What if we harnessed the same visual power for companies learning Scrum?

12 Risk #1: Playing not-baseball is so common, we ve started accepting all of it as fact. Risk #2: Existing approaches to management and metrics lead us astray. Risk #3: Sometimes, what matters most is hard to see (and even harder to measure).

13 My current Scrum Guide Sliders dashboard this picture is mostly for people who want to save the slide. We ll go through each section next (with bigger text )

14 The Development Team Backlog items are scoped and solutioned for team Self-organizing. No one tells the team how to turn PBI into increments of releasable functionality Component team or skills missing to create/release Cross functional: all skills necessary to create a product increment Team members have functional titles No titles for team members, regardless of work being performed by the person Team members work according to a functional silo or sub-team No sub-teams, regardless of domain like testing or business analysis Team members are measured on individual contribution and performance Accountability belongs to team as a whole, regardless of specialized skills and area of focus What would you add/change/remove? Experiment with sliders to fit your context, goals, and culture!

15 The Product Owner Product Backlog is maintained by committee (multiple people change backlog priorities) Product Backlog is stored in documents or "in the head" of the Product Owner Backlog items document nearly everything conceivable about the work to be done Product Owner is the sole person responsible for managing the Product Backlog Backlog is an ordered list, visible, transparent, and shows what the Scrum Team will work on next (single source) Backlog items are short placeholders for team conversations about work to be done [People] tell the PO what new backlog priorities are The entire org respects PO decisions; address the PO when wanting to change priority PO communicates priorities/deadlines to team PO communicates value, clarity, purpose to team What would you add/change/remove? Experiment with sliders to fit your context, goals, and culture!

16 The Scrum Master SM is a manager of team process / administrator of work Missing or sporadic Scrum ceremonies SM is responsible for results (involved in work, reports status, etc.) SM is a servant-leader for the Scrum Team / facilitator of Scrum principles and practices Scrum ceremonies occur in alignment with the framework SM is responsible for coaching and mentoring within the organization/environment Suitable number of teams to ensure process/ceremony occurs Suitable number of teams for coaching, mentoring based on team / personal skills SMs take directives, initiatives for change from management and stakeholders SMs work together and with stakeholders to increase effectiveness of Scrum in the org What would you add/change/remove? Experiment with sliders to fit your context, goals, and culture!

17 The Sprint Sprint durations vary and may exceed one month Sprints are a consistent duration of one month or less Quality is traded (overlooked) for scope Quality goals are non-negotiable and cannot decrease The team lacks a coherent daily plan OR planning is directed (by non-dev team mbr) The value of a sprint is described by the count of items to deliver Work is "in-progress" or must be turned over to another team at sprint end A sprint does not end with a feedback loop (demo) Retrospectives lack action or implementation of ideas Every day, the Team self-organizes to create a plan for the next 24 hours, emphasizing teamwork and trust A sprint goal exists: a coherent function, or value proposition, that causes the Team to work together The result of a sprint is a releasable increment of software A sprint ends with a review, resulting in a revised product backlog (e.g., probable items for next sprint) Retrospectives identify improvements/ideas to implement in the next sprint What would you add/change/remove? Experiment with sliders to fit your context, goals, and culture!

18 Sliders have excellent synergy with well-known techniques to decide what to do! Three in particular have been very effective for me: Force Field Analysis Social Cause Mapping Perspective Mapping

19 Synergy with Force Field Analysis Want more ideas for using Force Field Analysis?

20 Synergy with Social Cause Mapping A possible cause A possible cause A possible cause Dan Greening The problem or thing of interest

21 Synergy with Social Cause Mapping

22 Synergy with Perspective Mapping Get more help with Perspective Mapping from Jason Little!

23 The Introduction to Scrum Guide Sliders We have many questions and/or need more information!? We re feeling satisfied and confident with Scrum Guide Sliders! while measuring how strictly you are adhering to the rules and principles of Scrum is not the point, if you believe that an agile approach, such as Scrum, is a viable means of becoming successful then assessing yourself against the application of that framework or process as a proxy metric of success might not be a bad idea. -- Geoff Watts, Scrum Mastery: From Good to Great Servant Leadership (p. 71)