AgileScrumPro

As Senge points out in his book, The Fifth Discipline, the current processes and structures of a system are that which determines its reality (Senge, 52). Put another way, you are what you eat. Businesses and organizations often struggle with why things are they way they are, yet the obvious and simple answer is that they have created their own reality through the way they think, they way the make decisions, their culture, their interactions with one another, their visions and goals, and so much more.

We could boil it down to say that an organization is the sum of its decisions. It follows very simply then, that changing our reality requires changing our decisions. Of course this is very simplified, however, as in any sports team wanting to excel, we must go back to the fundamentals and ensure that our structure and mindsets are going to create the outcomes we desire.

Senge’s organizational Archetypes (patterns of system behavior) provide a good language with which to consider the multiple components of any system. These components form patterns of thought, which lead to patterns of behavior, which in turn lead to patterns of events. These events may or may not be what was intended, but are nevertheless, the way things are. Projects managed with traditional software development methods have always been at risk from the obvious – it’s not possible to know in advance all that needs to be done because customer and business needs change. It seems clear that new patterns of thought (which lead to behavior and events) are needed.

Agile practices provide a pattern which can enable a true learning organization capable of dealing with change and the unknown, one which is able to be innovative and find solutions and markets where other organizations cannot. In the coming posts, I’ll be exploring Agile from a systems perspective and leveraging tools from a broader context to hopefully help Agile teams learn to look at problems a little differently, and help non-Agile teams learn to see how they can begin to be more agile in their own way. <><

Explodingdog http://www.explodingdog.com/title/decicions.html

Fractal Image: http://www.flickr.com/photos/longan_drink/289130767

Project Management Institute. A Guide to the Project Management Body of Knowledge: PMBOK Guide (3rd ed.). (2008). PA: Project Management Institute.

Schwaber, K. (2004). Agile Project Management with Scrum. Redmond: Microsoft Press.

Senge, P. (2006). The Fifth Discipline: The Art & Practices of the Learning Organization: Revised and Updated. DoubleDay

William Edwards Deming (1900-1993) was a business professor and consultant and is widely known for his work in Japan in improving design, product quality, testing, and sales through statistical and lean methods. He is regarded as having had more impact upon Japanese manufacturing and business than any other non Japanese person. After working in Japan, he worked diligently in the US providing seminars, lectures, books, and other outlets for his ideas about management. The list below is fourteen points which he believed were crtical to business success.

1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.
2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
4. End the practice of awarding business on the basis of price tag. Instead, minimise total cost. Move towards a single supplier for any one item, on a long-term relationship of loyalty and trust.
5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
6. Institute training on the job.
7. Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of an overhaul, as well as supervision of production workers.
8. Drive out fear, so that everyone may work effectively for the company.
9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
10. Eliminate slogans, exhortations, and targets for the workforce asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
11. a. Eliminate work standards (quotas) on the factory floor. Substitute leadership.
    b. Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
12. a. Remove barriers that rob the hourly paid worker of his right to pride in workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
    b. Remove barriers that rob people in management and engineering of their right to pride in workmanship. This means, inter alia, abolishment of the annual or merit rating and management by objective.
13. Institute a vigorous program of education and self-improvement.
14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody's job.

Feedback is clearly a skill that needs to be practiced by any team, but is especially important for Agile teams because they are typically more self directed. This means that they must find ways to RECEIVE and give feedback to one another, with the goal of helping the team build trust and deliver on time with high quality. Here are some ideas about the purpose of feedback and what each role (organization, management, peers) should be thinking about.

Purpose of Feedback

• Help each other get better at what we do so that we can be more effective, efficient, and have higher quality
• Create a conversation about ideas and initiate listening
• Learning tool to create buy in, understanding, and change
• Create an environment of open sharing and reliance upon one another

Organization's Responsibilities:

• Create an atmosphere of honesty, learning, trust, and safety
• Demonstrate a willingness to listen to and incorporate ideas, and actually change
• Create an expectation that peers give each other feedback, and tie it to an incentive system
• Ensure that hiring practices include evaluation of people's ability to receive and give feedback
• Provide training on how to give feedback
• Give the teams, managers, and themselves tools (DISC, Myers Briggs, etc) to facilitate learning about each other

Manager's Responsibilities:

• Demonstrate active listening and an ability to receive and give feedback
• Make it clear that the expectation of the team is peer feedback
• Ask, "Have you talked to them yet?" and "What did you learn about how you should change?"
• Provide tools and time for the team to practice feedback, have time to build relationships.
• Work with the team to remove obstacles and make changes (to a new seat on the bus or to a new bus altogether)
• Find ways to work on feedback together

