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.

Agile Defect Fixing

I just read a posting on AgileBuddy about accounting for bugs in an Agile world. The post talked about accounting for bugs, team capacity, and whether bugs should count in team velocity.

It is very clear to me, both from the literature and from experience, that you should account for defect work done in the sprint. You must account for all the work done, otherwise you set false expectations for your business partners, for other stakeholders, and for the team itself (creating a tendency to over task and over commit). There is more than one kind of defect however and they don't all need to be treated the same.

Defects found during the sprint that are a result of coding done during the sprint (sprint defects) should be part of your normal code/fix work. We don't track hours or points for these because they are part of the original story point/task hour plan. This does mean that you have to think about that during sprint planning. We should be planning on code quality, requirements clarity, and the things that create less defects too of course.

Defects found that are not a result of the sprint or that are found during the sprint and the team/PO chooses not to fix them (based on time and priority), are put into the backlog for future sprints. These need to be prioritized by the PO and estimated just like any other backlog item.

If a defect is planned to be fixed during the sprint, we consider it part of the sprint backlog and it gets counted in the velocity. We typically add a "bug" story that gets x number of story point assigned to it, then we add defect tasks that approximate the story point estimation. This allows us to keep working on defects that are found at other times or by other stakeholders/customers.
I don't think that punishing the team by not including their defect work in the sprint is productive. We have a lot of legacy code that the teams are not the originators on and to make them accountable for previous years mistakes (before Agile) doesn't make sense. I do however believe it's important to keep the team accountable to their commitment of story points and to completing the sprint defect free. The basic point is that the team working on an issue, isn't necessarily the one that created it (which can cause mixed feelings and eventually a lack of productivity).

Agile and QA is an evolving process for us, but as we move toward more automation and more consistency in our Agile implementation, we're starting to see better and better results. There is much more to say about defect management in Agile to be sure, stay tuned.

Demo Scripting

Recently we've started a simple, but very effective, process to help our Agile Scrum demo's go smoothly. We write up a short document, called a Demo Script, that describes what we're going to demonstrate for the sprint, and pass it out to the stakeholders before the demo starts. It's very simple, but it has lots of benefits.

Benefits of a Demo Script

1. Start a demo script at sprint planning to begin to understand what will be shown to the Stakeholders. This helps get the creative juices flowing about how the functionality in the sprint is going to be deployed and demonstrated. Some deployments can be very complicated. Getting the team thinking about the end is a good way to mitigate risk and keep the team focused on the right goals. Clearly, the script will change as the sprint progresses, but it should roughly correspond to the commitment that the team makes to the Product Owner.
2. Allows the team some think-time to understand if a particular environment needs to be setup or updated to allow for final demonstration or production deployment.
3. Gives the team a way to write down and walk through the steps they intend to take during the demo (pre-demo demo). This should be more than just a list of stories. It could list specific pages in a website that are visited, usernames/SKUs to look up, particular emails that are sent, or whatever it is that the product is doing. Writing down the steps helps the team understand clearly what they are going to be showing.
4. Gives the stakeholders something they can look at before the demo so they know if they need to be there, be prepared, or pay more attention in particular sections. Provides them a reference for the new functionality to keep with them. Provides an instrument to discuss potential changes or impacts to future/other work/products.
   
5. Helps the team practice in a room if the demo is in a place that isn't dedicated for that or that needs to be changed for some reason.
   
6. Provides a simple release notes of sorts (in lieu of some other more rigorous form).
7. Provides a common point of reference for the team to drop or add an item quickly, before the demo (depending on how soon you send it out).
8. When the team successfully demonstrates all the done functionality on the script, it becomes a statement of their success. Since things that aren't done, aren't demonstrated, the stakeholders are left with a clear understanding of what was accomplished.
9. Provides a way to reference work that didn't have visible outcomes. We always try to link actual end user functionality to every story, however sometimes those stories produce work that is not really demonstrable without taking more time than necessary (like on a sprint where there is no deployment potentially). This hard work needs to be made visible and this provides a simple way to do that.
10. Provides a simple list that support functions in the organization can reference in other discussions to form more complete documentation.

Tips on building your Demo Script

1. Have a good title - Name of team/sprint
2. List the team members names, including the Product Owner
3. Include a list of stories for sprint that have been completed
4. Include a list of steps that will be taken during demo, and then stick to them.
5. Remember to include done and undone work (retain visibility for accountability)
6. Don't include anything that distracts from the work of the team for that sprint. Other documents can fully describe things that need more work, bug lists, future stories, retrospective reports, etc. Including too much can detract from what is being presented.

