DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
Securing Your Software Supply Chain with JFrog and Azure
Register Today

Trending

  • Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications
  • Revolutionize JSON Parsing in Java With Manifold
  • Building the World's Most Resilient To-Do List Application With Node.js, K8s, and Distributed SQL
  • What Is JHipster?

Trending

  • Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications
  • Revolutionize JSON Parsing in Java With Manifold
  • Building the World's Most Resilient To-Do List Application With Node.js, K8s, and Distributed SQL
  • What Is JHipster?
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Kick-Off Your Agile Team With A Working Agreement Workshop

Kick-Off Your Agile Team With A Working Agreement Workshop

For a new team, creating a team working agreement canvas collaboratively is a great exercise to help forge a team identity and is crucial for success.

Ayman Idris user avatar by
Ayman Idris
CORE ·
Oct. 14, 20 · Opinion
Like (7)
Save
Tweet
Share
7.80K Views

Join the DZone community and get the full member experience.

Join For Free

The canvas, created by Avi Schneier and the Scrum Inc team [1], encourages the team to ask questions that go to the heart of team dynamics, from the norms and guidelines they agree to abide by, to the skills they bring to the table and the skills they want to learn from each other, to how they celebrate success and learn from failure. In this article, I will discuss how I adapted Avi’s original canvas to the needs of the teams I was coaching, elaborate on the different elements of a working agreement, and share with you a step-by-step guide to facilitating collaborative working agreement development workshops.

 

The 8 Canvas Blocks In a Glance:

Team Name and Motto: 

Having a team name that all team members can identify with is one aspect of establishing the team’s unique identity. A Team name should be created (and agreed on) by the team on their own. There are many anecdotal accounts[2] about how coming together under a common team name helps the team run much more smoothly and efficiently (Plus, it’s fun to come up with a great team name together!) In a recent working agreement canvas workshop I facilitated, and since there were so many Harry Potter fans in the group, they chose to be called Team Slytherin. You should’ve heard the laughs as they attempted to come up with that name!

The Motto is the team’s catch-phrase. Some teams opt for something that captures in a few words what they consider the essence of good teamwork, while others prefer something more tongue-in-cheek. I love to observe the dynamic of a team and how they learn more about each other’s personalities as they try to come up with a motto.  

Team Mission:

The working agreement canvas allows the team, in one sentence, to declare to the world why this team exists. This allows team members to deeply examine their own (and others’) perspectives about why we’re here embarking on this large undertaking. 

Developing a team mission together provides a wonderful insight into how every team member has internalized all the conversations and information presented and discussed as part of team initiation/inception/sprint 0 etc.

Strengths and Skills:

Having a broad understanding of the skill sets (business, technology, tools, soft skills, etc.) available within the team has many benefits, including:

  • It enables the team to take advantage of its members’ unique skills beyond their job titles (a back-end developer may not just do back-end development – she might have a decent experience in test automation as well, for example, gained from previous projects or from a past career. Imagine how useful it will be to know this at the outset of the project)
  • It shows the team if there’s a shortage in a specific skill, enabling the team (and leadership) to address that problem quickly
  • Seeing the breadth of knowledge and skill available in the team encourages team members to want to develop broad, T-shaped skills by learning from their colleagues. Have you always wanted to learn a particular tool or technology, for example, but always felt like you did not have the time? How lucky it is then that one of your new team members is an expert in that technology!
  • Also, I invariably find new teams surprised by the breadth and depth of knowledge and experience within the group. This goes a long way in helping members of a new team develop a sense of respect and appreciation towards each other, and also in instilling a sense of pride in being a part of the team.

Gaps and Growth Opportunities:

How will we become more cross-functional as a team and more T-shaped as individuals? The previous block has provided us with important insight into the knowledge and expertise within the team, and the next step is to figure out what to do with that insight. For example, are there any specific skills that we need that are simply not available in the team? what are we going to do about that? What are our individual goals in regard to building a more T-shaped skillset?

Celebrate and Improve:

This block has two main themes: how we celebrate success & how we learn from failure. Both are important in order to build a high-performing team. People almost intuitively grasp the importance of learning from failures/mistakes, but the benefits of celebrating success are often overlooked. Nothing [3] encourages a collaborative work environment like celebrating wins as a team and sharing in each other’s success.

In this block of the Team working agreement canvas, the team discuss and agree on how they plan to learn from failure and celebrate success (e.g. how & when they are going to reflect on errors and mistakes, how are they going to translate what they have learned from past failures into actions, what success means to this team – as individuals and as a collective – and how they plan to celebrate it, etc.)  

Norms and Guidelines:

This is where we discuss and collectively agree on our ground rules: the code of conduct that describes the kind of work culture we want for our team. We approach this by describing how we should (and should not) behave as we engage in the various aspects of teamwork: from how we run our meetings and events, to how we resolve conflicts, divide the workload, collaborate, communicate, provide feedback, etc. The goal is to create an environment where everyone feels comfortable expressing their opinions without fear.

Events:

How long should our Sprints be? At what day and time should we hold our Sprint Planning, Backlog Refinement, Sprint Review, Sprint Retrospective & Daily Scrum meetings? Where should these meetings be held (team room? Large conference room? Etc.) Which attendees should attend which meetings/ceremonies (consult the stakeholder map here)? Etc.  