Peer Responsibilities:

• Demonstrate active listening and actively solicit and receive feedback
• Realize it takes many tools to build a house, be willing to let other people be good in their own way
• Incorporate feedback tools into the Retrospectives
• Be willing to be wrong or have different ideas and not have everything your way
• Be willing to be passionate about ideas without destroying unity
• Give SMART feedback daily
• Seek to be helpful, not right

The overall goal for feedback, like any other Agile tool, is to start a TWO way conversation. This implies active listening, being engaged, being willing to learn, and ready to help. Is your team doing that? What can you do in your role to help facilitate better feedback in your organization, in your management, in your team? Are you willing to receive feedback as well as give it?

Happy conversing! <><

Our world is changing at an astonishing rate. Globalization and technology are driving all types of change in our lives and organizations. People are becoming ever more connected yet companies are struggling to find their way. Organizations that are able to survive and thrive in this climate share key attributes according to  Rosabeth Moss Kanter in her essay, "The Enduring Skills of Change Leaders." She believes that these key attributes are:

• The imagination to Innovate
• The professionalism to perform
• The openness to collaborate

The imagination to Innovate

There is a lot to be said about Innovation, but leaders today know that organizations who cannot innovate in our tough economic, global, and technological environments will not survive. Innovation requires not only creating new concepts and ideas that set the organization apart, but also creating a framework or culture that enables innovation. Freedom from the confines of dictatorial management is crucial. The organization must create an environment that safely rewards risk taking, unconventional thinking, and respect for the individual. There also must be accountability for the succcess of the organization and responsibility to deliver value. This balance between freedom and responsibility can create a space where innovation becomes the norm.

From an Agile perspective, this should come as par for the course. However many organizations, especially those running Scrumbut and Scrummerfall are doomed from the beginning because they've adopted the language of Agile but haven't provided a fertile organizational ground which will yield amazing fruit. This fertile ground often remains hard and unusable because the organization hasn't given itself permission to break up the soil, to remove the rocks that get in the way, to provide a good source of water, nutrients, fertilizer and symbiants to the ecosystem that will result in truly remarkable and innovative jumps. Companies looking for a "blue ocean", the creation of a new way of doing things to completely side step the competition and open up new markets all together, will not get there without innovation. 

The professionalism to perform

Unfortunately, it takes more than just good concepts and new markets, it takes the operational and professional capability to deliver real busines and customer value. Personal and professional competance is required to take innovative ideas and give them legs to run on. Performance has to do with an ability to execute with precision and depth, not just the ability to do something minimally. Don't let the simplistic concepts of Agile fool you though, there is incredible room within the framework for ensuring engineering and business excellence, but it MUST be part of the framekwork solution. Too many times organizations have implemented a new language (i.e. culture) and have given themselves some room to cultivate ideas, but they simply haven't done the due diligence to take them to the next level. No process or method will ultimately bring success on it's own. Innovation must be paired with results or the organization will eventually come to a grinding halt.

Competence includes not only organizational competance in engineering and business disciplines, but personal competance and having a system that rewards learners. Competence is concerned with the personal development and growth of the individual, and cares enough to actually listen and partner with the thought leaders and individual contributors within the system. As individuals are built up, the organization is built up and performance can not only be hoped for, but expected and cultivated.

The openness to collaborate

Collaboration implies connections between viable (i.e. innovative results) partners. This is "dialog" in the two way sense of the word. We no longer have the luxury of knowing everything ourselves or being everything to everyone -  information has grown too deep, noise has become too loud, and problems have become too complex. We must find ways to collaborate and make use of those around us to extend the organizations reach, enhance it's options, and bring new energy. We can no longer control all the synapses. If we are to innovate and develop competance, we must also have an uncanny ability to connect - our global and interconnected world leaves us no other options. Agile provides a set of skills, behaviors, and frameworks that enable real collaboration, on the small scale and across the enterprise. Making use of these behaviors and cultivating them in the team and in our leaders will help ensure success.

Leaders must be change leaders

Our organizations must recreate themselves so that they can innovate, develop competance, and be collaborative. This requires that change leaders be available to enable and guide real adoption of agile practices, attitudes, cultures, rewards, and so much more. Agility is deeper than just the reference to scrum, xp, or lean; it's an ability to surf, to move with the ebb and flow of the tide, to ride the waves, and turn the disaster of a rolling wave into a beautiful victory of "shooting the tube."  Change leaders must use classic change leadership skills, but they also must be connectors who can perceive common ground and have the ability to negotiate, persuade, and integrate. They must construct networks and build coalitions and they must be able to lead with clarity of vision and persist through storms that will certainly come. Leaders today must be change leaders, and change leaders today must be agile. Leaders will only be successful to the degree that they have the capability to flex and adapt.

