top of page

Self-Organization through Team Agreements

Updated: Jan 17, 2023

"Team agreements are the foundation upon which a cohesive and successful team is built." - Jocko Willink




What is the purpose of having team agreements?


In Scrum, the team should work together to define their working process, as well as the roles and responsibilities of each team member. This includes defining the team's processes for conducting sprints and retrospectives, planning and estimating stories, and collaborating with other teams and stakeholders. As the team matures, it should strive to continuously improve its processes and practices in order to become more effective and efficient.


What is the purpose of having team agreements?


In Scrum, the team should work together to define their working process, as well as the roles and responsibilities of each team member. This includes defining the team's processes for conducting sprints and retrospectives, planning and estimating stories, and collaborating with other teams and stakeholders. As the team matures, it should strive to continuously improve its processes and practices in order to become more effective and efficient.



Tuckman's stages of team development:


The "forming, storming, norming, performing" model, also known as Tuckman's stages of group development, was first proposed by Bruce Tuckman in 1965. The model describes the stages that teams typically go through as they develop: forming, where the team is first coming together and establishing goals; storming, where conflicts and differences of opinion may arise; norming, where the team begins to work together effectively and establish norms and procedures; and performing, where the team is fully functional and productive.

In Scrum, teams are expected to deliver working software from the first Sprint, so they may not have the luxury of spending a significant amount of time in each stage of development. However, Tuckman's stages are still relevant, as Scrum teams go through them in each Sprint, and work to continuously improve their performance.

Sprint Zero is often seen as an opportunity for Scrum teams to go through these stages quickly, and establish team agreements that will help them avoid conflicts and work more effectively. The Scrum Master can facilitate a meeting where team members prepare, brainstorm, sort, categorize, agree, and refine these agreements.

Having a clear understanding of what kind of team agreements are necessary can be valuable for team members, as it allows them to set the agreements in advance, rather than dealing with conflicts or issues in the middle of working Sprints. It also helps to foster trust, communication, and cohesion within the team, which are crucial for the success of Agile methodologies like Scrum.

The Scrum Master can facilitate a team meeting to establish team agreements, also known as "working agreements" or "team norms." During the meeting, the team can work together to prepare, brainstorm, sort, categorize, agree on, and refine their agreements.


Scrum teams set the work agreements:


In Scrum, the team is responsible for setting their own work agreements, also known as "team norms" or "team rules." The ScrumMaster serves as a facilitator to help the team establish these agreements, but it is ultimately up to the team to determine how they will work together and what agreements are necessary for them to be successful. The team should review and update their agreements as needed during retrospective meetings, to ensure that they are still effective and that any issues or changes that have arisen since the last meeting are addressed.


What is the most convenient time to schedule this meeting?


Sprint Zero is the ideal time to establish team agreements, however, it's also good to review them in retrospective meetings. Keeping them updated is important during each sprint ceremony.


Team agreements -- Sprint planning meeting:


Backlog refinement, also known as grooming, is a meeting where the development team, the ScrumMaster, and the product owner review the product backlog to ensure that items are clear, prioritized, and ready for development in the next sprint. The purpose of this meeting is to make improvements to the product backlog and get everyone on the same page about upcoming work.


What is the estimated length of time for this activity?


In Scrum, Backlog refinement is typically held as a regular ceremony, with no specific time prescribed. It is typically held sometime during the middle of the Sprint and lasts for one to two hours. The ScrumMaster should facilitate the meeting and ensure that the team members and product owners are able to agree on a suitable time slot. The purpose of the meeting is to help the team plan its work for the current sprint.


Which individuals will be taking part in this activity?


The Scrum Team, which includes the Development Team, the Scrum Master, and the Product Owner, should participate in the backlog refinement meeting. The Product Owner should be present to provide information about the user stories and to facilitate agreement among the team members about the details of the stories. If some team members are unavailable, the participants should be identified based on the current workload and tasks. The goal is to ensure that everyone on the team understands the user stories and is able to make informed decisions about their implementation. The agreement between the Product Owner and the team regarding the details of the user stories, wireframes, and prototypes is important as it helps to ensure that the team has a clear understanding of what is expected and that the final product will meet the needs of the end users.