The Demo Script is, in a sense, both a working document and a marketing instrument for the team. It clearly shows what is done and provides a high level view of the status of the sprint for the stakeholders and user representatives. Use a Demo Script to bring visibility to the hard work completed by the team. <><

Agile Scrum Overview

Today I'm referencing an Agile Scrum overview that I present whenever I get the chance. Please check it out and give me some feedback. It's not designed to have everything, but be a good general overview.

Here are some important books that you need to read if you are going to be implementing Agile in your organization.

• Agile Project Management with Scrum by Ken Schwaber
• The Software Project Manager's Bridge to Agility by Michele Sliger and Stacia Broderick
• Agile Estimating and Planning by Mike Cohn
• User Stories Applied by Mike Cohn
• Practices of an Agile Developer by Venkat Subramaniam and Andy Hunt
• Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen

Scrum and get it!

More about Barriers

Barriers between the team and the Product Owner can come in the form of the old “us vs them” mentality, a lack of following process (stories, conditions of satisfaction, poor tasking, lack of commitment, etc), a lack of understanding of what's being asked for, and good old fashioned lack of trust. The SM can help remove barriers by keeping some of the following in mind.

Ensure that the PO is part of the team. If the PO is treated or acts like someone not on the team, there won't be trust and willingness to interact in a positive and persistent way. The team (including the PO) needs to be able to check their egos at the door and be able to ask questions, challenge assumptions, accept ideas and differences, and at the end of the day remember that they are all shooting for the same thing - working software at the end of the sprint.

Emulate correct behavior. This applies to interpersonal behavior (being reasonable, inquisitive, respectful) as well as following team rules, culture, and accepted practice (except where that interferes with delivering working software at the end of the sprint).