The challenge

How specifically has your organization created a culture that breeds innovation? How must it change to do so? What are the major barriers to being open to new concepts? How does your organization take creative people and innovative processes and give them wings through the development of the people doing the work? What is stifiling a learning atmosphere? Is creativity and accountability and risk taking being rewarded or punished? What are ways your people are being developed, personally and professionally? How are you collaborating with your partners? vendors? suppliers? competitors? Are you making new connections every day? How? Do you have change leaders in place that can see through the waves to find the "big kahuna wave" that threatens to both destroy you or make you the champion? How are you creating leaders in your organization? Have you given them permission to think and move outside the box? Do you reward sticking to the the way things have been done in the past, or trying new approaches and methods? How far are you willing to go to find real sustainable success?

This trivium of innovation, competence, and collaboration provides a three legged stool upon which a change thriving organzation can stand and build upon. Are you standing on this stool or using it for firewood? <><

In part one of this exploration of Barriers we talked about topics such as teams being focused on business value, building trust with the Product Owners, and learning to address problems and not people. In this post, we'll talk about tips to help break down the "us" vs. "them" mentality and good old fashioned rolling up the sleeves and taking responsiblity to move forward.

Other barriers between the team and the Product Owner can come  from 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 ScrumMaster 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.”

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

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. <><

When thinking about Scrum and how it could be extended to other types of non-software projects, I found a great quote that applies:

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

One morning on the way to work I was listening to my favorite Classical station on the radio and they played a selection from Gustav Holst’s “Mars” from The Planets. The discussion around this piece centered on a musical device called a basso ostinato. A basso ostinato is harmonic pattern that is repeated under other variations or patterns in the music.

A popular and simple example of this is comes from the Jaws movie theme where a two note basso ostinato is repeated at in increasing tempo as the monstrous shark draws near. Listen to the selection from Holst’s Mars and you will hear a very pronounced repeating pattern, that, as the piece progresses, becomes a foundation for other melodies. As I listened, my thoughts leapt into the AgileSphere and considered the wonderful analogy that was literally being played out around me.

Agile Scrum has a bass ostinato as well. The simple four note repeating pattern of sprint planning, scrum stand-up, sprint review, and retrospective give a solid foundation for the team to play it’s menagerie of variations upon. As the details of the sprint unfold and sublines and swirling melodies of team interplay, discovery, and value delivery dance upon the surface of the ostinato, Agile begins to take a form beyond just a simple project management method. In a sense, it takes on a rhythm of it’s own, undulating and coursing through the veins of the IT organism.

Like the beat of the tell-tale heart, the Agile Ostinato plays onward, never breaking, never ceasing, always present.  For some, this constant beating is the sound of safety and home, like a child in it’s mother’s womb comforted by the sound of it’s mother’s life giving heart. For others, the Ostinato may seem more like drums on an ancient viking war boat, foreboding and unsettling. The latter reaction is one which comes many times as an unknown Agile process is forced upon a group, instead of it being born from within as an agreement which all have ownership in.

The basso ostinato also speaks to the Agile concept of sustainable pace. Tirelessly, unceasingly, the rhythm presses onward, engendering regularity and giving strength to the team, admist the bouncing melody of customer and business need. The repeating pattern is the drum directing rowers on a ship, or the metronome giving cadence and tempo - being burned into the mind and fingers of the master craftsman.

Interestingly, ostinati also have the concept of internal variations. Some ostinati will remain regular for a time, but slowly move up and down within the movement of the  larger piece.  In Agile, we inspect and adapt, keeping a rhythm, but moving upwards and downwards within the larger flow to ensure that the rhythm remains connected to the rest of the effort. As ship rising and falling on the waves it traverses, the Agile Ostinato rides with graceful regularity, providing a feeling of security and potential to those who count on getting to the proper destination.

The Agile Ostinato however, is surely more than just a four note pattern of meetings. It is the the clarion of the manifesto, it is the voice of the principles upon which agility was born, it is the partnership between team and customer, and the regular availability of working solutions. The simplicity of the ostinato is the underlayment for a greater work.

This is why Agile works, this is why Agile is crossing the chasam, this is why Agile in some variation of form and tempo will remain a relevant and useful device for the regular delivery of value to our customer. Not all music makes use of the basso ostinato, and that’s ok. Yet those who experience the Agile Ostinato will surely recognize it’s value and be changed by it. <><

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=31954...
• http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html