Your SlideShare is downloading. ×
0
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Assessing youragility
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Assessing youragility

1,022

Published on

how to assess and measure the agility of projects and teams

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,022
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
32
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. Rostyslav Seniv<br />February 5, 2011<br />Assessing Your Agility<br />
    • 2. Assessing Your Agility<br />
    • 3. Agenda<br />Process Assessment<br />Metrics<br />Working Environment<br />Abiliton Agile<br />
    • 4. What’s the Agility?!<br />
    • 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. 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. 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. 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. 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. Assessment dimensions<br />Assessment checklist<br />Dimensions<br />Characteristics<br />Questions<br />We use ten dimensions<br />
    • 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. Sample Assessment<br />
    • 13. Team structure<br />Cross Functional<br />Self-organizing<br />Roles<br />Acting as a team<br />Collocation <br />
    • 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. 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. 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. 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. 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. 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. 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. Sample Assessment<br />
    • 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. Measuring your agility<br />Why to measure<br />What to measure<br />What not to measure<br />Analyze<br />
    • 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. 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. What not to measure<br />Individual performance<br />Business value as productivity<br />Source lines of code<br />Velocity to compare teams<br />
    • 27. Velocity Variance<br />Current Sprint velocity vs. Last 5/7 Median Average Velocity<br />
    • 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. 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. Technical Debt<br />Story A is a complex story touching each tier of the application<br />
    • 31. Sample measurement report<br />
    • 32. Tools and working conditions<br /><ul><li>No specific tools but specific areas should be covered by tools
    • 33. Tools should exist
    • 34. Working conditions should be cool
    • 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. Is applied to collaborative environments, accounting for time-zone, geographical distribution and cultural differences
    • 37. Is adapted for client-consultant relationships</li></ul>Organizational Support for Agile Projects<br />Resulting in hyper-productive software development<br />
    • 38. <ul><li> Guarantees stability and predictability of reaching project goals
    • 39. People, Process, Process Performance, Environment and Tools verified
    • 40. 75% team members trained and passed internal exam. SM and PO are externally Certified.
    • 41. All dimensions are above 70%. Metrics are within baselines.
    • 42. Appropriate tools and working conditions validated.
    • 43. Has validity period and is renewed
    • 44. Periodic assessments for all Agile projects and collaboration with clients on assessment results
    • 45. Collaboration with clients on project start
    • 46. Consultancy and coaching to team members
    • 47. Consultancy projects for the clients
    • 48. Based on Scrum
    • 49. Invokes advanced Agile practices
    • 50. Optimized for collaborative environment
    • 51. Created and enhanced in collaboration with industry experts
    • 52. SoftServe University based SM and PO trainings
    • 53. Internal exam (more comprehensive than Certified one)
    • 54. On-demand trainings, conferences, webinars offered</li></ul>Abiliton Agile<br />
    • 55. Questions?<br />

    ×