What criteria should be used to determine the maximum size of a user story?


When refining the backlog, it's important to size the user stories. It's important for the team to decide on the maximum size of the user story they can pick up, and complete in an iteration. Ideally, the user story should be small enough so that it can be completed within 25 percent of the sprint time, this allows for easy prioritization, flexibility and faster feedback loops. A good rule of thumb is to aim for user stories that are small enough to be delivered in a day or two.


Prioritizing the baseline user stories and assigning them points:


baseline user stories with defined points are essential for accurate relative estimation. Team agreement on these stories improves estimation accuracy and allows for a shared understanding of task complexity.


What factors should be considered when selecting an estimation technique?


The best estimation technique for Agile teams is Planning Poker, which combines expert opinion, analogy, and desegregation in an enjoyable approach to estimating, resulting in quick and reliable estimates that the team can agree on.


What will be the Definition of Ready (DOR)?


The Definition of Ready (DOR) is a set of criteria that ensure user stories are fully understood, well-defined, and ready to be worked on during the next sprint. It is typically agreed upon by the Product Owner and the development team and includes items such as ensuring the story meets the INVEST principle, is clear and well understood from the "what" perspective, and that all assumptions, constraints, and dependencies have been identified and addressed.

The DOR criteria can vary depending on the organization, but it is typically used to help ensure that user stories are correctly scoped and understood before they are taken on by the development team to work on.


Team agreements -- Sprint review meeting:


The Sprint Planning meeting is an event where the Product Owner and the development team come together to plan the work that will be completed during the Sprint. The team breaks down the highest-priority items from the Product Backlog into smaller, actionable items and makes a commitment to complete them. This meeting helps the team align on the goals and objectives of Sprint.


Length of the Sprint Planning session:


The maximum time allotted for a Sprint Planning meeting for a 30-day Sprint is eight hours, but the team can agree to reduce that time proportionally for shorter Sprints. The meeting should be held on the first day of the Sprint and the Product Owner should attend. The meeting can be broken into two parts, with the first part focusing on defining the Sprint Backlog and goal and the second part dedicated to breaking down user stories into tasks. Alternatively, the team can do the user story breakdowns together with the Product Owner present to clarify any questions that arise. Short breaks can be taken after covering 20-30% of capacity.


Outline the tasks and objectives for the upcoming sprint:


Team members should read and understand top-priority stories before sprint planning meetings. The product owner should ensure there is enough prioritized backlog for the team to review. This will ensure all team members are prepared and productive during the meeting.

Determining the scope of the sprint based on the stories selected:

Team members should be aware of their capacity and velocity, and agree on the number of stories to be picked for the sprint. This will ensure that the team can effectively plan and commit to completing the stories within the sprint.

Tasks breakdown and assignments should be clearly defined:


To avoid last-minute conflicts, the team should predefine the process of task breakdown and agree to do it together for each user story during the second part of the Sprint Planning meeting. This ensures that everyone is on the same page and that all team members understand their roles and responsibilities.


Break down large user stories into smaller, more manageable tasks:


That is a common practice in Scrum, the Product Owner and development team should collaborate to determine the size of user stories that can be included in the Sprint Backlog. If a user story is too large, it should be broken down into smaller stories that can be completed within the Sprint or added to the Product Backlog for later consideration. This process is known as "splitting" and its goal is to ensure that the team is able to deliver valuable and working software at the end of each Sprint.


The Definition Of Done defines the requirements for story completion:


