Agile Adoption Patterns

as possible to deployment. This will weed  out most of the errors and increase your confidence in the teams true progress. Your team should be consistent, so  agree on what it means to really be done; this is the done state. Your goal for each iteration will be to take each  requirement to completion as defined by the done state. Finally, a done state is binary. Either it is met or it is not; there is no partial credit. If a requirement doesn't meet its done state at the end of an iteration, it goes back onto the  backlog.

Adoption

Be aggressive in setting your done state as close as possible to deployment, but also be realistic. Your done state has to be something you can meet in the coming Iteration

• Agree on your done state before the start of your first Iteration. Work to get commitment from team members; the whole team will have to work to get a requirement all the way through to your definition of done. Remember, a done state is a goal; therefore, it needs to be S.M.A.R.T. (specific, measurable, achievable, relevant, and timely).
• The done state should push your team members without breaking them.
• Expect getting to the done state to be painful initially. If your team consistently fails to meet the goals of the Iteration, use your retrospective to address the issue. Look to fixing other things before scaling back the done state.
• Revisit your done state in your retrospectives when your team is comfortable meeting them. Try to push your done state closer to deployment.

The done state is an important part of having successful iterations. If the done state is set too low, your team wont see the benefits; if its set too high, your team will feel the pain and get discouraged.

• A common occurrence is that teams fail to get through acceptance testing because developers complete their work near the end of the iteration and dont have enough time to do full acceptance testing and fix errors that arise. It will be tempting to scale back the done state, but consider working on requirements in series instead of in parallel. That is, don't start working on all the requirements at once, but take a few at a time and work to complete them—using Pair Programming to help—and then go on to the next requirements when those that you are working on have reached their done state.
• If your team is not a cross-functional team, it will be difficult to get close to deployment.
  • If at all possible, go to cross-functional teams.
  • If it is not possible, your done state can go only as far as building, testing, and integrating the particular piece your team is working on. At the same time, plan for teams to be done with their interlocking parts as soon as possible for integration feedback.
• If your done state is too lax—that is, it does not include integration and acceptance testing—your Iterations will be dysfunctional. Your team will miss many defects that will have to be fixed later at a higher cost. Important feedback will be missed.
• If you have a customer who places a high value on look and feel and more subjective qualities like usability, it will be important to leave time in the iteration for the back and forth with the customer to finetune and reach the done state.
• Some teams decide to have two done states —one for developers and done for the QA team. Therefore, a task is coded in one iteration and tested in the next. This usually creates a