The Scrum Alliance and the Business Agility Institute partnered on a client survey focused toward—Skills in the New World of Work that was released in October 2023. You can get a copy of the report here.
The key question on the cover – Which agile skills are most in demand in today’s workforce?
But on page #20, the key question is reframed to – Which skills are most in demand in today’s workforce?
While the questions are close, I’m imagining the “agile” drove most of the respondent thinking.
I would encourage everyone to read it, as it contains some interesting findings and insights. That being said, there are some things in the survey (assumptions, commentary, shared data, and conclusions) that I want to challenge a bit. While the overall tone of this article will be constructive feedback, I don’t want to diminish the effort behind the report.
In a recent Moose Herd the discussion surrounded the release of the report and the impact and relevancy of the findings. How it was something interesting, thought-provoking, insightful, and new. I honestly didn’t read it entirely that way. Instead, I felt it also a bit contrived, self-serving, and old news. Now let’s serially walk through the report for my more detailed reactions…
I’ve been doing agile coaching for over two decades. If there were a Top 5 question I get when doing organizational and leadership coaching, it’s—
How do I set up my teams? Vertical, horizontal, hybrid.
What exactly is an x-functional team?
What about distributed team dynamics?
Are the roles full-time? Or can I share everyone?
How do I handle shared, service-oriented, or platform teams?
For a long time, I wished for a solid reference that I could send to folks when they have these sorts of “teaming” related questions.
Well, the good news is now I do, but it’s not one book. It’s a triplet of books.
This article by Martin Hinshelwood entitled—If your backlog is not refined, then you are doing it wrong; inspired me to write this article.
Here’s the LinkedIn post with some valuable commentary…
I wrote the first edition of my Scrum Product Ownership book in 2009, then a second edition in 2013, and a final / third edition in 2019. There was a period of time from ~2007 to 2020, where I was spending a majority of my time teaching and coaching in the agile product space.
One of the top three topics I explored over the time was Backlog Refinement. I would often coach team refinement sessions as a means of exploring, explaining, and show good practices for emerging and maintaining a solid backlog.
Often other product owners would attend to observe it as a fishbowl learning experience. While I’ve found no process or recipe for effective refinement, there are a set of patterns that have proven to be useful.
I was in one of our Moose Herd sessions the other day and one of the Moose (or is it Meese) brought up a scenario around impediments. The topic was—how to encourage (inspire, make) the team take ownership of resolving their impediments.
The question elicited a wonderful Herd discussion that felt like it helped the questioner. But as it went on, I began to remember that I’d historically formed a view of 4-Types of Impediments that I hadn’t thought about in a long time or articulated. Thus, this post.
4-Types of Agile Impediments
The first thing is that there might be more than four that some of you can come up with. These are just some that have helped me decide how to describe and act on them uniquely. I like drilling down into different types because it adds contextual flavor to handling the wide variety of challenges we aggregate into the word impediment.
1 - Team Impediments
I think the Scrum Guide refers to these as impediments the Scrum Master should be helping their teams resolve. They are within the span of control of the team and can usually be “struck down” quickly and easily. Or relatively easily.
I saw this post on LinkedIn the other day from Brian Orlando. I read it and a few comments, which motivated me to write this post.
Here’s Brian’s initial post—
I've been thinking...
In the latest Arguing Agile Podcast podcast where Hemant (Om) Patel and I discuss Peter Drucker's three different types of teams, right near the end we started to talk about aligning #management with/to the appropriate team model.
Anyone who has been involved in an #agile transformation knows organizational design changes are likely required for success (in response to product challenges, changing markets, etc).
I'm wondering why the obstinate resistance to responsive #organizationaldesign and #organizationaldevelopment?
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.”
I saw this post on LinkedIn the other day from Damon Poole where he was responding to a question about daily standup. And it made me think of all the debates I see today around folks in the agile community, how do I say it, following the “rules” of the various frameworks, methods, and tactics.
Now I get it. We’re agile, right? So, we should be inspecting, adapting, experimenting, not becoming dogmatic, etc.
But at the same time, I don’t get the point about all rules being bad. Especially when you’re just beginning (Shu for those familiar with that metaphor) or new to agile ways of working.
Learning to drive
For example, if you’re learning to drive, there are typically rules for learning to and maturing your driving, then the following is a fairly sensible path—