The Definition of Done (DoD) is a crucial aspect of Scrum and is used to ensure that the team has a clear understanding of what is expected for each user story to be considered complete. The DoD may vary depending on the complexity and requirements of the story, but it should always be agreed upon by the product owner and the development team. Additionally, the team should have an overall general DoD that can be adjusted for specific stories during Sprint Planning. This helps to ensure that all stories meet the necessary acceptance criteria and are ready for delivery to the customer.


Daily Scrum/Stand-up ensures team alignment and progress:


The Daily Scrum is a 15-minute daily meeting where team members report on their progress, plans, and obstacles. It's aimed to align the team, identify and address issues, foster collaboration and communication among team members and break down silos of work. Team members should be vigilant for signs of old working habits and address them during the meeting.


What is the ideal time for the Daily Scrum?


The Daily Scrum is typically held at the beginning of the day to align the team and set the direction for the day's work. However, for a distributed team, it is important to establish a Daily Scrum time that is convenient for all team members, taking into account different time zones and schedules. It is important to establish a consistent time for the Daily Scrum to ensure that all team members are able to attend and give their updates. This can be accomplished through open communication and collaboration among the team to come to an agreement on the best time for the Daily Scrum.


A consistent location for Daily Scrum:


it is a best practice to have the Daily Scrum at the same location every day, as it helps to establish a routine and ensures that all team members know where to go for the meeting. Additionally, for distributed teams, it is important to use an online meeting service to facilitate virtual participation and ensure that all team members are able to join the meeting, regardless of their location. This can help to foster a sense of cohesion and collaboration among the team and keep everyone aligned on the progress of the work.


Keep Daily Scrum time-boxed:


the Daily Scrum, also known as the daily stand-up, is a time-boxed meeting that should not last longer than 15 minutes for a team of about seven people. However, the team can agree to a different timebox that is more realistic for their specific situation based on factors such as the number of team members, location, and technology used. The purpose of the Daily Scrum is for team members to quickly share their progress and any obstacles they are facing, so it is important to keep it short and focused.


Team agreements reviewed and aligned during Sprint:


The development team works on committed stories based on priority during the Sprint. The Product owner clarifies any requirements or business logic queries. Any Impediments faced by team members are communicated to the ScrumMaster for resolution. Documentation is updated, story points are burned, and efforts are made to achieve the Sprint goal.


Coding best practices:


Coding standards should be established and agreed upon in Sprint Zero to ensure consistency and quality in the codebase. If not all team members have read the standards, a meeting should be scheduled for discussion and understanding to avoid any confusion or errors in the future. This helps to make sure that the team is aligned and working towards the same goals.


Pair Programming:


Pair programming is a technique that involves two developers working together on the same code. It takes time for developers to get used to, but the benefits are worth it. Team members should practice this activity to gain its full benefits.


Planning of Leave:


Leave planning is essential for effective project delivery. Communication channels should be established for team members to inform each other of leave plans, and these plans should be regularly updated on the Scrum board for coordination and tracking purposes.


Navigating Roadblocks: Strategies for Managing Escalations and Mitigating Risks:


The ScrumMaster and team should work together to create a clear and effective communication system. This should include protocols for how impediments, escalations, and risks should be identified, tracked, and addressed. All team members should be aware of the process and be committed to following it.


Agreement for Improved Soft Skills:


The team should also make sure to keep up with the team agreement. This agreement should be reviewed on a regular basis to make sure that everyone is on the same page. These agreements include committing to the Sprint Backlog and avoiding distractions, respecting each other’s opinions and ideas, giving feedback, and reaching a consensus before making decisions. Additionally, they should make sure that everyone is adhering to the Agile values and principles, such as collaboration, transparency, self-organization, and continuous improvement. By regularly reviewing the team agreement, everyone can ensure that everyone is on the same page and that everyone is contributing to the team’s success.


Facilitating Effective Sprint Reviews Through Team Agreements:


The team then holds a Sprint Review to demonstrate the Product Increment to stakeholders and discuss what was done, what wasn't, and what can be done next. The Sprint Review is a collaborative effort between the Scrum Team and its stakeholders.


