A Secret of High-Performing Teams: Working Disagreements
All of us have gone through the eye-rolling exercise of creating a Team Working agreement. We come up with the same 5 things every time:
Be present
Let others finish before speaking
Be on-time for meetings
Professional disagreement is encouraged
There are no "dumb questions"
Please don't get me wrong, Team Working agreements are great. They are mandatory for every high-performing team (scrum team or other type of team) that is in existence.
The problem is we approach working agreements from the "everything is perfect" view of the world. When is the last time you have been on a team where everything is perfect? If you are on one now, please let me know. I would love to come and hang out with your team and learn from you.
What if we approached things from a working disagreement perspective. How will we be able to disagree, debate, fight, and then quickly come up with a resolution. Then forget about the fight and focus back on the work?
Enter the Team Working Disagreement:
Think of it as a prenuptial agreement; we hope we never need it, but if things go poorly we need to have a set of rules set up for how we are going to resolve our differences. This way we are only worried about having the fight and not about the rules of engagement. Think of all the time we waste arguing about the rules of the argument, not about what the argument is actually about.
Here is a WORKING DISAGREEMENT example from a team I am working with right now. They are a 100% dedicated software development team. They follow the scrum framework. They are cross functional and can get an idea from start to finish with the exception of the final deployment to production. The company's bureaucracy and technical architecture are not allowing that...yet. (We will address this is a later post.)
Team events are mandatory unless you are on PTO. A missed event will result in the team member having to clean out the fridge at the end of the sprint.
Team events start on time. For every minute a team member is late they will have to put $1 in the monthly team event fund jar.
Sizing will be done as individuals, in writing, and secret. Failure to follow this rule will result in the individual having to sing "I am a little teapot".
Disagreements in technical approaches will be resolved within 24 hours. The principle parties will meet face to face (video conference is ok too) for no longer than 10 minutes. Our scrum master will facilitate the conversation. If the principle parties cannot come to a resolution, at the conclusion of the next daily scrum each person will have 5 minutes to make their case to the larger team. At that point the team will vote on the resolution. A simple majority is all that is needed.
The Product Owner will be available for questions within 30 minutes of a text request. If the Product Owner (or delegate when on PTO) is not available within 30 minutes, the Development Team will make the best possible decision based on their understanding of the situation. An update will be provided at the next daily scrum. If additional work results in the Development Team's decision, the Product Owner will look for work to take out of the sprint.
Do you see the pattern? This team knows that they have the best chance to succeed if they stay connected and keep work moving forward. Making a decision that may be "wrong" is better than not making a decision. You can always fix a bad decision. You can't recapture lost time. You
In addition, the team has high expectations of each other. If they are not met, the team doles out the "punishment". They are working together 6-8 hours a day, 5 days a week. They need to be able to build relationships on reliability and trust. They don't want a "manager" to baby-sit and make decisions for them. This team is the best team on the planet to deal with bad behavior and make decisions on their product.
Now if the team gets into one of these scenarios, they know exactly what to do next. For working disagreement #4, the parties in disagreement know they have 24 hours to get this resolved. The rest of the team knows that a resolution will be decided upon in 24 hours so they know how to manage their time in the interim. The key is that everybody keeps working! There is no office politics or back-stabbing. We understand that it is important that we only involve the parties necessary to make a final decision.
Remember, getting the work to "done" is the only measure of success. If it happens to be wrong, you will get a chance to fix it in the next sprint!
The highest performing teams have the ability to disagree, debate, resolve, and then move on with no lingering bad feelings. We are all in this together. We are here to make a quality product for our customers. Our customer’s happiness ensures a successful company and our ongoing employment.
Let’s be a team dedicated to making our customers happy.
Do you have a working agreement to share? Please put it in the comments below!
Here is wishing you a valuable 2020!
Thomas (Tom) Auld is a Product Owner and Enterprise Agile Coach. Since 2006 he has been part of agile transformations resulting in over $400MM of value created (and counting). Tom is featured in @JJ Sutherland's new book: "The Scrum Fieldbook: A Master Class on Accelerating Performance, Getting Results, and Defining the Future". Amazon's #1 New Release in Organizational Change.
Got 12 weeks to see if you have the right product, right team, and right approach? Agile12™is your solution. Designed over the last 10 years of working with Fortune 500 organizations struggling with agile, product development, and business transformation. In 12 weeks you will have a team trained, coached, and delivering up to 5 product releases. All for one price.
We have openings for Agile12™ starting in February of 2020.
See our 3 minute video here: https://www.auldconsultingllc.com/agile12-video
Contact us at Info@AuldLLC.com to schedule your free conversation.