Bob's Blog
Bob is a prolific blogger who simply enjoys sharing his experiences with colleagues in the Agile Community. Topics revolve around Scrum, XP, Kanban, Project Management, Business Analysis, Testing, Leadership and General Musings.
Check back often as we've always got something to say...
The ScrumMaster role is one of those that is simple and complex at the same time. I often speak in terms of doing agile and being agile, and the ScrumMaster role strongly influences their teams in both of those dimensions. Of course, the latter being much more difficult to manage and get right.
The good news in this space is that there are a few really solid books that explore this important role within Scrum.
It’s funny really. One of the key points of the agile methodologies and the manifesto is heavy collaboration, with the best being face-to-face collaboration. But one of the things I see happening in teams all of the time is, how can I say this delicately, over collaboration.
In other words, the teams, ahem, talk too much. There, I said it And I’m referring to open-ended discussion that takes too long if ever to narrow down towards a decision. Folks seem to be talking to hear themselves talk. Often it’s not everyone, with a few heavy talkers dominating discussions and the rest seemingly along for the ride. So it can be quite unbalanced.
In facilitation terms, there are two types of discussions going on when a team is trying to make a decision. There are divergent conversations, where options and ideas are getting put on the table. This is the brainstorming side of the discussion. And then there are convergent discussions, where the team is narrowing down options in order to make a decision.
A ScrumMaster asked me the other day how they should handle the situation where half their team doesn’t seem to care about the work. They don’t seem to be motivated. They seem to be slacking…a lot. And where two individuals seem to be doing all the work. And they seem to be burning out.
A senior leader in an organization that I’m coaching asked me the following when he found out I would be meeting with his boss. He asked me to tell him that they have too much work to do. That they are being stretched over capacity and that it’s causing delivery, quality and morale problems. In fact, the house of cards is about to fall.
I was training a class at a client the other day and three individuals, not at the same time, asked me to escalate their impediments. One impediment was that their leaders were excessively interrupting the sprints. Creating chaos. Another was that the priorities changed constantly. And the final, small problem, was that the leadership team expected the team to exceed their capacity by 350%. They wanted me to address these (fix it) with their organizational leaders. And, believe it or not, they were all serious.
This is a bit uncomfortable for me to admit, but I have some confessions to make…
I’m a SAFe SPC;
I’ve attended a 2-day Nexus training;
I plan on attending / co-teaching Scrum @ Scale with Don MacIntyre in September;
I’ve studied (I mean studied!) and contrasted DAD and LeSS;
I’ve actively coached SAFe organizations;
I’ve been leveraging simple scaling techniques (Scrum of Scrums, bits of SAFe) for well over a decade.
So, it’s fair to say that “agile scaling” is in my bones, in my DNA, and that I’m fairly experienced. And it’s incredibly easy for me to meet a larger scale client and begin discussing scaling aspects quite early in our coaching relationship.
I have some coaching acquaintances who’ve joined a relatively large firm. They’re tasked with being the internal agile coaches and leading the organization’s agile transformation.
Several times members of the organization’s leadership team have reached out to me to come in and discuss various aspects of high-performance agility. Topics like culture, scaling, and leadership agility was of heavy interest. I think they were simply looking to get an outside, experienced coach to come in and provide insights. Not undermine the internal coaches.
But each time the internal coaching team squashed the inquiry and insisted that they do the session. In fact, in other cases of invitation, they wanted to go over my “talking points” to ensure that I wouldn’t say something that differed with their guidance or perspective. Given that level of scrutiny, I respectfully withdrew any interest.
This is an actual example. But I’ve seen and heard it repeated many times in my own agile journey.
I’ve been blogging for quite a while, but I just realized that I have rarely (never) made recommendations for agile books to read as part of your learning journey. And as an author, I’m surprised at myself for this gap. A gap that I intend to start closing with this post.
My inspiration for starting to share on great books comes from Jeff Payne, who shared a similar post here - https://www.techwell.com/techwell-insights/2018/03/3-must-read-books-good-agile-foundation
Thanks, Jeff!
And this isn’t the end, but only the beginning. Look for the occasional post about learning advice for various aspects of your journey. Starting with this one…from the beginning.
I see Scrum Alliance certification classes advertised this way all of the time. Declaring minimal to no, to 100% no PowerPoints in the classes. And it’s not only the Scrum Alliance classes, but many other organizations and trainers proudly declare it.
One of the trends that have influenced this is the work of Sharon Bowman and her Training from the Back of the Room approach to adult learning. I attended the training a few years ago and it definitely changed the way I approach constructing classes, the learning, and the medium/mechanisms I used to foster the learning.
That being said, I don’t have a class today that is 100% PowerPoint-free. I just don’t feel that PowerPoint is inherently bad in its use for training. I view it as simply a tool, one of many, that I leverage. But clearly, I’m a Dinosaur in my thinking, as not many others view things the same way.
I think one of the reactions driving these statements is the scar tissue that poorly constructed and delivered PowerPoint classes has done to people. You can see it in their eyes of countless students who have been forced to sit through such training.
The other part of the problem is we all learn in different ways. Some of us prefer PowerPoints done well and learn quite effectively that way. Others of us want a more experiential and collaborated approach, where the learning emerges instead of us being told it. Information density is also a challenge. Especially when we’re trying to convey complex information or problems.
I was never a huge Simon and Garfunkel fan but there are a few songs of theirs that really stood out for me as I was growing up.
One of them is The Sounds of Silence.
It’s a haunting vision of the future.
And it swirled in my head as I read an article by Chris Murman. Chris is a friend and colleague that I find incredibly thoughtful about his (and others) agile journeys. But the article I found was published in September 2017, so nearly a year ago. And unfortunately, I missed it.
The article is entitled – What Can You Do About Organizational Silence?
And it focuses on a common corporate cultural phenomenon where the following occurs:
Leaders drive most of the “thinking”
Alternate ideas are not brought up
Discussion and debate are not realized
Disagreement with the status quo is discouraged
Creative ideas aren’t even suggested
And where silence, connoting tacit agreement, is the norm.
More than a few years ago, I visited a client in Greensboro, NC. I did a little consulting there, but it really wasn’t a longer-term gig.
What stood out to me, after all of these years, is that folks could bring their dogs into work. And everyone seemed to do just that.
There were dogs roaming free in the halls.
There were dog play areas.
There were dogs at their owner’s desks.
And those that didn’t have dogs were playing with others dogs.
And yes, there was the occasional “doggie accident” ;-)
It was a wonderful environment. Instead of feeling like an office space, it felt like a home that I was visiting. A comfortable home where the family loved their pets.
This is a continuation of Bad Product Ownership anti-patterns that I’ve seen all too often. And that I would encourage you and your organizations to avoid.
Without more context setting, let’s get onto the patterns –
It’s probably human nature.
When I ask a contractor to come over to my home to estimate fixing a problem. I usually focus on how long it will take them and how they will approach the repair.
