I have a confession to make. I’ve fallen into a trap and I need to get out of it.
Gosh, Bob, what’s wrong? What is it you might ask?
I’ve been saying: “The Scrum Guide says” way too frequently. It’s almost a daily mantra and I suddenly realized that I need to stop it.
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.
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.
Death by PowerPoint
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.
Julee Everett and Ryan Ripley shared a wonderful article on making technical debt more visible. In that article, they focus on visual metrics that illustrate progress in cleaning up debt.
I’d encourage you to read it.
The article also made me think a bit about my own experience with technical debt and how to influence the organization to take it more seriously. Here are some advice tidbits to make your technical debt more visible –
There’s been a movement afoot in the agile community for a while. It’s about getting back to basics. I characterize it as:
- Agile leadership is nice, but…
- Agile planning & forecasting is nice, but…
- Agile Project Managers are great, but…
- All the certifications are nice, but…
- Scaling frameworks are nice, but…
- Accenture, Gartner, etc. interest is nice, but…
- DevOps and Business Agility are nice, but…
- Adoption, transformation, etc. are nice, but…
- Making $billions is nice, but…
We’ve lost the essence of agility. We’ve forgotten the very things that got everyone excited in the first place. The simplicity. The power of the team. The results that an engaged customer can inspire.
For years and years, I've been a strong advocate of goal-setting within your agile teams. Ares where I think goals are important include:
- At the daily stand, focusing the conversations towards the teams' goals;
- During sprint planning and at the sprint review, focus towards the sprint goal;
- If you're doing releases, ala SAFe release trains or a similar mechanism, then having a release-level goal is important;
- To me, Definition of Done and Definition of Ready, are goal-oriented. Providing clarity on the teams' constraints;