Who will give the demo?


Having the developer give the demo is ideal, as it allows for a complete understanding of the functionality. However, if that isn't possible, the business analyst can take the lead in presenting the functionality. This will ensure that all team members have a clear understanding of the new feature.


Setting the Stage: Preparing the Environment for the Demo:


It is essential to guarantee that the demo environment is properly configured prior to the review meeting. This will provide sufficient time to test the environment, resolve any technical issues, and prepare the team for the demonstration. Doing so will help ensure that the demo runs smoothly and the review meeting is successful.


How to Effectively Capture Stakeholder Feedback for Future Reference:


During the demo and feedback session, our team should take notes in order to accurately record the client's feedback. It's important that someone in the team, or even everyone, pays attention to the feedback given and records it. After the session, the Product Backlog should be updated with the feedback, so that we can effectively use it to improve the product.


Harness the Benefits of the Sprint Retrospective: Exploring Techniques and Structures:


Sprint Retrospectives are an important part of the development process, allowing teams to assess their performance, identify areas for improvement, and reach an agreement on how to move forward. To ensure successful retrospectives, teams should be familiar with the various methods available, such as timelines, triple nickels, team radar, and force field analysis. Each activity allows team members to surface the necessary agreements needed to move forward.


Who Else Will Be Invited to Participate other than the team members?


The team should be given the autonomy to decide on the participants for the Sprint Retrospective so that members feel comfortable expressing their views and discussing areas of improvement without any inhibitions. This way, the team can get the most out of the retrospective and move forward with a positive attitude.


Outline Action Steps:


At the Sprint Retrospective, the team will discuss a range of topics, which may or may not be converted into action items for the next Sprint. It is important for the team to prioritize the items discussed and decide which action items are feasible and can be implemented during the next Sprint. To ensure that all items discussed are properly documented, someone from the team should volunteer to take notes during the Retrospective. This will help the team remember and refer to the items discussed when deciding which action items to take for the next Sprint.


Enforcing Work Agreements:


Once the work agreements are defined, they should be documented where necessary. Some agreements, such as coding standards, should be noted down, while others, such as timings and timeboxing for meetings, may not need to be documented. Documenting agreements helps to ensure a clear understanding between all parties.

Work agreements provide a framework for teams to work together effectively. It is important to review them regularly to ensure they are still relevant and suitable for the team. This can be done through regular retrospectives, at the end of each Sprint, or any other time the team feels necessary. By reviewing and updating agreements, teams can ensure they are working to the best of their ability.




Conclusion:


The Scrum Master plays a critical role in facilitating team agreements and helping team members reach consensus, even in the face of conflicts. The agreements made by the team help to create a suitable work environment and enable the team to become self-organized.


"The Scrum Master is the facilitator of the team, helping them establish agreements and processes to guide their work." - Jeff Sutherland


About Advance Agility

We, at Advance Agility, are the new-age Agile Coaching, Consulting, and IT services company. We enable end-to-end Digital Transformation. Agile execution is integral to our being. We are doing SAFe implementation with small, medium, and large organizations across the globe. Our vision is to be the leading Agile execution player globally. To keep adding value at every process stage. We are on a mission to empower our clients and move from concept to cash in the shortest sustainable lead time by adopting a human-centric approach to business agility. Embracing change is in our DNA. Things that keep us apart are Quicker and Seamless execution with an End-to-end gamut of services. Our Global presence and Stellar Track Record give us an edge over our competitors.



Connect with us at advanceagility.com to learn about SAFe and SAFe Implementation. We provide various SAFe certification courses along with DevOps, Scrum, Agile Coaching, and more training. Write to us at contact@advanceagility.com for any agile training or consulting needs. We are always looking for competent agile trainers as well. So if you are a good trainer or want to become one, do get in touch with us to that we can learn, grow and achieve together.










6 views0 comments

Comentários


bottom of page