Disclaimer: text below is compilation of notes I made on Agileee 2010 conference, listening to different speakers. I do it to keep knowledge I got on conference, share it with my colleagues and anyone else who interested. It is only about how I heard, interpret, write down the original speech. It also includes my subjective opinion on some topics. So it could not 100% reflects author opinion and original ideas.
The speech by two guys for XPInjection.com who shared they knowledge on such important Agile concept of Done. I was really interested in this speech since this is something that we also trying to use as common practice in our company.
Software development involves a lot people: developers, customers, management. And everybody has own “dreams” (or goals). Such differentiation of goals could lead to hidden (or opened) conflicts, misunderstanding of business and development, wrong communication and as a result - failure of project. But if we try to look it with another prospective, everybody is actually have one goal - delivery of product. Developers happy to see their work done, managers happy to see it is in budget and met customer criteria’s and so on. So in general everybody has one common goal.
The way of managing one common understanding is the way of creation of Definition Of Done (DOD).
Developer declare work as done, but sources are not committed to SCM. Developers definition of done - it works on my machine.
Customer said - let’s deploy on production. Developer said - we still have a lot stuff to work on, merge, tests, DB migration scripts etc. Customer Done is different.
Customer - Well done, our velocity increased to 32 SP, let’s used for next fixed. Master - I have a lot small bugs to , documentation. Customer - how we change our velocity. Master - let’s say it is 20. Developers lack understanding of done.
Customer - there is a crash on form, have somebody tried to work before me. Developers - oops, it was quick fix, haven’t tested it well. I’ll just do another quick fix for that.
Customer - my site is very slow, let’s discuss it on next meeting. Master - who did the performance testing? Aaaa.. no body. Non functional requirements are forgotten.
Definition of Done: is a contract (number of rules) between different parties of how to treat particular actives state of completeness.
If you decided to start with with DOD, you need some initial guidelines of implementation, what should you do to “define” DOD?
The process of creation of DOD is brainstorming, you have to understand your need, you problems, your goals to create DOD.
Team + Customer have to decide on definition of done.
What usually happens, as for me, that DOD is created by Team only, because customer (or PO) is not really exited to do that, so this activity is usually skipped, but only understands the importance and consequences in case of major project issues. That’s why it is Scum Master job to involve customers (PO’s) as much as possible.
Ideally at the start of the project. But in case of something wrong, you have to stop and re-implement definition of done, to prevent the problem. Retrospective is good time for changing DOD.
Definition of done is document. Electronic versions is stored in SCM, on wiki site. Printed version have to be ‘before eyes’ of Team/SM/PO. It is a good idea to put a copy near board, so everyone sees it on stand-up meeting etc.
DOD could not cover all aspects of project. So it have to be granulated. DOF for Release, DOD Iteration, DOF for feature, DOF for task and so on.
Automate everything you can - of possible try to automate rules from DOF (like using a hook in SVN to control comment). Add static analyzer to build (code quality).
Define a workflow in issue tracking system. As code review: workflow have to be changed to make a ‘Code review’ as mandatory state.
Execution of DOD is not possible without responsible persons. Scrum Master (person responsible for process), Team Leader, QA. It should be one person!