I saw this wonderfully courageous and informative post by Sabine Canditt the other day where she wrote about Sustainable Scrum.
https://www.linkedin.com/pulse/sustainable-scrum-responsible-choice-sabine-canditt-x0gef
After just completing a The Week program facilitated by the amazing Ann-Marie Kong, it touched my heart.
That said, I wanted to highlight one comment reaction/interaction between Sabine and Erich Bühler
Erich said—
Thank you for bringing this approach into the world! Scrum does provide an iterative approach for teams to create value, but its scope is limited to the product level and struggles with dynamics across the whole organization for several reasons.
Without updating the underlying business and financial model at a strategic level, Scrum alone cannot transform organization-wide sustainability.
I talk a lot about the first step in coaching any client (individual, system, team, etc.) is to build a relationship, gain empathy and understanding, and then gain an idea of where/how to help initially. So, do NOT start to coach until you’ve done some relationship-building.
But what does a coaching relationship, or a professional relationship in general, look like? What are aspects of that? Here are a few things that come to my mind—
Making + taking the time.
Explaining what you do—what is Agile Coaching.
Building some empathy; walking in their shoes; understanding where they are coming from.
Meeting them where they are.
Listening; reflective listening; building metaphors together.
Connecting with their language, not yours.
I was interviewing a personal trainer the other day. I asked them—
How should I measure your effectiveness and your value as my personal trainer to achieve the outcomes I desire?
And she responded with something interesting. She said, you can’t.
She followed up with—
My personal value and effectiveness must be coupled with your ability to partner with me to realize the results you seek. You see, at least how I see it, we’re in this together.
She went on to say—
1. T-Shaped nature of the team? (1)
Perhaps the best way to think of T-shaped-ness is the flexibility of everyone on the team to the overall work. Do people focus only on a narrow/deep skill area (I-shaped) or do they try and occasionally flex to help in areas where they’re less skilled, but willing to learn, pitch in, and help (T-shaped)? One of the easiest ways I’ve found to determine this is measuring the times you hear: “that’s not my job, or I’m waiting for Blarg to finish their part” within the team.
2. Visualization of work and tooling (1 and 3-)
How well does the team visualize their work? This includes the word itself (product backlogs, sprint backlogs) and artifacts around the work (DoD, charters, roles & responsibilities, etc.). I’ve always thought that the higher the maturity and performance of the team, the less they rely on tools and the more they rely on visualization and collaboration around the visuals. Related to this is the notion that the visuals are kept up-to-date in real-time or always reflect the current reality.
We were talking in the Moose Herd the other morning and Cory Bryan brought up the topic of factors that influenced agile team maturity, performance, and health. We immediately discussed the obvious factor of team size. Chatting about how team cohesion and maturity could offset any negative aspects of the team is larger.
Team distribution also came up, that is remote vs. onsite and geographic distribution. Again, we leaned into the idea that a more seasoned team could probably deliver “in spite of” the challenges of being distributed.
It was a really good topic to explore. And, as we explored it, I brainstormed in my journal and jotted down as many factors that I could think of that directly impact the formation, growth, dynamics, and ultimate success of any agile team.
I also tried to evaluate as to whether each factor was:
Entirely within the team’s control
Entirely an organizational factor
Or something in between, 3- meaning towards Org and 3+ meaning towards the team.
I think this twist nuanced the list a bit. Anyway, I thought I’d share these thoughts with you…
This idea came out of another Moose Herd discussion.
The situation where (sometimes) an agile coach can get lost in their role and forget to be themselves. To move from being:
Coach Bob, who has to “show up” as an agile coach every minute of every encounter of every day;
To simply…
Bob, who coaches, but who also is an employee, colleague,equal partner, and human being.
There’s potentially a huge difference between the two. For example, the latter allows me to:
Vent if I need to, or complain to my boss;
To get overly excited about an idea;
Not have to say…Yes, and… all of the time;
Not having to look for deeper meaning or revealing the system;
To passionately disagree with someone;
My emotions to surface, to get defensive, overreact;
To have a bad day; to have a great day;
To not want to coach now, today, this week;
Be real, be genuine, be ME.
The key idea here is for agile coaches to not get too “wrapped up” in their role to the point where they are always the coach or always coaching. To allow ourselves to occasionally step out of that role and become us. To not be afraid to express ourselves, to ask for help or a break, to not always have to be “coaching clients”.
Let that run around your mind as a coach and see if it resonates. Reflect on times when you’ve been coaching when you actually shouldn’t be coaching. And think about giving yourself permission to stop doing that.
But there I go again, always coaching…
Stay agile my friends,
Bob.
In our Moose Herd session this week (July 7th) we explored aspects of changing your perspective when engaging individuals, teams, groups, and organizations.
It’s not about changing THEIR point-of-view or perspective. It’s about changing OURS.
Some ideas that came out of this were—
Entering every conversation API - Assuming Positive Intent
Cynefin – considering the complexity and the situational context
Applying Ritual Dissent
Getting out of your comfort zone – experiment more, take risks, play around (Be a YES, Man)
And here’s a bonus post.
We all need to be in the business of expanding our perspectives. My hope in writing this was to share a few models or tools that you can apply and use to do just that.
Now everyone, prepare to be amazed!
Stay agile my friends,
Bob.
We were collaborating in the Moose Herd the other morning about agile coaching stances and when to be prescriptive (consulting or advising stances) and when not to be (coaching, facilitative learning, or
(I’m referencing the Agile Coaching Growth Wheel here for the stances…)
As I sat and listened to the discussion, I thought of a metaphor for the coach to help when adopting certain stances. I likened it to a mirror and a window.
This is where you simply serve to reflect back to the client you’re coaching. You, add, change, or delete nothing. How could you…you are a mirror.
The mirror reflects; clearly and succinctly. It says nothing. It does nothing. It owns no actions. It simply reveals the system (or the client) to themselves.
I have a question and would like to get some inspiration on an activity I’m trying to put together. Looking for an activity which will cover the following:
Strong communication between members in a team
Listening skills
Understand what is being told to you
My team is virtual, with a couple from another country, so English isn’t their first language. I have team members who don’t communicate to others to advise when they are done work so others can proceed, and the team on the most part is not functioning as a single entity. Now we are still in the Storming Phase, as this team was formed in late January and we added two new members over the last month.
The work gets done by the team, but it’s the bonding, communication, and paying attention when others speak, where I’m seeing issues. Especially hard being virtual for some I gather.
Clearly, the person sharing up the scenario wants things to change, improve, or get better. They want the folks to talk. And their reactions are—
How do I get them to talk more or when needed?
Do I just call on everybody in the meetings and make them talk?
Under the banner of continuous improvement within the team, how do we change this?
As a backdrop, they have a dual role of Scrum Master of the team and a Developer on the team. So, the mixed nature of their roles might be exacerbating things. Perhaps?
In a recent Agile Moose Herd group chat we explored a coaching dojo session. My friend Rob Walsh showed familiarity and vulnerability by playing the ill-behaved leadership role. I might add that he did a terrific job. As did the coaches, Rich Brents and Dan Puckett. Afterwards, I asked him to write up an account of his experience and he was kind enough to do so. Here’s the synopsis—
At a recent meeting of the Agile Moose Herd, Bob Galen (aka Chief Moose) suggested that the group do a dojo session where we would role-play a coaching session. I volunteered to be the client, and Bob suggested a scenario involving a senior executive of a tech company with a tendency to “swoop” into the details of the development efforts. He explained that this exec would jump into team meetings and dev sessions with ideas that he felt could make the product better. However, his actions served to demoralize the team and strip from them any sense of ownership of the product. The team saw them as mandates, not suggestions or helpful tips. Recognizing that something was wrong in the team, the company had hired an Agile coach to help set things right.