Don’t try too hard to come up with a perfect team working agreement canvas. The working agreement canvas, like everything else in the context of an Agile team, evolves as we learn more. The longer we work together, the more we will learn about one another and about what improves (or hinders) our working dynamic as a team. Some of what we put in the working agreement canvas now will be woefully irrelevant in a few weeks or months, while new, emerging things (new additions to the norms and guidelines, for example) will demand attention and naturally find themselves on the working agreement canvas. This is good. It shows that we are indeed learning, evolving, and constantly getting better.

Working Agreement Workshop - Facilitation Guide (1-hour workshop):

  • This activity is only for core team members, so stakeholders, SMEs, etc. do not play a role in it. The ‘core team’ here refers to the people actually building the product: developers, testers, BAs, Scrum Master, Product Owner, etc.
  • Ask the team to form groups of 2. Each group will attempt to build a working agreements canvas on their own first, before trying to consolidate all the different versions into one canvas that represents the opinions and views of the whole team
  • Step 1: Pairs working independently to fill their canvas (20 mins):
    • Name: the pair brainstorms names for the team and agree on one
    • Motto: the pair brainstorms mottos/slogans for the team. The slogan could be anything as long as it is short & snappy. The pair has to agree on 1 motto to put onto their canvas 
    • Mission: the pair brainstorms answers to the question: “why does this team exist?”. Again, the two discuss their perspectives and agree on a mission for the team that they add to the canvas under the ‘Mission’ block
    • Strengths and skills: 
      • The pair first brainstorm all the skills they have in various levels of mastery (from novice to expert), covering technology, business, tools, soft skills, etc. Think broadly and don’t limit yourself to only the skills/areas that you know in and out
      • Next, the pair work to rate their level of mastery in each skill identified. One scale they can use is this simple 5-step scale: No skill – basic knowledge – perform basic tasks – perform all tasks – teaches all tasks 
      • To visualize the level of mastery a person has of a particular skill, I like to use the following visualization that corresponds to the 5-step scale above:
      • The pair’s visualization of their skills and respective levels of mastery will look something like this [4]: 
      • The pair’s visualization of their skills and respective levels of mastery will look something like this [4] : 
    • Skills we want to learn: In what skills do we want to increase our level of mastery? The pair study the skills matrix they built in the previous step, and then identify any potential skillsets they want to improve (or learn from scratch), writing on post-it’s the skill & the level they want to attain (e.g. they’re already at level 1 and want to be at level 3) – along with their initials. One post-it per skill to be learned
    • Celebrate success and failure: how & when are we going to reflect on errors and mistakes? How are we going to translate what we have learned from past failures into actions? what does success mean to this team – as individuals and as a collective – and how are we going to celebrate it? Etc. Brainstorm (and capture in post-its) answers to these questions (and others the pair can think of along the celebrate success and failure theme), and place the post-it’s on your canvas for later discussion with the rest of the team
    • Norms and guidelines: The pair brainstorms the rules that they believe should govern how team members work together. Some teams like to frame this as a list of things that we should and should not do. One way I help teams think through this part is by asking them to look back at the best and worst teams they had ever been a part of. Try to think about what stood out and made those experiences last (whether positive or negative). What behaviors or attitudes characterized those team environments, and what can we learn from them to nurture the type of culture we want for our team?
    • Events: The purpose of this part is to ensure that regular project meetings/ceremonies are scheduled in times that make sense to all team members. If you can’t be at work before 9:30 because you have to drop off your kids at school, for example, then it is important for the team to know that so that the stand-up is scheduled for a more appropriate time that accommodates everyone. The pair discuss dates and times for regular project ceremonies (e.g. Sprint planning on Mondays, Reviews, and Retros on Fridays before 3 pm, stand-up every morning at 10 am, etc.) Their proposals will be discussed with other groups and the dates, times, and places chosen should satisfy the needs and constraints of all team members. To get the conversation going, ask questions such as How long should our Sprints be? At what day and time should we hold our Sprint Planning, Backlog Refinement, Sprint Review, Sprint Retrospective & Daily Scrum meetings? Where should these meetings be held (team room? Large conference room? Etc.) Which attendees should attend which meetings/ceremonies (consult the stakeholder map here)?
  • Step 2: Form pairs of pairs (i.e. groups of 4) working together to consolidate their canvasses (20 mins):
    • Ask the team to form pairs of pairs (4 people)
    • The purpose is for the two pairs comprising each group of 4 to discuss the similarities and differences between their two working agreement canvasses, ultimately producing one working agreement canvas that captures the ideas of both pairs
    • Take the blocks one by one, and for each block discuss how the two pairs addressed the issue (e.g. team name, purpose, skills, etc.). Pairs take turns presenting what they developed and their rationale. The two pairs engage in conversation, discuss areas of agreement and disagreement, different options to consolidate the two versions into one, and eventually come up with a unified answer for each block
  • Step 3: The whole team engages to produce one working agreement canvas (20 mins):
    • Repeat step (2), but this time all the pairs of pairs get together as one team to compare their canvasses and ultimately produce 1 final team working agreement canvas
    • Run a quick fist-of-5 vote to gauge the level of commitment to/faith in the team working agreement canvas
    • If you get a 1 or 2: as a team, engage the team members who gave those scores to try to understand their point of view – ask what would it take to get you closer to 5? Work as a team to incorporate any changes or learnings from this activity into updating and improving the working agreements canvas.


scrum agile Sprint (software development)

Opinions expressed by DZone contributors are their own.

Trending

  • Performance Comparison — Thread Pool vs. Virtual Threads (Project Loom) In Spring Boot Applications
  • Revolutionize JSON Parsing in Java With Manifold
  • Building the World's Most Resilient To-Do List Application With Node.js, K8s, and Distributed SQL
  • What Is JHipster?

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: