assessing youragility

Rostyslav SenivFebruary 5, 2011

Assessing Your Agility

Assessing Your Agility

Agenda

Process Assessment Metrics Working Environment Abiliton Agile

What’s the Agility?!

Why to assess

Identify gaps in the process To have a discussion To transfer knowledge To share practices To compare your team to other teams To improve – or inspect and adopt

Por qué? Why? Чому? Dlaczego? Почему?

Чаму?

Nokia Scrum Test

Iterations must be time-boxed to less than six weeks / Do your sprints start and end on planned dates

Is the software completely tested and working at the end of an iteration

Can the iteration start before specification is complete

Assessing through surveys

Good to gather the data quickly No discussion No feedback Require specific questions Do not discover hidden issues Good as a team practice

There is good survey from Mike Cohn at http://comparativeagility.com

Question types

Yes-no or specific (closed)– Simpler– Good as a pocket guide– Faster – Do not discover hidden issues

Areas to discover (open)– Time-consuming– Explores the process– Deals with creativity and innovation– People finds answers by themselves

Our assessment method

Face-to-face discussion Open questions Mark and Importance 2.5h-3h in quick mode

Detailed assessment requires assessor to attend all the ceremonies and have additional meetings with the project team

Assessment dimensions

Assessment checklist Dimensions Characteristics Questions

We use ten dimensions

Assessment dimensions

Team Structure Requirements Management Release Planning Iteration Planning Engineering Practices QA and Acceptance Continuous Learning and Improvements Cooperation and Collaboration Distributed Settings General

Sample Assessment

Team structureRequirements Management

Release Planning

Iteration Planning

Engineering Practices

Quality Assurance and Acceptance

Continuous Learning and Improvements

Cooperation and Collaboration

Distributed Settings

General Practices and Values

0%

50%

100%

Desired

Agility Index

Team structure

Cross Functional Self-organizing Roles Acting as a team Collocation

Requirements Management

Backlog writingin JiT/JE manner

Backlog items writingin JiT/JE manner

Backlog prioritization Product Owner Responsiveness Scalability of Product Ownership Cross team dependency tracking

– Single backlog for depending teams– SoS

Release Planning

Backlog sizing– The meeting, values, re-sizing

Velocity usage Release Burndown Chart Usage Release Planning culture

– Projection vs. Planning– Long term commitments vs. indication

Iteration Planning

Sprint Planning ceremony Pre-planning activities Sprint backlog creation Task assignment Sprint scope changes Commitment Using Track Task Done approach

for (int i=Sprint_Zero; i < Will_Define_Later; i++) { team.plan_Iteration(everything_Team_Needs, i, product_Owner, pizza, backlog, list_Of_Other_Things);...

Engineering Practices

TDD and Unit Testing Continuous Integration

– Distributer parallel build systems– CI lamps

Peer Review Pair Programming Refactoring Coding Standards Collective Code Ownership

QA and Acceptance

Definition of Done Acceptance Criteria Sprint Review Automated Testing Manual Testing Dev doing QA work (cultural aspect) Dealing with defects

Continuous Learning and Improvements Retro Problem Solving

– Root Cause Analysis Willingness to Learn Knowledge sharing Process refinements

Cooperation and Collaboration in Distributed Settings Unified process across teams Daily Scrums

– same time same location Collaboration tools Impediments Scrum of Scrum Trips Phone, Video, IM Distribution strategy Proxies

Sample Assessment

Team structureRequirements Management

Release Planning

Iteration Planning

Engineering Practices

Quality Assurance and Acceptance

Continuous Learning and Improvements

Cooperation and Collaboration

Distributed Settings

General Practices and Values

0%

50%

100%

Desired

Agility Index

Waterfall

Waterscrum

Assessment Report

Comes with detailed description of current process

Gaps and areas for improvements identified Recommendations broken down into categories:

– Knowledge– Immediate– Short term– Longer term

Measuring your agility

Why to measure What to measure What not to measure Analyze

Why to measure

To identify gaps in the process To improve processes To ensure predictability of the project To ensure agility

What to measure

Attributes– Team size over time– Team members contribution– Sprint length

Velocity variance Cycle time Technical debt Post sprint defect arrival Root cause fixed defects Bug fixing to implementation time

What not to measure

Individual performance Business value as productivity Source lines of code Velocity to compare teams

Velocity Variance

Current Sprint velocity vs. Last 5/7 Median Average Velocity

N Velocity Average Variance1 20 202 30 25 50%3 25 25 0%4 30 26.25 20%5 20 25 24%6 33 26.33 32%7 24 25.8 9%8 19 26% 1 2 3 4 5 6 7 8

0

10

20

30

40

50

60

VelocityVariance

Cycle time

Lead Time (In Sprint Cycle Time) Days or % of Sprint Length Completed minus started Shorter is better Indicator of productivity and

predictability

Technical Debt

Metaphor developed by Ward Cunningham Complex metric which is hard to measure

– High-Low makes the most sense Quick and Dirty approaches produce more debt Should be paid back Has significant impact on velocity

Technical Debt

1 2 3 4 5 6 7 80

5

10

15

20

25

30

35

Cost of Story ACost Sprint 3Cost Sprint 8

Created debt

Story A is a complex story touching each tier of the application

Sample measurement report

Metric Baseline Current AgilityTeam Size 7+-2 7 ExcellentSprint Length 2, 3 2 ExcellentTask Estimate 1d - 1.5d 1d Excellent

Team member contribution >75% per team 100 ExcellentVelocity Variance <25% 15% High

Cycle Time 1/4 SL - 1/2 SL 1/3 HighTechnical Debt Low Medium MediumPost Sprint Defects Arrival <10% 15% MediumEarned Value >90% avg 90% HighIn Sprint Work in Progress <TS + 50% TS + 20% HighRoot Cause Fixed Defects >90% 98% High

Above High

Tools and working conditions

No walls, hardware available, whiteboard etc

No specifi c tools but

specifi c areas should be

covered by toolsTools should existWorking conditions should be cool

• A fully optimized iterative and incremental methodology for project management and software development.

• Incorporates a superior framework of services and solutions to deliver maximum value for each project.

• Combines industry best practices from Agile and Scrum

• Is applied to collaborative environments, accounting for time-zone, geographical distribution and cultural differences

• Is adapted for client-consultant relationships

Organizational Support for Agile Projects

Resulting in hyper-productive software development

Abiliton Agile Framework Teams Training

Projects Assessment and

Consultancy

Abiliton Agile Certified Project

• Guarantees stability and predictability of reaching project goals

• People, Process, Process Performance, Environment and Tools verified

• 75% team members trained and passed internal exam. SM and PO are externally Certified.

• All dimensions are above 70%. Metrics are within baselines.

• Appropriate tools and working conditions validated.

• Has validity period and is renewed

• Periodic assessments for all Agile projects and collaboration with clients on assessment results

• Collaboration with clients on project start

• Consultancy and coaching to team members

• Consultancy projects for the clients

0%

50%

100%

• Based on Scrum

• Invokes advanced Agile practices

• Optimized for collaborative environment

• Created and enhanced in collaboration with industry experts

• SoftServe University based SM and PO trainings

• Internal exam (more comprehensive than Certified one)

• On-demand trainings, conferences, webinars offered

Abiliton Agile

Questions?