I was coaching someone new the other day. I knew they had a broad and deep non-software background and were pivoting into a Scrum Master role. It was their first job as a Scrum Master, and the hiring company was taking a leap of faith in hiring them. But I knew they had deep skills that would translate into the Scrum Master role and that they would do well.
That is…if…they would stay in their lane.
They had ~20 years of experience and had held organizational leadership roles in their previous companies. Given that, I knew it would be a challenge for them to, how to say it, be a Scrum Master. Especially when they encountered organizational, leadership, and broadly impacting impediments.
They also seemed to have a very proactive, fix-it mindset. I thought this would be hard to throttle in the context of Scrum Mastery in an early-stage and chaotic agile transformation, mainly if they were focused on doing things “right.”
John Cutler recently wrote an article on his Beautiful Mess blog entitled—The Weeds. In it, he explores the notion of going too far into the details of a role/activity from another role perspective. Aka, getting into the weeds.
For example, a project manager might be asking too detailed questions about the design of a particular UX component and trying to reduce the effort associated with it. They have gone “into the weeds” with the developer.
A couple of things that this article made me think about including—
I’ve been speaking at conferences and training technology folks for over 20 years. During that time, I’ve probably delivered over a thousand talks and hundreds of workshops.
Early on, I cared deeply about the scores I received from attendees. Of course, I was always looking for perfect 10s from everyone. But an average score in the 9s was usually ok with me.
I would review all of the feedback forms as well. And, if I saw an outlier, such as a 3 or 4, I’d become obsessed. It would influence how I felt about the whole class. A few times I tracked down the person giving me the low score and interrogated them as to why. I even tried to negotiate a higher score with them right there on the spot.
You get the idea. I was incredibly focused on the grades as a measure of the value delivered in the class.
Fast Forward
Over time, I’ve softened on grades. I’m not going to say I don’t care anymore, but I’ve come to realize that there is more to each of my classes then a numeric valuation. I also realize that no class, and I mean no class, can make everyone happy. That is, perfect 10s are virtually not achievable AND they’re not a good goal.
So, I began to reframe my focus on each class.
A long time ago, in a galaxy far, far away…
I was visiting a client over the course of a 12-18-month period for some agile coaching when I discovered an interesting pattern. It seemed as if every quarter (3-4 months) or so they would reorganize their organization. Sometimes it was an overhaul reorg, with a massive shift for most folks. And other times, it was just a fine-tuning reorg, affecting only a small percentage. But on aggregate, it seemed as if everyone would get a “new boss” at least once a year.
Of course, there were different reasons for each reorg. Here are some of the drivers that were mentioned in passing—
We need to shift from a Project-based organization to more of a Product-based one.
We lack accountability and ownership within our teams. We’re going to shift management around and declare a “Team Lead” for each team.
We’re adopting LeSS (or Spotify, or fill in your agile scaling framework), which recommends flattening management layers within the organization.
We just merged with/we acquired by (Company x) and we need to aggregate our two groups into one unified team.
We’re simply not getting enough done. We wonder if a reorg will help? Shaking things up a bit if you will.
Now that we’ve “gone Agile” we have far too many of this “role” and need to flatten things out a bit.
We’re not happy with the results from the last reorg. Things are still not getting done and we want to further streamline the organization.
Change happens. Shift happens. So, get over it.
All of which gives you a flavor for the very typical rationale for reorgs that I’ve seen across my 20 years of coaching experience.
A coaching friend of mine came to me the other day asking for coaching advice about a team she was coaching. I’ll try to get the story right…
She was coaching a fairly new Scrum team. They were refining a story and decided to implement it in the front-end. Even though the “proper” solution was a backend one. It seems they’d done this before so there was a precedent.
The primary reason for this technical decision was speed. It would take them 5x longer to do a backend implementation and they felt the need to get this feature done quickly. They would then defer any technical debt clean-up to a future sprint.
The Product Owner weighed in on the side of the team but really didn’t have a strong opinion either way. They simply wanted the feature delivered as soon as possible.
The Scrum Master, as they were new, also sided with the team. So, the leanage was unanimous.
One of the functional managers in the organization, realizing that the team was making a mistake and implementing a hack or work-around, stepped in and tried to influence the team to make a better call, the right call, by implementing it in the backend.
The coach asked me about defending the team from the manager and how I might go about it…
Many years ago, I volunteered to help a local conference team reenergize their conference program. They had been putting on the conference for a number of years and were looking for some new, fresh, and outside opinions on how to change the format and reenergize it.
You see attendance was declining, not too much, but a troubling trend. And attendee feedback, while positive, pointed to getting a bit bored with the current repeating recipe.
We went out to dinner to brainstorm. It was attended by the long-time program chair and an invited set of 4-5 outsiders who were asked for their ideas.
We’ve tried that before…
As the dinner commenced, the introductory conversations turned into a brainstorming session All seemed to be going swimmingly and I was excited about the possibilities.
I was reading a blog post from a coach who was working with a continuous deployment team. In essence, every story (work item, PBI, etc.) from their sprint made it into the customers hands immediately. They received feedback on each in real-time and took follow-up actions as appropriate.
Since they were using Scrum, they were still conducting a Sprint Review every few weeks. The coaches question related to the value of the review. As it seemed that everyone was questioning it in this particular context. That is, since they saw (and accepted) things in real-time, what was the need to see them again in a review? Or were they just doing it because the Scrum Guide said to do it?
And the backstory was that the coach was struggling with dogmatic Scrum in the organization. I.e., doing things just because the book said to do them, rather than thinking and adapting.
This question made me think a bit about Sprint Reviews. And it led to the following online response to that coach –
My reply
During the years 2009 – 2012, I worked at a small company called iContact here in the Raleigh/Durham area. iContact had developed an email marketing, SaaS application that competed (still does) with the likes of Constant Contact and MailChimp.
Ryan Allis was our CEO at the time and he was very innovative when it came to organizational change & evolution and leadership development. He happened to read The Five Dysfunctions of a Team, by Patrick Lencioni at that time, and became enamored with the ideas contained within.
At the same time, we were adopting agile (Scrum, Kanban, and Scrum of Scrums for scaling) across the organization. Quite successfully, I might add. So, the two efforts naturally converged. And I was pleasantly surprised how well our Agile efforts and the 5 Dysfunctions blended together. That’s really what this article is all about.
5 Dysfunctions & Agile, like Peanut Butter and…
I was having an email conversation with an agile coaching colleague the other day. In one of her replies, she said the following:
BTW I really like the way you articulate your concerns about the agile community at large. It’s helpful to share with my leadership and customers as we try to navigate a very messy space of certifications, frameworks, and competing agile voices
The final point she made really struck a chord with me. The notion of competing agile voices.
It made me realize that, YES, there are many, many agile voices today. And one of the real challenges is to figure out who to listen to. Where’s the value and the experience? And how to avoid the “noise” or how to separate the wheat from the chaff?
I want to share some ideas around this challenge. No, I’m not sharing any secret filter or the 1-person to listen to. They don’t exist.
But I do want to share some advice for handling the high voice count and how to become a more discerning listener when it comes to the noise.
And it’s getting worse…
