Shu-Ha-Ri: Measuring Agile Adoption Maturity

Shu-Ha-Ri Measuring Maturity of Agile Teams

Dan Fuller May 21, 2014

Contents

1

Introduction(Shu-Ha-Ri)

2

Visualizing the Metaphor

3

Shu (Stage 1) Team Behaviors

4

Ha (Stage 2) Team Behaviors

5

Ri (Stage 3) Team Behaviors

6

Shu-Ha-Ri Applied to Agile Teams

7

Provably Better Agile Teams

Shu-Ha-Ri • Shu-Ha-Ri is the journey that Aikido martial arts students go through from novice towards mastery. • It is becoming the metaphor the Agile community is using to measure maturity of Agile teams. • This session will explain Cognizant’s implementation of Shu-Ha-Ri to measure Agile Teams…

Source: Alastair Cockburn @ http://alistair.cockburn.us/Shu+Ha+Ri

Visualizing the Metaphor

Nascent Teams Follow the Rules

Proficient Teams

BE the Rule Break the Rules

-Ri -Ha

-Shu (Stage 1)

Hyper Performing Teams

(Stage 2)

(Stage 3)

Shu (Stage 1) Team Behaviors • Learning the process basics, & team members • Growing their rapport both professionally and socially • Mimicking the practices • Learning to work together • Following the rules • Learning the process • A collection of skilled individuals learning their roles

-Ri

-Ha (Stage 2)

-Shu (Stage 1)

(Stage 3)

Ha (Stage 2) Team Behaviors • Starting to question practices that seemingly may not work for them. • Understanding the practices, and the importance of the principles and values. • Coming to a deeper understanding of the art than pure repetitive practice will allow. • Beginning to move beyond a collection of skilled individuals. • Developing their own personalities. • Beginning to break the rules.

-Ri (Stage 3)

-Shu (Stage 1)

-Ha (Stage 2)

Ri (Stage 3) Team Behaviors • Creating output greater than the sum of the work of the individuals. • Breaking the rules to gain an advantage. • Progressing more through selfdiscovery than instruction. • Consistently thinking and acting as a unit. • Adjusting with little friction

-Ha -Shu (Stage 1)

(Stage 2)

-Ri (Stage 3)

Shu-Ha-Ri Applied to Agile Teams

What do we evaluate… and why? We chose 12 particular dimensions that cover the entire breadth of Agile methods from Product Backlogs to Working Software. Factoring in the roles of Product Owners, Scrum Masters, Developers and Testers Some are Quantitative Quantitative,, others are Qualitative Qualitative.. Let’s take a look at the 12 dimensions…

Quantitative Dimensions Velocity

How much working software is being created?

Quality

How good is the working software?

Story Creation

Accuracy of Commitment

Accuracy of Estimates

Overtime

How comfortable are we with creating user stories? Is the team delivering their commitments? How well are we estimating relative size and effort? How sustainable is the pace?

Qualitative Dimensions Sprint Planning

Release Planning

Daily Scrum

How effective are we conducting our sprint planning sessions? How far out into the future are we planning our work? How effective is the facilitation of the standup?

Story Estimation

How smooth is the estimation process?

Release Frequency

How often is working software released?

Retrospectives

Are we actually doing meaningful process improvement?

Visualizing the Results • All teams start at Stage 1 (Shu) (Shu) • To achieve Stage 2 (Ha) you must be at Stage 2 for all 12 dimensions, likewise for Stage 3 (Ri) Sprint Planning

Think of it like the rings on a tree (Cambia), • Stage 1 (Shu) - Inner Ring - Pith • Stage 2 (Ha) - Middle Ring - Xylem & Floem

Release Frequency Release Planning

3

Accuracy of Commitments

2 Accuracy of Estimates

1

Quality

Effort Estimation

Overtime

• Stage 3 (Ri) - Outer Ring – Bark

Daily Scrum

Story Creation Process

Retrospectives Velocity

Sprint Planning Stage 1 – Shu : Represented in the center of the chart

Sprint Planning Release Frequency Release Planning

Daily Scrum



Team struggles with the process, has trouble defining tasks & duration.

Quality

