Definition of Done

The Definition of Done is a key aspect of Agile done right. It is one of the critical aspects of Agile development and unless a team or organization has defined and understood what Done means for them, they will not be as successful as they could be.

Scott Downey, MySpace Agile Coach, has a Definition of Done that includes:

• Feature Complete
  
• Code Complete
  
• No Known Defects
  
• Approved by the Product Owner
  
• Production Ready

Based this list, here are some ideas I've compiled that attempts to describe what this looks like for an Agile team in general.

Feature Complete – The short definition of Feature Complete is that all the intended stories and associated tasks are completed that will enable the business value that was intended for that iteration. There may be some stability, performance, or bug fixing work yet to be done before being production ready. It would indicate that Stories and Conditions of Satisfaction are complete and understood, any analysis and necessary design is complete, environments have been setup for development and production, the code has been written and unit tested, functional test cases are written and understood. Necessary documentation for support staff and customer service has been completed. Deployment and risk mitigation understood.

Code Complete – Code is considered complete at the point where the development tasks for the sprint are completed. This would mean any necessary refactoring is done, TODO’s have been completed, code has been checked in, testing in integration has been completed, bugs fixed, and merged as necessary. It could include automated review, peer review, code coverage reviewed, and build ready to go.

No Known Defects – No defects that were created during the sprint are remaining. There may be unknown bugs, bugs in other parts of the software, bugs left from previous technical debt/legacy code, but the bugs created and found during the sprint have been addressed. It may also mean that any defects that are discovered in the section of code being worked on are also fixed, depending on the time necessary and approval from the Product Owner and the team. Pre-release builds/deploys have been created and validated.

There will be times when we purposely choose not to fix something (created during the sprint) however that should be the exception rather than the rule. Remember that not fixing a defect is creating technical debt that is highly likely going to cost us more if we have to come back to fix it later. The teams need to make sure that they aren’t over committing to stories to ensure that they have time to get what they commit to, triple done. This might reduce the velocity in the beginning, but as the team gets better at only biting off what they can chew (plus maybe a small stretch goal), they will become more highly performing and able to gain back that velocity and much more.

Approved by the Product Owner – The User Story conditions of satisfaction are completely met. The prototypes/mockups are reproduced to the satisfaction of the Product Owner. The Product Owner has received necessary approval from business stakeholders. Functionality has been demonstrated live to the Product Owner. Any other issues brought up by the Product Owner have a plan around them and the PO understands exactly what is going to production and what is not.

Production Ready – System is able to be deployed without adverse affects to the customer or other parts of the system. Functional, regression, performance, security, and acceptance testing (UAT) has been completed. All documentation and project information (backlog) has been updated and any incidents/issues not handled during the sprint are tracked in the appropriate system. Any necessary metrics have been updated. Any remaining closure steps have been completed (security audits, backups scheduled, training material ready as necessary, coordination with stakeholders and support staff ready/complete). Product Owner and stakeholders know the Deployment schedule.

What is your definition of done? How are you validating and measuring it? What decisions are you making because of it? <><

Reference:

• http://www.scrumalliance.org/articles/106-definition-of-done-a-reference
• http://blogs.myspace.com/index.cfm?fuseaction=blog.ListAll&friendId=319545476
• http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html
  

AgileRoots Conference

I will be attending the AgileRoots conference in Salt Lake City on Monday June 15 and Tuesday June 16. This is a VERY reasonably priced conference and I'm looking forward to it.

After the conference I will be staying in SLC for the week, talking to ScrumMasters in the area and hopefully finding out more about highly performant team "practitioning" as well as building connections that will help me build bridges between the SLC and Boise markets. If you are a ScrumMaster, Product Owner, Agile Practioner, Trainer, Coach, or Consultant and have contacts in SLC that would enjoy discussing the possibilities of bridging the Agile gap (between companies, cities, and individuals) please let me know! <><

Remote Team Members with Agile Scrum

Even under the best circumstances, not having Agile Scrum teams collocated is difficult. There are lots of issues some of which have fairly easy answers, and some don't. We have a partial team in Cost Rica and our teammates in CR have done a great job given the physical separation from the main teams, however it has been lots of issues and difficulties (which I'm sure they can attest to).

• Scrum is about face to face problem solving, decision making, and team collaboration. Some collaboration can be done online and some just happens as talk goes back and forth in the team area. Going overboard with electronic communication in this area (in addition to regularly scheduled communication) is the only way to really address it. Setup web cams, chat clients, and even team area web cams (to catch banter, team play, team work, and all that happens). Of course meetings have to all be connected with audio and visual (use VOIP and remote sharing for low cost solutions). We also did bring the remote developers in-house for a month training. I would consider this essential to starting team relationships that will are ultra-critical for Agile (and three months would be a better time frame than the one month we used).
  
  
• Ultra clear communication required. This is not indigenous to Agile, but applies to any type of non-collocated project team. Having worked at HP for over 10 years with multiple teams around the world, I know that working together with my remote partners required constant vigilance for changes, plans, retro's etc. The big problem is that, with traditional waterfall there is typically much more well defined requirements and milestones that remote teams can work from/toward. With Agile, we have only just enough of everything, including documentation, forcing frequent and face to face communication. This is a tough problem, no matter how good your people are. Of course there are other aspects of communication, from User Stories and Conditions of Satisfaction, to non-verbal communication (which is very difficult with remote teams), and team building. These all have to be addressed and solved.
  
  
• Meetings. Scrum is lightweight. The meetings are essential and critical to success. This means that remote locations (or team members) need to be included for Sprint Planning, Scrums, Reviews/Demos, and Retrospectives. Scrum also requires frequent impromptu meetings, where decisions are made. (Our Product Owners sit with the teams, further increasing the potentially for quick change and decision making). If the team doesn't communicate or connect like it should, there could be serious consequences. The only real workable solution in my opinion lies in making the remote location a team(s) of their own, and they need to be co-located with each other. This can be difficult in terms of economies of scale if you only want to keep a few remote team members - with more team mates remotely together you can save on fixed costs.

