What makes my Certified Agile Leadership training valuable and different?
I’ve been delivering my version of the CAL-I class for approximately 3-years. I deliver it mostly as a private class, nearly 80% of the time, to client leadership teams. I’ve heard feedback from many attendees that my CAL class is a game-changing experience and quite different from other leadership classes they’ve taken. I’ve even heard this feedback from attendees who’ve attended other CAL classes and been disappointed with those experiences.
I’m not saying I’ve got all the answers or that this will be the best class that you’ll ever attend. But what I am saying is that, within the scope of becoming a better agile leader, I think this class “nails it”. Let me share some of the key differentiators.
Something came up on the September 20th Kazi stream about how to maintain your energy level as a change agent, which is incredibly hard at times. And, on a related note, the challenge of knowing when it’s time to leave.
Change Agency is…HARD!
The harsh reality is that every Scrum Master and Agile Coach in any instance, situation, or context is a CHANGE AGENT. You are in a role that is trying to guide folks along a change curve to a new state.
And being a CHANGE AGENT is, in a word, HARD!
There’s no other way to say it. In many ways change agency reminds me of the Energizer Bunny in that you/we need to “bring it” every minute of every day. We have to bring enthusiasm, energy, positivity, engagement, and a can-do attitude every day to our work.
If you find yourself lacking on the energy front for too many days in a row, you have to seriously reconsider your choice of jobs. It’s that simple.
My colleague Dana Pylayeva has created something really interesting in the agile community. One of her research interests is fear in the workplace. Not in some academic fashion, but in how it shows up, that is what are the types and personas of fear in the workplace?
Dana enjoys creating interactive experiences, so she developed a series of cards (a game) that can help a team surface the various fears they may be experiencing. And, once they (the fears) see the light of day, the team can then discuss how they wish to deal with them.
Here’s some additional information on Fear in the Workplace (FITW):
Estimation FEAR Cards
In the November 2019 Kazi stream, Josh and I talked about teams often pushing back on estimating and some of the root causes. It seems like estimation is one of the hardest things for agile teams to get right (be balanced, feel comfortable with, do effortlessly).
Josh Anderson and I recorded a shared podcast with Jeff Bubolz & Jeff Maleski of the AgileWire podcast.
While we rambled a bit (mostly caused by me) across a variety of topics, it was a lot of fun.
One of the tangents we went on was understanding the agile maturity (readiness, culture) of an organization by the presence of certain words in the overall culture. This would cross everyone…teams to senior leaders.
There would be words or phrases that would indicate a less mature/ready culture and other words that would indicate more maturity. It would be the overall usage and trending of all of the words that would be most interesting and indicative of overall maturity.
(and please don’t get hung up by the word maturity, you could just as easily say readiness or receptiveness or fertility)
Early in 2019, Shelley Carter approached me about sharing a keynote at the Gatineau-Ottawa Agile Tour conference. I’ve never been to Ottawa nor spoken at that conference, so I said yes. I asked Shelley to share the theme with me, it was: "Imagine the Future - Lessons from our Current Selves". And as a keynote, I tried to come up with a presentation topic that would align with the theme. I submitted some ideas and I was honored to have been chosen to deliver a keynote there.
I eventually came upon telling my story around brand-building. How I had, over the years, approached building my personal brand. The focus of the talk was that everyone should build their personal brand as part of their career and professional journeys.
Our local agile ALN group has an annual tradition of doing lightning talks on the last meeting (November) of the year. The group coordinator kindly asked me if I wanted to participate and, since I was in town, I enthusiastically agreed.
But then the hard part began. I would have 5-minutes to talk about anything I wanted to. But only 5-minutes.
I struggled to figure out what to focus on until the day of the meeting. The pressure was building. And yes, I had a gazillion ideas that I could share, but nothing had risen to the top. Around 2 pm something came to me.
I interact with team members all of the time. They speak in terms of:
Their leaders have made them “go agile”;
That it’s not going the way they want it to be;
That things are worse than before;
Or that nothing has changed, they’re still underappreciated, overworked and stressed out.
You get the picture.
I’d like to start off this post with the following excerpt from the ProductPlan website. I think it sets the stage of things quite nicely:
“We’re agile, so why do we need a long-term product roadmap?” I hear this question regularly. At first blush, the terms agile and product roadmap seem like a contradiction, but they’re not. In fact, you should have an agile product roadmap.
In most agile product development organizations, the backlog is used by the development team to track what’s coming next, at least for the next few sprints or iterations. Many agile teams rely heavily on the backlog, as it maps out short-term initiatives. But the backlog in itself is not the roadmap. This post explains why you need both.
Product Roadmap vs. Backlog
A product roadmap is different from a backlog. The roadmap defines a strategic view of where the product is headed over the mid to long term, whereas the backlog defines the product features and initiatives for the near term. The roadmap is tied to the organization’s vision and strategic goals, often for the next 12 or more months. In an agile organization, the roadmap provides guidance rather than a strict project plan.
I also sometimes equate the word Portfolio with Product Roadmap. In my mind, the two are quite synonymous.
This was inspired to write this by the Music City Nashville talk by Faye Thompson and Charles Husemann. It was entitled: Coaching Katas - In Search of The Answer to the Agile Kobayashi Maru.
Essentially it was a series of coaching scenarios where we run thru Coaching Kata’s (very similar to Dojo’s as I’ve shared on them before). The scenarios were inspired by Star Trek episodes (original Star Trek I might add). In it, they emphasized using the 7-questions from The Coaching Habit book by Michael Bungay Stanier.
As we debriefed each of the scenarios, I heard attendees really struggling to apply the 7-questions effectively as part of a “normal” conversation.
It made me think that:
7-questions (from the Coaching Habit)
Powerful questions (from Co-Active Coaching)
Other question-based coaching models
Can set you up for failure if you don’t use them sparingly within the ARC of an overarching conversation model/framework. And we shouldn’t use them sequentially or artificially as well. They are also only for the coaching stance/role. For example, what about teaching, mentoring, or modeling stances/roles?
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…