Effort Estimation Overtime



?

Sprint Planning Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum


Team is comfortable with the process, is able to do sprint planning in 3-4 hours. 3 – – 4 4 Hours


Quality




Sprint Planning Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Team is identifying tasks and durations in advance and meeting is fast and efficient Quick Meeting

Release Planning Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Team is not sure what it will be doing next sprint

!

!

!

Release Planning Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Team knows what it will be working on 2-3 sprints into the future

Quality




2 - 3 Sprints

Release Planning Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Team knows what it will be working on 3 or more sprints out into the future

Quality




_ Sprints >3

Daily Scrum Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Lots of off-topic discussion, resembles a status meeting

--

-------

Daily Scrum Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum


Everyone is participating and the 3 basic questions are being addressed To Do


Quality

Accomplished Accomplishe d Impediments




Daily Scrum Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Executed with precision, nothing extraneous, transparency & truth are shining through

Quality Stage 1 – Shu : Represented in the center of the chart

Sprint Planning Release Frequency

Defect Density > 25%

Release Planning

Daily Scrum



Quality




Quality Stage 2 – Ha : Represented in the 2nd circle of the chart


Defect Density between 25% and 10%

Release Planning

Daily Scrum



Quality

! Effort Estimation Overtime



Quality Stage 3 – Ri : Represented in the outer circle of the chart


Defect Density < 10%

Release Planning

Daily Scrum



Quality




Estimation Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Team struggles gaining consensus on story point estimates, meeting takes a long time

Estimation Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum


Team is able to estimate about 6 stories per hour 1Hour / 6 Stories


Quality




Estimation Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum


Team is able to estimate more than 8 stories per hour. 1Hour / 8+ Stories


Quality




Story Creation Process Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Unpredictable Story Creation Rate, Story Authors Uncomfortable

Story Creation Process Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Quality




Story Authors starting to become comfortable, story production rate is rising

Story Creation Process Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Story Production Rate >= Velocity of Teams

Velocity Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Velocity is unpredictable, it’s up, it’s down from sprint to sprint

Velocity Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Quality




Velocity growth trend is increasing for three sprints in a row

Velocity Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Velocity growth trends slows, levels off, is consistent & predictable

Retrospectives Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Team seems to be going through the motions on the Retro

Quality




Collect Data

Retrospectives Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Quality




Team has positive discussions aligned with Agile Manifesto themes and values

--

-------

Retrospectives Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Team is instituting meaningful process improvement every sprint

Overtime Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Team frequently has to put in overtime to deliver against commitments

?

Overtime Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Quality




Overtime occurs, but is minimal and team is working at a sustainable pace

!

Overtime Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum


Overtime is rare, and it is usually the teams choice to overachieve Sustainable


Quality




Accuracy of Estimates Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Initial Story Point Estimates are frequently revised

Accuracy of Estimates Stage 2 – Ha : Represented in the 2nd circle of the chart


Initial estimates are within 25% of actuals

Release Planning

Daily Scrum



Quality

0 Effort Estimation Overtime



25

50

75

100

Accuracy of Estimates Stage 3 – Ri : Represented in the outer circle of the chart


Initial estimates are within 10% of actuals

Release Planning

Daily Scrum



Quality

0 Effort Estimation Overtime



25

50

75

100

Accuracy of Commitments Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Quality




Team frequently doesn’t deliver against story point commitments

Accuracy of Commitments Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Quality




Team usually delivers against its sprint commitment but often has adopted work

!

Accuracy of Commitments Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Team always delivers against its sprint commitment and adopted work is rare

Release Frequency Stage 1 – Shu : Represented in the center of the chart


Daily Scrum



Team struggles to get working software out the door every sprint

Quality

? Effort Estimation Overtime



Release Frequency Stage 2 – Ha : Represented in the 2nd circle of the chart


Daily Scrum



Quality




Most sprints result in a good build with occasional build issues

Release Frequency Stage 3 – Ri : Represented in the outer circle of the chart


Daily Scrum



Quality




Every sprint results in a good build of working software, no exceptions

Measure Teams over Time Team advanced from Stage 1 to 2 Sprint 10 Release Frequency

Sprint Planning


Sprint 15 Release Frequency

Release Planning