From my experience with remote teams in both Traditional and Agile environments, having remote team members will require lots of additional work, usually money, and lots and lots of patience. If you must have remote teams using Scrum, I highly recommend having them be their own team, make sure they have the communications technology and protocols in place, and remain as consistently Agile "by the book" as possible. <><

References:

1. http://tinyurl.com/non-it-scrum

Using Agile with Non-Software Projects

Part of the reason for writing my last blog was to show the essence of Scrum and how it could be extended to other types of non-software projects.

Agility is the ability to both create and respond to change in order to profit
in a turbulent business environment. - Jim Highsmith, Agile Project Management

I read a fun interview with Alistair Cockburn about how he used Scrum to build and add on to his home a few years back. Obviously this is a non-software project and was very successful. The main portions of Agile that he took advantage of were:

• Work Incrementally
• Willingness to make changes on the fly as needed
• Open Communication
• Feedback to help guide next steps
• Daily Standups
• YAGNI - "You Aren't Going to Need It" - do only what's needed, change later if necessary
• Time and material contracts
• Venture Capital Funding (funding as you need it)
• Customer Involvement and steering
• Small wins
• Process miniature
• Developing Collaboration and Trust

Agile Practitioner and Coach Robbie Mac Iver used the concepts of Agile to manage a complex business process in the supply chain domain. Some of the tenets discussed there relating to how they used Agile were mentioned before.

• Focus the team on the real business value
• Clarify the work streams and the alignment of the team
• Enforce what “done” means
• Make progress and issues visible (sometimes “painfully”)

Iver also mentions in his About section on his website that he belives that using Agile for business really provides three important deliverables.

• Effectiveness - Teams are working from the top of list of work that the business leadership has characterized as the most important, the highest priority. As these solutions are delivered, the business sees immediate gains and doesn't have to wait for "everything" (stuff that could have been planned for with longer planning) to be done.
• Information - The business learns very quickly what works and what doesn't. Information is discovered quickly and decisions can be made rapidly without significant loss (as compared to traditional projects).
• Control - The business is given more control because they can see quickly the state of situations and make decisions about which direction to go. They can work on projects that actually produce value, not just projects that might produce value, and stop whenever they have made "enough" progress to provide that value.

<><

References:

• http://www.agileadvice.com/archives/2006/06/interview_with.html
• http://www.swdecisions.com/documents/WP-ScrumForNonSoftware.pdf

Agile Essentials

Agile is a process framework most typically used in software development projects ideally suited for projects with high uncertainty. However the basic principles of Agile can apply to just about any type of context. The founders of Agile have developed a "Manifesto" that describes the basic tenets of Agile.

The four tenets are as follows*:

1. Individuals and interactions over processes and tools
2. Delivery of value over comprehensive documentation
3. Customer collaboration over rigid contracts
4. Responding to change over a detailed plan

Some other aspects of Agile are:

1. Early and continuous delivery of value
2. Adaptive insted of predictive to give maximum flexibility
3. Visibility for good and bad
4. Inspect and Adapt frequently
5. Become iteratively better
6. Result driven tasks
7. Face to face communication
8. Cross disciplined, motivated, empowered teams
9. Sustainable pace
10. Continuous attention to Quality

Agile Scrum (a particular flavor of Agile) arose from proceses that were designed to increase speed and flexiblity in the delivery of business or social value. It is a collaborative and change embracing method that cross-functional teams use to produce high quality deliverables through iterations of work time.

Scrum itself is specifically a lightweight process framework that is designed to focus the teams on delivering the highest priority items first. The fact is, that most projects or programs spend much of their time attempting to deliver some less-than-well-defined artifact, only to find that by the time it's done it's no longer relevant or needed. Scrum defies this by demanding that the highest priority items are addressed first, exposing issues, forcing the understanding of risk and dependencies, and in general bringing visibility to the team and the rest of the organization it lives in.

Read more information about the details of scrum. How would Scrum apply to your context?
<><

References:

1. http://www.agilemanifesto.org/
2. http://www.scrumalliance.org/articles/22-scrum-delivers
3. http://www.mountaingoatsoftware.com/scrum

*For the purposes of abstracting Agile out of the software world I have changed the wording slightly from the original, but it carries the same connotations (1).
* The focus on the first half of the statement doesn't mean that we don't care about the second half and need to consider them.