Upload
rseniv
View
1.028
Download
6
Embed Size (px)
DESCRIPTION
how to assess and measure the agility of projects and teams
Citation preview
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?