Daily Scrum


Quality

Effort Estimation

Overtime



Sprint Planning

Release Planning


Daily Scrum


Quality

Effort Estimation

Overtime



Overtime moved from Stage 1 to 2 Team is at Stage 1 due to Overtime

Velocity moved from Stage 2 to 3

Data Collection Qualitative data should come from Agile Lifecycle Management tools (ALM) and Integrated Testing Suites, e.g.: •

Rally

•

VersionOne

2 Approaches to Data Collection for Qualitative Dimensions: •

Coach Led Interview of Product Owner and Scrum Master (Benefit – Rich conversation results in rich data)

•

Team Self Reported via Survey (Benefit – Scalable on very large programs)

Suggested Interval: •

Every Sprint – Ideal if enough Agile Coaching available

•

Every Release – Minimal recommended interval

Analyzing the Results Team level assessment Warning: This is not intended to determine “good” or “bad” teams.

This is a tool teams can use to come up with thoughtful ways during retrospective to improve the way the team works.

Compare overall results against goals aligned with overall Agile vision, •

Goal is Faster Time to Market BUT teams scoring low on Release Frequency

•

Goal is more Productivity BUT teams scoring low on Velocity

•

Goal is higher Quality BUT teams scoring low on Defect D efect Density

Provably Better Agile Teams

Becoming Ri (Hyper-Performing, Provably Better) Do Stage 3 Teams Exist? Caveat: Fewer than 5% of teams achieve Ri (Stage 3), and there is no average timeline for a team to achieve the highest stage.

Many factors must come together. These teams typically are: •

Stable in terms of staffing over time

•

Product Owner role cannot change on a project

•

Team is small; less than 10 people

•

Empowered to change its process

•

Incorporates the core values in their work

•

Bonding via a difficult challenge

•

Committed to shared success

•

Hungry to learn

•

Willing to accept change, and

•

Eager to experiment with new ideas

Stage 2 and 3 Benefits Higher Productivity 14%

88%

384%

Lower Costs 10%

26%

70%

Faster Time to Market 5%

10%

2 e g a t S

37%

Higher Quality 63%

3 e g a t S

64%

84%

Improved Job Satisfaction 52%

74%

92%

Improved Stakeholder Satisfaction 53%

78%

93%

Statistics quoted from QSMA, Rico, and DDJ in Succeeding with Agile , Mike Cohn , Jan 2010

Benefits of Stage 3

“RI”

Teams

Provably Better - We don’t just think we are outperforming waterfall, we have metrics to prove it. Hyper-productivity - The team will be able to produce quality software at an amazing rate enabling a faster time to market and lower IT costs. Extremely Efficient - The team will efficiently estimate, plan, execute and report progress and impediments.. “Ri”

Benefits

Higher Quality - Fewer defects will result from their work. Predictable and Consistent - Their velocity is well known, consistent, and range-bound, allowing for greater confidence in future delivery estimates. Improved Morale - Members want to work together more for the betterment of the team. Improved Stakeholder Satisfaction - Business sponsors working with these teams will enjoy working with the team.

Case Study of a Stage 3 (Ri) Team SirsiDynix 2005 – Distributed integrated Scrums that achieved a hyper-productive state

Results • • • • • •

A large enterprise project (56+ developers) run with distributed integrated Scrums was as productive as a small co-located Scrum team 8X more productive than a parallel project performed with Waterfall, resulting in “…more functionality functionality and higher quality.” quality.” Characteristics 2-week sprints, with a few use cases, but mostly user stories Teams in Provo, Utah and St Petersburg, Russia, with a few key individuals working from Seattle, Denver, St Louis and Waterloo, Canada Used Jira / Greenhopper ALM tool

Best Practices • • • • • •

Daily scrum team meetings from multiple sites Daily meetings of Product Owners Automated builds builds from fr om one central repository No distinction between team members at different sites Followed sound engineering practices constantly Seamless integration of some XP practices, refactoring, continuous integration, limited pair programming on most complex technical components

Thank you! Dan Fuller [email protected] May 21, 2014

Shu-Ha-Ri: Measuring Agile Adoption Maturity

Recommend Documents