Hans Samios' Personal Lean-Agile Knowledge Base

... absolutely #noabsolutes ...

User Tools

Site Tools

Trace: • difficulties_and_benefits_of_working_in_agile_environment • what_does_it_mean_to_be_done • what_are_the_steps_involved_in_an_initial_agile_assessment
what_does_it_mean_to_be_done

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
what_does_it_mean_to_be_done [2021/04/28 12:38] – Added in explicit discussion about quality and technical debt reduction hanswhat_does_it_mean_to_be_done [2021/04/28 12:45] (current) – [Who is Responsible for the Definition of Done?] hans
Line 14: Line 14:
 While this is important from a business perspective, the real benefit of the "potentially shippable" standard is that at any given time we know the status of the software and have low risk going forward because we have done all the work required in order to release our software. At many organizations I have worked at most of the (legacy systems and) software is not in this state and so part of this discussion is that we need to be working to get closer and closer to this state. While this is important from a business perspective, the real benefit of the "potentially shippable" standard is that at any given time we know the status of the software and have low risk going forward because we have done all the work required in order to release our software. At many organizations I have worked at most of the (legacy systems and) software is not in this state and so part of this discussion is that we need to be working to get closer and closer to this state.
  
-And finally, by leveraging the DoD we can establish a quality standard for the Team which helps ensure that we are not creating new Technical Debt as a result of the work we are doing, but also allows us to incrementally address the Technical Debt we already have in the code base. +And finally, by leveraging the DoD we can establish a quality standard for the Team which helps ensure that we are not creating new Technical Debt as a result of the work we are doing, and also allows us to incrementally address the Technical Debt we already have in the code base. 
  
 In summary, the "Definition of Done" (DoD) helps us: In summary, the "Definition of Done" (DoD) helps us:
Line 41: Line 41:
 > "Later = Never" - LeBlanc's Law > "Later = Never" - LeBlanc's Law
  
-By having a public Definition of Done we can help ensure that we are able to maintain our quality standard. The plan for the Iteration (Sprint) takes into consideration all the things that are part of the DoD and so we are able to complete quality work. After all:+By having a public Definition of Done we can help ensure that we are able to maintain our quality standard. The plan for the Iteration (Sprint) takes into consideration all the things that are part of the DoD and so we are able to complete quality work. It's up to us to ensure we don't add to the mess; we need to maintain our quality standards:
  
 > "A mess is not Technical Debt; a mess is just a mess" - Uncle Bob Martin > "A mess is not Technical Debt; a mess is just a mess" - Uncle Bob Martin
- 
-It's up to us to ensure we don't add to the mess; we need to maintain our quality standards. 
  
 We also know that left alone without care, existing code rots. Its kind of like entropy applied to code; if you don't apply effort to the code it will decay. The DoD can help here to. As part of the DoD we can think about an incremental approach to improving code. For example, perhaps our DoD includes the Boy Scout rule "Leave the code in better shape than when you found it." This allows you to do random acts of kindness to the code; if the naming of variables doesn't make the code easy to follow, fix them so it does; if it doesn't have an automated unit test, put one in; if it has a Cyclomatic Complexity above 21, refactor so it is less; and so on. Over time this kind incremental improvement will result in a code base that is easier to work on. We also know that left alone without care, existing code rots. Its kind of like entropy applied to code; if you don't apply effort to the code it will decay. The DoD can help here to. As part of the DoD we can think about an incremental approach to improving code. For example, perhaps our DoD includes the Boy Scout rule "Leave the code in better shape than when you found it." This allows you to do random acts of kindness to the code; if the naming of variables doesn't make the code easy to follow, fix them so it does; if it doesn't have an automated unit test, put one in; if it has a Cyclomatic Complexity above 21, refactor so it is less; and so on. Over time this kind incremental improvement will result in a code base that is easier to work on.
Line 53: Line 51:
 > "Make the change easy; then make the easy change." - Kent Beck > "Make the change easy; then make the easy change." - Kent Beck
  
-Or establish a working agreement whereby as you work an area of code and see something that need fixing you create a reference to the changes needed. Then the next time someone on the Team has to go into that code base, you ensure that the estimate that you provide to do the work also include the work required to fix the area.+Or establish a working agreement whereby as you work an area of code and see something that needs fixing, you create a reference and estimate the changes needed. Then, the next time someone on the Team has to go into that code base, you ensure that the estimate that you provide to do the new work also includes the work required to fix the existing problems.
  
 No matter what, do not underestimate the impact of incremental improvements - see [[how_do_small_changes_lead_to_big_improvements|How Do Small Changes Lead to Big Improvements?]] for more information. No matter what, do not underestimate the impact of incremental improvements - see [[how_do_small_changes_lead_to_big_improvements|How Do Small Changes Lead to Big Improvements?]] for more information.
Line 72: Line 70:
   - Agile Team: Things the team learns it needs, especially at a technical level   - Agile Team: Things the team learns it needs, especially at a technical level
  
-Teams have a known, public DoD. Teams are explicit both in being visible about their DoD (available on the Scrum Team's page). They are also transparent about the practice they use to ensure their Definition of Done is addressed. It is up to the team to determine their approach.+Teams have a known, public DoD. Teams are explicit both in being visible about their DoD (for example, available on the Team's page). They are also transparent about the practice they use to ensure their Definition of Done is addressed. It is up to the team to determine their approach.
  
 Example approaches we have seen include: Example approaches we have seen include:
  
-  * Teams create tasks associated with their definition of done so that when the sub-tasks are done, the story is done.+  * Teams create tasks associated with their DoD so that when the sub-tasks are done, the story is done.
   * Teams maintain a spreadsheet and check-off the definition of done at the end of the Sprint.   * Teams maintain a spreadsheet and check-off the definition of done at the end of the Sprint.
   * Teams create a task that is the Definition of Done checklist that is updated as work proceeds on the story   * Teams create a task that is the Definition of Done checklist that is updated as work proceeds on the story
/home/hpsamios/hanssamios.com/dokuwiki/data/attic/what_does_it_mean_to_be_done.1619638686.txt.gz · Last modified: 2021/04/28 12:38 by hans