Rostyslav Seniv<br />February 5, 2011<br />Assessing Your Agility<br />
Assessing Your Agility<br />
Agenda<br />Process Assessment<br />Metrics<br />Working Environment<br />Abiliton Agile<br />
What’s the Agility?!<br />
Why to assess<br />Identify gaps in the process<br />To have a discussion<br />To transfer knowledge<br />To share practic...
Nokia Scrum Test<br />Iterations must be time-boxed to less than six weeks / Do your sprints start and end on planned date...
Assessing through surveys<br />Good to gather the data quickly<br />No discussion<br />No feedback<br />Require specific q...
Question types<br />Yes-no or specific (closed)<br />Simpler<br />Good as a pocket guide<br />Faster <br />Do not discover...
Our assessment method<br />Face-to-face discussion<br />Open questions<br />Mark and Importance<br />2.5h-3h in quick mode...
Assessment dimensions<br />Assessment checklist<br />Dimensions<br />Characteristics<br />Questions<br />We use ten dimens...
Assessment dimensions<br />Team Structure<br />Requirements Management<br />Release Planning<br />Iteration Planning<br />...
Sample Assessment<br />
Team structure<br />Cross Functional<br />Self-organizing<br />Roles<br />Acting as a team<br />Collocation <br />
Requirements Management<br />Backlog writing<br />	in JiT/JE manner<br />Backlog items writing<br />	in JiT/JE manner<br /...
Release Planning<br />Backlog sizing<br />The meeting, values, re-sizing<br />Velocity usage<br />Release Burndown Chart U...
Iteration Planning<br />Sprint Planning ceremony<br />Pre-planning activities<br />Sprint backlog creation<br />Task assig...
Engineering Practices<br />TDD and Unit Testing<br />Continuous Integration<br />Distributer parallel build systems<br />C...
QA and Acceptance<br />Definition of Done<br />Acceptance Criteria<br />Sprint Review<br />Automated Testing<br />Manual T...
Continuous Learning and Improvements<br />Retro<br />Problem Solving<br />Root Cause Analysis<br />Willingness to Learn<br...
Cooperation and Collaboration in Distributed Settings<br />Unified process across teams<br />Daily Scrums<br />same time s...
Sample Assessment<br />
Assessment Report<br />Comes with detailed description of current process<br />Gaps and areas for improvements identified<...
Measuring your agility<br />Why to measure<br />What to measure<br />What not to measure<br />Analyze<br />
Why to measure<br />To identify gaps in the process<br />To improve processes<br />To ensure predictability of the project...
What to measure<br />Attributes<br />Team size over time<br />Team members contribution<br />Sprint length<br />Velocity v...
What not to measure<br />Individual performance<br />Business value as productivity<br />Source lines of code<br />Velocit...
Velocity Variance<br />Current Sprint velocity vs. Last 5/7 Median Average Velocity<br />
Cycle time<br />Lead Time (In Sprint Cycle Time)<br />Days or % of Sprint Length<br />Completed minus started<br />Shorter...
Technical Debt<br />Metaphor developed by Ward Cunningham<br />Complex metric which is hard to measure<br />High-Low makes...
Technical Debt<br />Story A is a complex story touching each tier of the application<br />
Sample measurement report<br />
Tools and working conditions<br /><ul><li>No specific tools but specific areas should be covered by tools
Tools should exist
Working conditions should be cool
No walls, hardware available, whiteboard etc</li></li></ul><li><ul><li>    A fully optimized iterative and incremental </l...
Upcoming SlideShare
Loading in …5
×

Assessing youragility

1,248 views

Published on

