How to be proud when you are done

8,209 views

Published on

Presentation from AgileEE conference (Kiev, october 2010) and AgileDays’11 (Moscow, March 2011) about Definition of Done.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
8,209
On SlideShare
0
From Embeds
0
Number of Embeds
2,520
Actions
Shares
0
Downloads
63
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

How to be proud when you are done

  1. How to be proud when you are done<br />
  2. Mikalai Alimenkou<br /><ul><li>Java Technical Lead/Scrum Master at Zoral Labs
  3. 6+ years in software development
  4. 4+ years of working by Agile methodologies
  5. Expert in Agile engineering practices
  6. Agile coach at XP Injection</li></ul>Aleksey Solntsev<br /><ul><li>Architect at Infopulse Ukraine
  7. Agile volunteer
  8. Certified Scrum Practitioner
  9. Coordinator of translation of the book "Scrum and XP from the Trenches" and “Kanban and Scrum – making the most of both” into Russian
  10. Agile coach at XP Injection</li></li></ul><li>Everybody has own “dreams”<br /><ul><li>Latest frameworks
  11. No overtimes
  12. No bug fixing
  13. Clean code
  14. More features
  15. In time delivery
  16. No defects!</li></ul>Manager<br /><ul><li>Goal achievement
  17. Predictable plans
  18. On budget</li></ul>Team<br />Customer<br />
  19. What all of them have in common?<br />With fast delivery<br />And good quality<br />Done product<br />At low price<br />
  20. Why in real life it is not so simple?<br />Whhhyyyy?!!!<br />
  21. “Uncommitted stuff”<br />Can I start testing this new feature?<br />Yes, it is done!<br />But I can’t even build the product…<br />Ops, I forgot to commit some files...<br />
  22. “Useless build”<br />Well done! Let’s deploy new build on production server.<br />Not so fast. We need to do integration testing, prepare DB migration scripts, etc. I hope it will be finished in a week.<br />???<br />
  23. “Unstable velocity”<br />Well done! Our velocity in the last iteration increased up to 32SP. Let’s use it as base line.<br />Agree, but we have to make some small fixes, finish testing and update documentation.<br />How will it change <br />our velocity?<br />Let’s say 20.<br />
  24. “Unverified tasks”<br />WTF! A new order form is nightmare. It looks like random set of fields and doesn’t accept basic values.<br />Have somebody tried to use it before assign to me?<br />Don’t panic! I just made a quick fix…<br />
  25. “Forgotten requirements”<br />Guys, as we discussed on the planning meeting, we’ve just started pre-orders program for iPad2. And now our site is extremely slow.<br />John, have you made load and performance testing?<br />Well, but …<br />
  26. Why this happens?<br />Whhhyyyy?!!!<br />
  27. Hidden conflicts in goals<br />Developers like always implementing interesting features, but customers want working software<br />Team want to show productivity, but customers want predictability<br />Developers believe they are perfect, but customers want software without defects<br />Management want to deliver in time, but customers want ready to use software<br />Developers see technical side of the project, but customers see it from end users perspective<br />
  28. And the main reason is …<br />Everybody has his own definition of words ‘done’, ‘fast’, ‘low price’, ‘good quality’! <br />
  29. Let’s start from definition<br />“Definition of Done” is<br /><ul><li>a "contract" between all parties on subject when …
  30. a checklist of valuable activities for …
  31. gates your product has to go through before …</li></ul>… you can label the product “Done“<br />
  32. 4<br />mainquestions<br />
  33. How to start?<br />Take from previous project<br />From code quality in mind<br />From business problems and wishes<br />
  34. Start from flow visualization<br />Image from HenrikKniberg book “Scrum and Kanban - making the most of both”<br />
  35. Who should define?<br />Customer<br />Team<br />
  36. When to define?<br />
  37. Where to store?<br />Electronic<br />More<br />common<br />More <br />personal<br />Paper<br />
  38. 3<br />main formats<br />
  39. Plain list<br />
  40. Different levels of granularity<br />
  41. List categorized by level<br />
  42. Complex structure<br />
  43. 3<br />main control principles<br />
  44. Automation<br />Use SVN hook for verify comments in commits<br />Add static analyzer to build<br />
  45. Fixed workflow<br />Task tracking system can help<br />Review<br />Fix and document<br />workflow<br />
  46. Responsible persons<br />Manager<br />Team Lead<br />
  47. How does it work<br /> in real world<br />
  48. Binary state<br />Not done<br />Will be done<br />In progress<br />Nearly done<br />Done<br />
  49. Depends on context<br />End of sprint 1<br />End of sprint 2<br />End of sprint 3<br />week 1<br />week 2<br />week 3<br />week 4<br />week 5<br />week 6<br />week 7<br />week 8<br />End of iteration 1<br />Start of stabilization<br />End of project<br />week 1<br />week 2<br />week 3<br />week 4<br />week 5<br />week 6<br />week 7<br />week 8<br />Traditional <br />approaches<br />PM: Are tasks done?<br />Devs: No.<br />PM: OK, go on. But don’t <br /> forget about new features.<br />PM: Done?<br />Devs: We hope so.<br />End of project<br />Scrum<br />PM: Done?<br />Devs: Yes.<br />PM: Done?<br />Devs: No yet.<br />End of project<br />week 1<br />week 2<br />week 3<br />week 4<br />week 5<br />week 6<br />week 7<br />week 8<br />Kanban<br />PM: Done?<br />Devs: Of course!<br />PM: Done?<br />Devs: Of course!<br />
  50. 7<br />main problems<br />
  51. No common understanding<br />
  52. No commitment<br />
  53. Unrealistic<br />
  54. Too ideal<br />
  55. Partially done tasks are accepted<br />Done?<br />
  56. "Broken windows" principle<br />
  57. “Development” only<br />
  58. Let’s try to build Definition of Done!<br />
  59. Conclusions<br />Common vocabulary <br />helps us to avoid hidden <br />conflicts …<br />… and work together as a <br />team to archive our goals! <br />
  60. Introduce “Definition of Done” ASAP to avoid broken expectations<br />All parties must take part in definition process<br />Automate as much as possible<br />Don't lie yourself, DONE means DONE<br />Learn from your mistakes<br />Inspect and adapt continuously<br />
  61. Q&A<br />Email us:<br />mikalai.alimenkou@xpinjection.com<br />aleksey.solntsev@xpinjection.com<br />

×