Social Contracts, Simple Rules, and Self-Organization

This is the abstract and conclusions from a short paper I wrote and presented at the 15th International Conference on Agile Software Development (XP 2014) in Rome, Italy. A preprint version of the full paper is available here.

Abstract

Teams and organizations are complex adaptive systems. Self- organization in complex adaptive systems evolves through a set of Simple Rules. Self-organization is a core tenet of agile teams. Self-organization does not mean everyone gets to do whatever they want to do. Team members create contracts with each other. These contracts create boundaries, or containers, within which self-organization can occur. Teams also create contracts with other teams, the wider organization and other stakeholders. The contracts are both implicit and explicit. Social contracts in complex adaptive systems are more effective if they are based on Simple Rules. Social Contract Theory acts as a lens through which we can better understand these social contracts in agile teams. This paper represents ongoing research that examines the role of Simple Rules and Social Contract Theory in fostering self-organization in agile development teams. The paper discusses four examples of social contracts in agile teams: definition of done, definition of ready, working agreements, and retrospectives.

Conclusions

This paper described the connection between Social Contract Theory and agile teams, viewing agile teams as complex adaptive systems. The field of Human Systems Dynamics provides a suitable lens through which to view teams and organizations as complex adaptive social systems, and defines necessary conditions for self- organization using Containers, Differences and Exchanges. The social contracts in agile teams and organizations are based on the Simple Rules that govern emergence and self-organization.

Simple Rules support coherent behaviors in a system. Definition of done, definition of ready, and working agreements are all examples of social contracts, created using Simple Rules, in agile teams and organizations. In addition, there are examples of social contracts to be found in retrospectives, including the prime directive, second directive and ground rules. These Simple Rules and Social Contracts support emergent behaviors and self-organization.

Teams own their own Simple Rules. As teams adapt their Simple Rules, new patterns are formed in the system. These patterns are governed by the social contracts created by the Simple Rules. Violating the Simple Rules creates a tension in the system that can be resolved by the team enforcing the rules or altering the rules (an Exchange intervention), or by the team membership changing (a Container intervention).
Social Contracts exist within agile teams, between agile teams, between agile teams and management, and within management teams.

Definition of Ready

Introduction

Many agile teams are familiar with Definition of Done as a set of agreements that let everyone know when a user story (or a sprint or a release) is really done, and all necessary activities are complete. Definition of Ready is a set of agreements that lets everyone know when something is ready to begin, e.g., when a user story is ready to be taken into a sprint, or when all necessary conditions are right for a team to start a sprint.

Life of a User Story

The typical life of a User Story is shown in the following diagram:

Life of a User Story from Concept to Happy User

At some point in time someone will have an idea or concept for a new feature. The concept will be expressed as one or more user stories, and get added to a product backlog. The team, working together, will figure out how to turn this concept, expressed as one or more user stories, into a real product feature that delights end users. That’s the abridged version; all sorts of interesting things happen along the way.

Viewed another way, we can consider the level of focus that a user story gets at different times.

The life of a User Story in a typical Scrum project

The horizontal axis represents time. The vertical axis examines the level of focus on the user story from the perspective of the Product Owner and the Delivery Team. Of course there are other stakeholders in the user story, but these are the two perspectives I want to consider right now.

Let’s assume we’re talking about a typical Scrum team, although the details are similar for any other agile process. At some point before the Sprint starts (represented by Sstart) the Product Owner has a high degree of focus on the user story. They are trying to figure out what the value is for the user, and how to express that as a user story. As we approach the start of the Sprint, the rest of the team increases their focus on the user story. As part of their Backlog Grooming and look-ahead planning activities the team will start to consider the user story’s general feasibility, acceptance criteria, dependencies and related details. The team will size the user story, and maybe even start to think about the tasks.

Between Sstart and Send the team works on delivering the user story. The team gets into more detail than the Product Owner during this period, as they figure out the software design, test cases, user experience details, implementation details, and generally work towards getting the user story Done (according to the team’s own Definition of Done) and Accepted by the Product Owner. The Product Owner is involved every step of the way – the intention of the diagram is to convey that the team is bringing a higher degree of focus during this time.

After the user story has been accepted the team’s focus changes to the next user story.

At some point after the Sprint ends (represented by Send) the team is considering the product as a whole, and preparing to ship it. By this time the user story has been combined with many others to form a complete product.

Synchronization points

The Product Owner and Delivery Team work at different cadences. They focus on different things at different times. Time-boxed iterations (or Sprints) are one way to synchronize their different areas of focus. Having a Definition of Ready that serves as a set of mutual agreements between Product Owner and the rest of the team brings a focus to upcoming Sprint synchronization points.

Why Have a Definition of Ready?

A Definition of Ready lets everyone know when a User Story is really ready to be taken into a Sprint. It does not need to be “100% defined” with all acceptance criteria, etc. but it should be “ready enough” so that the team is confident they can successfully deliver the user story.

It will save a lot of time if each user story meets Definition of Ready before the Sprint Planning meeting, but it is also OK to work on the user story during the Sprint Planning meeting to bring it to Ready.

Sample Definition of Ready

This section shows a sample Definition of Ready for a user story, and a sample Definition of Ready for a Sprint. I generally use these as baselines or starting points, and work with teams at the start of a project or release to customize the Definition of Ready for their product and environment.

Definition of Ready for a User Story

  • User Story defined
  • User Story Acceptance Criteria defined
  • User Story dependencies identified
  • User Story sized by Delivery Team
  • Scrum Team accepts User Experience artefacts
  • Performance criteria identified, where appropriate
  • Person who will accept the User Story is identified
  • Team has a good idea what it will mean to Demo the User Story
Most of these bullet points are targeting specific problems I have encountered on projects over the years. A little preparation can go a long way towards helping the team delivery user stories. When I presented this at XP 2011, one of the participants suggested adding that last bullet point. I like that suggestion.
I advocate that teams do not commit to taking a user story into a Sprint unless there is sufficient clarity and evidence of commitment from Product Owners. Remember the “3 Cs” of a user story (Card, Confirmation, Conversation). There’s a balance here, and judgement and common sense need to be applied. We don’t want to replace the Conversation aspect. I am not suggesting to turn user stories into specifications. I am suggesting that Product Owners and teams give themselves a greater chance at successful delivery of user stories by considering some issues ahead of the Sprint.

Definition of Ready for a Sprint

  • The Sprint Backlog is prioritized
  • The Spring Backlog contains all defects, User Stories and other work that the team is committing to
  • No hidden work
  • All team members have calculated their capacity for the Sprint
    • Fulltime on project = X hours per day
  • All User Stories meet Definition of Ready

Examples of ‘other work’ might include lab setup, build environment maintenance, creating a test application.

Scrum Masters, working with Product Owners and the rest of team, can use this to prepare for upcoming Sprints.

Slides

These are the slides from my talk at XP 2011 in Madrid:

Conclusion

Try using Definition of Ready to bring a focus to Backlog Grooming meetings and Look-Ahead planning activities. Product Owners can use it as a guide when preparing user stories for upcoming Sprints. Teams can use it as a checklist to make sure that they have an increased chance of success in delivering the completed user story, and that there is enough thought gone into the user story before they start to deliver it.