Each team is unique, and as such, they each need specialized coaching.
The “New” Team — A Story
Each team is unique, and as such, they each need specialized coaching. To show this, I will start with a tale of a new team. Real events form the thread of this story, but I have fictionalized it to protect the innocent. Post story, I present a coaching strategy for a new team, such as the one described.
Part 1: The Setup
“We need you to coach a new team,” the Agile COE lead told me as soon as I arrived at my desk this morning. He seemed especially alert for 8 in the morning. Maybe I should have had the barista add that shot of espresso to my coffee. “The team is in the cloud data group. They are a newly formed team, but they all have previous experience serving on Agile teams. They are a bit on the large side with 10 development team members.”
My mind immediately started assessing the situation. I can’t help this. It is automatic. As a fairly seasoned Agile Coach, I have had my share of interactions with Agile teams who are newly formed but have “Agile” experience.
“I will introduce you to them at 10 o’clock,” the COE lead told me.
“OK, that sounds great,” I said. My mind was still racing. The variations in behavior amongst Agile teams these days is limitless. It is rare for a team to have a positive experience with Agile. Often, Agile is done to them instead of something they chart their own path to use. Agile was created to make a team’s product delivery life better. Its implementation is often far from that mark.
I decide to get more coffee. On my way to the break room, one of the other Agile coaches, Sarah, stops me. She says sarcastically, “Hey, Todd, have you heard that the cloud data group is going Agile?” She then inconspicuously rolls her eyes.
I skipped a beat as I considered how coincidental it was to hear about the cloud data group twice within ten minutes of arriving at the office. I asked with genuine curiosity, “What have you heard about that group?”
“Well, John, the coach that just ‘left,’ was working with those teams. He confided in me before he left that it was ‘messed up’ over there. The teams don’t want to change. Plus, they are a living anti-pattern. They have data component-focused teams, and as a result, they become a dependency for everyone and have no control to create working software of their own. John had good intentions, but I am pretty sure he was forced out for trying to change their status quo.”
I tried to keep my cool. Rumors are usually too far removed from truth on the ground and rarely produce reliable information. “Well, I meet with them at 10,” I said matter-of-factly. “I am hoping that will shed some light on the situation.”
“It should be eye-opening. That’s for sure!” Sarah exclaimed as she excused herself to head to a meeting.
I poured my coffee and tasted it. If I close my eyes and try hard to imagine what coffee is supposed to taste like, it is almost bearable. I go back to my desk, put on my earphones, and prepare for my introduction to the team. The best thing to do with a new team is to see where they are in their Agile journey and to see where they want to go next. Nine times out of ten, they elect to go down a path I would have recommended. When it comes from their court, they are much more receptive to change.
I finish up my approach notes and realize the meeting starts in ten minutes. I quickly gather my notes, grab some post-its and pens, and head to meet my new team. Along the way, I remind myself to observe and ask plenty of questions. Gathering empathy for their situation will be key for the coaching strategy I deploy.
Part 2: The Meetup
I walk into the team room, and nobody is there. I look at my watch. It is 10 o’clock on the dot. I open my laptop and check my email and calendar to make sure the meeting is still on. Everything looks in order.
Five minutes pass and the Scrum Master comes into the room. He seems nervous. “Sorry I am late. The daily scrum on my other team ran late,” he says as he wipes the sweat off his brow. “They are three floors down, so I had to run the stairs to try to make it here on time. Those elevators are way too slow.”
“No worries, I am Todd, the Agile Coach who will be working with you guys,” I say. His statement worries me. A Scrum Master split across two teams is a possible sign of trouble especially when one of the teams is new. Also, having two teams on different floors is a barrier for promoting face-to-face conversation. Communication bandwidth can drop even if a team member is sitting just twenty feet from the other team members. The difficulties of remote communication start to creep in. Throw in slow elevators and three flights of stairs, and the barriers get worse.
“Hi, Todd. I’m glad you are on board. We really need your help. I’m David,” the Scrum Master says with a look of relief. Then, like the flip of a switch, his expression turns to a look of concern. “Has the rest of the team not shown up yet? I thought their other stand-ups would be over by now. They are always busy on their other teams when we have a meeting. It is rare to have all of us in the same room at the same time.”
I maintain a calm visage, but inside, my mind is assessing the situation. This team is not dedicated to their product scope. Did David say, “other teams?” Context switching is bad enough when team members are assigned to just one other team. It starts to consume a significant portion of a team’s capacity when it goes above one additional team. Shared understanding and alignment suffer, flow is interrupted, and it takes longer for a team to gel. “Well, let’s wait on them before we get started,” I say calmly.
The Agile COE Lead shows up. Slightly harried, he says, “Hey, Todd, I need to go help another team out with an issue. Are you OK handling this introduction meeting without me?”
“Sure, no problem,” I say. “Once the team gets here, we will get started. I’ll update you later.”
I barely finished what I was saying before the Agile COE Lead left, saying, “Thank you!” as he rushed down the hall.
12 minutes into the meeting I looked at my watch. I was about to call the meeting when two of the team members walked in. “Hi, I’m Gwen, the database specialist,” one of them said. The other was frantically typing out a text message. When he finished, he briefly looked up and said, “Hey, I’m Ty. I am the backend service guy. I need to get back to this. Hold on.” He went back to feverishly typing on his smartphone.
“Gwen and Ty,” I say, “Nice to meet you. Do you mind if I ask you a question?”
“Sure!” Gwen says, enthusiastically. Ty does not look up from his smartphone. I don’t even think he heard me.
I smile at Gwen as I say, “I know this may seem like an odd question, but I have not been told much about your team. What is the purpose of this team? Who is your user?”
Gwen seems genuinely excited as she says, “We exist to provide the one true source of data for the organization. All data must go through us and be ‘blessed’ as meeting our data standards. Our customer is pretty much every developer in the company.”
As she talks, my suspicions are confirmed. This team does not have a clear purpose of delivering value to its end customer or even who the end customer is. The purpose also seems a bit monolithic for a cloud data team.
I turn to David as I say, “Will the Product Owner be joining us?”
The Scrum Master said, “Oh, I thought this meeting was only for the Scrum team. The Product Owner only meets with us on day 1 and day 10 of the Sprint. Let me see if she is available. I doubt she is. She is very busy with her day job.”
It is somewhat concerning that David thinks the Product Owner is not a member and daily contributor to the Scrum team. With all of the divided responsibilities, this team will have a difficult journey. For a team to normalize socially and begin performing as a unit with flow, they need to be dedicated to the work and purpose of the team.
As I consider all the data points from my interactions with the cloud data team, I start to form an insight that the preconditions for Agile team success are missing. This is a key team prerequisite to enable flow, alignment, teamwork, and happiness.
Story Analysis and Coaching Strategy
There are typically three stages a team progresses through in their social journey—Beginning, Practicing, and Innovating as shown in Figure A.
In the story above, the cloud data team is in the Beginning stage.
The Beginning stage of a team’s social journey focuses primarily on 1) ensuring preconditions exist for team success and 2) jump-starting a team to form new patterns based on Agile values and principles.
While it might be tempting to apply a standard training curriculum or guide the new team towards a cookie-cutter approach, this technique rarely works in practice. Understanding the team’s current condition and crafting a tailored approach is critical to success.
In the story above, the coaching strategy must start by meeting the preconditions for success before beginning to teach and coach Agile patterns to the team.
Preconditions for Success
From a preconditions perspectives, there are five to consider as shown in Figure B.
Purpose-Driven: A purpose-driven team needs to understand why they exist, who they are serving, and the desired outcomes and impact they are targeting. Alignment and motivation of a team around their purpose will occur optimally when they co-create it with their stakeholders.
Small, Stable: A team should be small enough to promote rapid shared understanding through efficient and effective collaboration. Stability will prevent the team from having to repeatedly cycle through Tuckman’s forming, storming, norming, and performing cycles1.
Focused: Members on the team must be focused solely on their team. Teams whose members have partial dedication to the team will have their attention divided and will experience significant waste in delivering value according to their purpose. This will negatively impact their overall performance and success achievement.
Self-Reliant: A team’s members should have all the capabilities to completely deliver valuable work for the end customer. Teams that must depend on other teams to fulfill their purpose are at a significant disadvantage and will experience significant waste in the achievement of customer value.
Safe-to-Learn: A team must feel safe in experimenting to emerge the right product and to improve its effectiveness in delivery. Small experiments enable safety. The resulting growth mindset from safety in learning will create a team that is an unstoppable force of creative delivery. Without it, teams will stagnate and be unable to adapt to changing conditions.
Preconditions Analysis
In our story, the Cloud data team is struggling with each of the preconditions of success.
The team’s purpose is clouded as they are a data-focused component team and as such become far removed from the why, who, and desired outcomes and impact behind their cloud data work.
The overall team size of the Cloud data team is 12—10 development team members, the Scrum Master, and the Product Owner. If a team size of 5 is optimal for shared understanding and collaboration2, there is work to be done to right-size the team. Stability is also a concern as multiple team members have responsibilities with other teams.
The divided focus is a concern. Development team members have responsibilities on multiple teams. David, the Scrum Master, has multiple teams. The Product Owner has another job and is unable to engage daily with the team or perform the significant responsibilities of the role.
By its very nature, the cloud data team is not able to be self-contained to deliver customer value. They are simply delivering the data component that other teams must integrate with in order to deliver end customer value. They are dependent externally in every case to deliver end-customer value.
There will be little room for learning with all the waste present due to the other precondition gaps. The team will simply have no time to learn as they will be dealing with all of the other issues putting pressure on delivery. Learning is not a safe option.
Preconditions Coaching Strategy
The Toyota Improvement Kata3 is an effective, targeted improvement technique for addressing the precondition gaps with the cloud data team.
This technique will first focus on each of the 5 pre-conditions to describe what they are and why they are important. Then, the coach will co-create a strategy with the team and management to meet the pre-conditions through an application of the scientific method to attain incremental improvement as outlined in Figure C.
First, the team is asked if they would like to set a challenge to meet Agile team preconditions. If the team does not agree, no further action should be taken. A team must desire to take on a challenge; it should not be imposed. However, if they agree to set the challenge, the process continues.
Second, the team is asked to self-reflect where they currently stand against the preconditions and where they need to improve to achieve the challenge of meeting the preconditions. It is important to engage the team in reflecting on and recognizing their current condition and assessing their primary needs. Resist the urge as a coach to provide your own observations.
Third, the first precondition target state is jointly determined. With preconditions for success, defining the team’s purpose makes a good starting point if one does not exist.
Fourth, the first experiment towards the target state is outlined collaboratively with the coach. The team should provide their own ideas and the coach should suggest options from his or her experience. It is important for the team to select the experiment they will try first.
With a team starting on its journey, it is crucial that the coach has a high touch with the team as the team executes experiments towards their next target condition. This allows the coach to correct the team in their moment of practice. This avoids the seep-in of old habits and provides expert guidance on the correct implementation of the new habit. This results in faster formation of the correct new behavior habits.
The co-creation of an improvement strategy and an experimental approach to incrementally introduce change produces buy-in and helps the team build a skill set around applying a scientific method towards improvement.
Wrap up
When a new team is in the Beginning stage of their social journey, context is key. While it may be tempting to treat every team the same and jump right into training and standardized patterns, the more prudent approach is to customize coaching to the team’s context.
This post outlined a story of a new team in its journey. It emphasized a coaching strategy to work with the team to co-create the team’s preconditions for success before any Agile mindset training and coaching is performed.
The next post in the series will follow the Cloud data team as they embark on a new product.
Other Posts in the Series
- Customizing Agile Coaching to a Team’s Context—An Introduction
- Customizing Agile Coaching to a Team’s Product Context – New Products
- Customizing Agile Coaching to a Team’s Technology Context – New Technology
Related Posts
- Customizing Agile Coaching to a Team’s Context—An Introduction
- Agile Leader Pattern 2 for Building Awesome Teams: Stabilize Teams
- Agile Leader Pattern 3 for Building Awesome Teams: Small is Big
- Agile Leader Pattern 5 for Building Awesome Teams: Enable Self-Organization
- Agile Leader Pattern 6 for Building Awesome Teams: Serve the Team
- Gain Control By Breaking Dependencies: Task Level Part 1
References
- Developmental Sequence in Small Groups, Psychological Bulletin 63, B W Tuckman (1965)
- Agile Leader Pattern 3 for Building Awesome Teams: Small is Big
- The Toyota Kata by Mike Rother (2010)
Todd Lankford unlocks Lean Leverage in organizations to cultivate powerful, engaged product teams who maximize outcomes and impact.
His articles share his experiences and learnings along the way. Join the mailing list to get them in your inbox.