how to assess and measure the agility of projects and teams

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,248
On SlideShare
0
From Embeds
0
Number of Embeds
233
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • Здатність швидко реагувати на перешкоди, швидкість і тд. Відповідність принципам Еджайл, що є гнучкістю і здантістю реагувати на перешкоди. Скрам взятий як ядро
  • При такій розмові люди часто самі запропонують відповіді
  • Video linkLunch together
  • PO:Team members to think about the next day few days
  • Enhanced burndown shocked the customer
  • both pre-assignment and using pool of tasks make a sense
  • Dev + QA pairing before checkins
  • Self-testable Acceptance Criteria
  • Willingness to Lean
  • Trips almost just as motivation
  • checklist
  • checklist
  • Color coding
  • Assessing youragility

    1. 1. Rostyslav Seniv<br />February 5, 2011<br />Assessing Your Agility<br />
    2. 2. Assessing Your Agility<br />
    3. 3. Agenda<br />Process Assessment<br />Metrics<br />Working Environment<br />Abiliton Agile<br />
    4. 4. What’s the Agility?!<br />
    5. 5. Why to assess<br />Identify gaps in the process<br />To have a discussion<br />To transfer knowledge<br />To share practices<br />To compare your team to other teams<br />To improve – or inspect and adopt<br />Por qué? Why?Чому? Dlaczego?Почему?Чаму?<br />
    6. 6. Nokia Scrum Test<br />Iterations must be time-boxed to less than six weeks / Do your sprints start and end on planned dates<br />Is the software completely tested and working at the end of an iteration<br />Can the iteration start before specification is complete<br />
    7. 7. Assessing through surveys<br />Good to gather the data quickly<br />No discussion<br />No feedback<br />Require specific questions<br />Do not discover hidden issues<br />Good as a team practice<br />There is good survey from Mike Cohn at http://comparativeagility.com<br />
    8. 8. Question types<br />Yes-no or specific (closed)<br />Simpler<br />Good as a pocket guide<br />Faster <br />Do not discover hidden issues<br />Areas to discover (open)<br />Time-consuming<br />Explores the process<br />Deals with creativity and innovation<br />People finds answers by themselves<br />
    9. 9. Our assessment method<br />Face-to-face discussion<br />Open questions<br />Mark and Importance<br />2.5h-3h in quick mode<br /> Detailed assessment requires assessor to attend all the ceremonies and have additional meetings with the project team<br />
    10. 10. Assessment dimensions<br />Assessment checklist<br />Dimensions<br />Characteristics<br />Questions<br />We use ten dimensions<br />
    11. 11. Assessment dimensions<br />Team Structure<br />Requirements Management<br />Release Planning<br />Iteration Planning<br />Engineering Practices<br />QA and Acceptance<br />Continuous Learning and Improvements<br />Cooperation and Collaboration<br />Distributed Settings<br />General<br />
    12. 12. Sample Assessment<br />
    13. 13. Team structure<br />Cross Functional<br />Self-organizing<br />Roles<br />Acting as a team<br />Collocation <br />
    14. 14. Requirements Management<br />Backlog writing<br /> in JiT/JE manner<br />Backlog items writing<br /> in JiT/JE manner<br />Backlog prioritization<br />Product Owner Responsiveness<br />Scalability of Product Ownership<br />Cross team dependency tracking<br />Single backlog for depending teams<br />SoS<br />
    15. 15. Release Planning<br />Backlog sizing<br />The meeting, values, re-sizing<br />Velocity usage<br />Release Burndown Chart Usage<br />Release Planning culture<br />Projection vs. Planning<br />Long term commitments vs. indication<br />
    16. 16. Iteration Planning<br />Sprint Planning ceremony<br />Pre-planning activities<br />Sprint backlog creation<br />Task assignment<br />Sprint scope changes<br />Commitment<br />Using Track Task Done approach<br />for (int i=Sprint_Zero; i < Will_Define_Later; i++) {<br />team.plan_Iteration(everything_Team_Needs, i,product_Owner, pizza, backlog, list_Of_Other_Things);<br />...<br />
    17. 17. Engineering Practices<br />TDD and Unit Testing<br />Continuous Integration<br />Distributer parallel build systems<br />CI lamps<br />Peer Review<br />Pair Programming<br />Refactoring<br />Coding Standards<br />Collective Code Ownership<br />
    18. 18. QA and Acceptance<br />Definition of Done<br />Acceptance Criteria<br />Sprint Review<br />Automated Testing<br />Manual Testing<br />Dev doing QA work (cultural aspect)<br />Dealing with defects<br />
    19. 19. Continuous Learning and Improvements<br />Retro<br />Problem Solving<br />Root Cause Analysis<br />Willingness to Learn<br />Knowledge sharing<br />Process refinements<br />
    20. 20. Cooperation and Collaboration in Distributed Settings<br />Unified process across teams<br />Daily Scrums<br />same time same location<br />Collaboration tools<br />Impediments<br />Scrum of Scrum<br />Trips<br />Phone, Video, IM<br />Distribution strategy<br />Proxies<br />
    21. 21. Sample Assessment<br />
    22. 22. Assessment Report<br />Comes with detailed description of current process<br />Gaps and areas for improvements identified<br />Recommendations broken down into categories:<br />Knowledge<br />Immediate<br />Short term<br />Longer term<br />
    23. 23. Measuring your agility<br />Why to measure<br />What to measure<br />What not to measure<br />Analyze<br />
    24. 24. Why to measure<br />To identify gaps in the process<br />To improve processes<br />To ensure predictability of the project<br />To ensure agility<br />
    25. 25. What to measure<br />Attributes<br />Team size over time<br />Team members contribution<br />Sprint length<br />Velocity variance<br />Cycle time<br />Technical debt<br />Post sprint defect arrival<br />Root cause fixed defects<br />Bug fixing to implementation time<br />
    26. 26. What not to measure<br />Individual performance<br />Business value as productivity<br />Source lines of code<br />Velocity to compare teams<br />
    27. 27. Velocity Variance<br />Current Sprint velocity vs. Last 5/7 Median Average Velocity<br />
    28. 28. Cycle time<br />Lead Time (In Sprint Cycle Time)<br />Days or % of Sprint Length<br />Completed minus started<br />Shorter is better<br />Indicator of productivity and predictability<br />
    29. 29. Technical Debt<br />Metaphor developed by Ward Cunningham<br />Complex metric which is hard to measure<br />High-Low makes the most sense<br />Quick and Dirty approaches produce more debt<br />Should be paid back<br />Has significant impact on velocity<br />
    30. 30. Technical Debt<br />Story A is a complex story touching each tier of the application<br />
    31. 31. Sample measurement report<br />
    32. 32. Tools and working conditions<br /><ul><li>No specific tools but specific areas should be covered by tools
    33. 33. Tools should exist
    34. 34. Working conditions should be cool
    35. 35. No walls, hardware available, whiteboard etc</li></li></ul><li><ul><li> A fully optimized iterative and incremental </li></ul> methodology for project management and <br /> software development.<br /><ul><li> Incorporates a superior framework of services </li></ul> and solutions to deliver maximum value for <br /> each project.<br /><ul><li>Combines industry best practices from Agile and Scrum
    36. 36. Is applied to collaborative environments, accounting for time-zone, geographical distribution and cultural differences
    37. 37. Is adapted for client-consultant relationships</li></ul>Organizational Support for Agile Projects<br />Resulting in hyper-productive software development<br />
    38. 38. <ul><li> Guarantees stability and predictability of reaching project goals
    39. 39. People, Process, Process Performance, Environment and Tools verified
    40. 40. 75% team members trained and passed internal exam. SM and PO are externally Certified.
    41. 41. All dimensions are above 70%. Metrics are within baselines.
    42. 42. Appropriate tools and working conditions validated.
    43. 43. Has validity period and is renewed
    44. 44. Periodic assessments for all Agile projects and collaboration with clients on assessment results
    45. 45. Collaboration with clients on project start
    46. 46. Consultancy and coaching to team members
    47. 47. Consultancy projects for the clients
    48. 48. Based on Scrum
    49. 49. Invokes advanced Agile practices
    50. 50. Optimized for collaborative environment
    51. 51. Created and enhanced in collaboration with industry experts
    52. 52. SoftServe University based SM and PO trainings
    53. 53. Internal exam (more comprehensive than Certified one)
    54. 54. On-demand trainings, conferences, webinars offered</li></ul>Abiliton Agile<br />
    55. 55. Questions?<br />

    ×