Ensure that the team and the Product Owner are on the same page. Do this by asking questions of both sides, by checking assumptions, and facilitating regular and adhoc communication. Ensure that the schedule is followed and be proactive in anticipating events that might impact it (certain stakeholder must be there but can't be, technical limitations such as development or UAT environment issues, etc).

Ensure that the Product Owner is involved closely with the team on a daily basis. The PO should be attending the daily Scrum so that he can hear if there are impediments that require his attention (clarification of conditions of satisfaction or a story, priority decisions, etc). If possible, the PO should be co-located with the team so that they are building a relationship and learn how to deal with one another on a daily basis. Also, the PO can pair with programmers to develop/understand/clarify requirements as questions arise, not later when it's too late.

The ScrumMaster should take personal responsibility to own the process and the interaction between team and the PO. Whether by title or personal charisma, the SM needs to take personal responsibility and ownership for how the team and the PO behave together. This may be demonstrated by orchestrating adhoc meetings, helping keep things on an even keel when tensions right high, or encouraging dependency on each other. It should be done “covertly” in the sense that the SM is just helping to facilitate the relationship, not necessarily be present at every connection.

The ScrumMaster can be an abstraction layer between the team and external forces that get in the way. In some cases the SM may act as a barrier between forces that tend to impede progress. Many times there are multiple competing priorities that the PO is having to sift through to make the best decision for the customer. The SM can help by facilitating organizational or social change, helping the team to understand why the backlog may look like it does, or simply being there as a resource for the PO to take advantage of for bouncing ideas around or getting technical feedback.

Publicize the success of the team. The SM needs to publicly praise the good efforts of the team and the PO. Since the PO is the “single-wringable-neck” they need the support of the team, just like the team needs the support of the PO when their scope has to be reduced or when they push back on a feature request and ask for more design review. When the SM tells the organization of the success of the team and PO, trust is built in this delivery mechanism, which helps all parties be more engergized, motivated, and empowered.

Preserve openness and transparency between team and the PO. One of the foundation aspects of Agile is transparency. Agile brings out the good and bad, so keeping a commitment to respect between all parties is essential. This doesn't come overnight, but the SM can help bridge the gap by working to build a relationship with the PO and their stakeholders as well as the team. When issues seem to be running under the surface, the SM can ask questions (at the right time) about what is going on? He can help parties save face, but at the same time accept responsibility. This takes a willingness to be on the edge of conflict sometimes, but done well, can enable the team to build an open relationship with themselves and the organization.

Inspect and adapt. This is also part of the core of the Agile framework. The SM can help remove barriers by ensuring that the Agile inspection and adaptation process is followed as intended. It is also where the SM needs to ensure that follow up happens with retrospectives, with impediments, and with team productivity.

Push for continuous improvement of the process. The SM needs to remember that in most organizations, not every aspect of Agile will be implemented all at once, or done to the vanilla optimum that may be needed. The SM needs to have patience and ask the team and PO to grow at the pace they can readily absorb change. This will be faster or slower depending on the people and organization.

Help the team and PO to deliver the most value possible. Keep the team and PO focused, not on positions, but on objectives and purpose and goals. The goal is to deliver as much value as possible. When the team or the PO gets focused elsewhere, it becomes an impediment, no matter how cool or nifty it may seem. Keep the simple dictum, “a little better than before.”

Removing barriers is the core of the ScrumMaster's role. Learning how to be an expert at this will enable the team to do more than they could have done on their own. <><

Some of this discussion was taken from my linkedin q&a. Thank you to all those that contributed to that discussion.

Removing Barriers between the Team and Product Owners

According to Ken Schwaber and his definition of the ScrumMaster's (SM) responsibilities, the SM is to remove barriers between the team and Product Owner (PO) to effectively enable the PO to drive development and achieve value.

I asked my LinkedIn, Certified ScrumMasters group, the following question.

What are specific ways you remove barriers between the team and Product Owner? What are some specific ways that you, as ScrumMaster, have removed barriers between the development team and the product owner, so that the product owner directly drives development?

I asked this question in an effort understand in a more realistic and "earthy" way, just what it means in practical terms to remove barriers - in this case, between the scrum team and their product owner. In summary, here are some highlights of that conversation that I believe to be significant.

The SM needs to remove barriers by:

• Ensuring that the team is concerned about delivering business value. It's easy for developers to seek excellence for their team and department, which is good; however the team exists to meet the needs of the business. If the team is not truly focused on the needs of the business through delivering value, it is not meeting it's fundamental purpose.
  
  
• Helping the PO trust and learn how to work with the team. Some examples include helping ensure accurate tasking, promoting flexibility in accepting change,and ensuring that everyone is working toward the same goals (sprint goal and an understanding of Agile itself).
  
  
• Ensuring that the team knows how to work with the PO (not take on adhoc work, redirecting the PO to the SM in case of conflict with the plan, etc)
  
  
• Asking tough questions of the team and the PO to ensure that quality is not sacrificed.
  
  
• Learning to address the problem and not the person. Many times there are issues - like a lack of communication, not following the basics of the framework, not adhering to agreed upon engineering standards and others. These issues should be identified and then targeted for removal by the SM, pulling in as many people as needed (with the right authority)to remove the barrier.
  
  
• Educating the PO and team on the process regularly. It seems clear from many comments here and elsewhere, that the SM is the one driving the agile education process - on a day to day level by consistently pushing for agile adherence and continual process improvement; as well as on a more formal basis by identifying training needs and facilitating those needs in formal and informal ways (again, working with those who are in the position of authority to enable that training).
  
  
• Owning the Agile process and facilitating regular communication between the team and PO. There is some discussion between the ideas of ownership vs. enablement. The SM should clearly be doing his best to enable the team toward growth and self direction. Because the Agile team is focused around collaboration, it seems that the the SM is typically the one helping to direct the growth and use of Agile within the organization. There are usually other partners involved as well.
  

A great article on ScrumAlliance mentions some other barriers that the ScrumMaster handles in support of the team:

• Work to remove impediments on a daily basis and communicate resolutions
• Protect the team from disruptive outside influences (support staff, managers, customers, even the PO if that becomes an issue).
• Unnecessary time wasters (inappropriate meetings, tasks that someone else could/should be doing)
  

There are other aspects of removing barriers that were not covered here and are the topic for future conversation. There are barriers:

• Between individual team members
  
• Between individual team member roles
  
• Between the team and the product owner

Of course these barriers address just a portion of the overall business communication context, however, they are the primary areas of interaction for the development teams and the SM. It is hoped that, as more is learned about what kind of barriers generally occur and good solid ways to deal with them are determined, that more targeted efforts can be made by the SM and the organization to avoid them. <><

Welcome to AgileScrumPro!

I hope to use this blog to document my learnings about Agile Scrum as I pursue expertise in that role. I have been involved in project management and coordination for several years before becoming a certified ScrumMaster at BodyBuilding.com. I am a member of our local APLN (Agile Project Leadership Network) local Boise Chapter, a member of several Agile groups in LinkedIn, and seeking to expand networking opportunities for the purpose of promoting the use of Agile in software development and expanding the field, especially as it relates to project management in general.

Please feel free to contact me for questions or networking regarding Agile Scrum, especially in the Boise area. I am also interested in pursuing Agile coaching opportunities as they arise.

More to come...

<><