I submitted a talk to the North America Scrum Gathering this year that made me a bit nervous. It was entitled – Why the World Needs More Prescriptive Agile Coaches. And I was intentional with the title.
I’ve felt for quite a long time that agile coaching can be too soft, at least in the beginning with Shu-level (beginning) agile teams. Coaches are taught to never TELL teams what to do or be forceful in any way. At best, they might “hint” at a tactic or solution, but the real learning and evolution is “up to the team”.
Consider this the default coaching stance for the majority of agile coaches.
And while I understand it, I wanted to get the audience thinking differently in this session. And yes, see what the outcome might be. Does it resonate well OR do I get some tomatoes thrown at me was the question.
I stumbled on a blog by someone I hadn’t heard before. His name is Tanner Wortham and the blog is Spikes & Stories.
Here’s the link to the post: http://www.spikesandstories.com/qualities-of-great-agile-coaches/
In it Tanner explores qualities of great agile coaches with a theme of their biases:
- Bias towards learning
- Bias towards action
- Bias towards innocence
- Bias towards honesty
- Bias towards silence
- Bias towards the team
I loved the premise of the post and feel inspired to extend it a bit. So adding a few additional biases to the mix.
For years as I’ve been getting older, I often refer to myself as a “Dinosaur”. It’s not a bad analogy, as I’m getting quite old in the tooth.
I’m certainly not as technically astute as I once was, nor am I as mentally quick. And please don’t say that I was never all that quick.
But I read a blog post the other day from Jason Little that alarmed me. It brought the analogy home, as he is predicting the extinction of agile coaching.
I was sent a request to gather my idea on what Agile Maturity looked like from a column writer. Here’s her request:
Here's my thinking: In 2015, I heard many software pro's talk about "Agile maturity." But you had to listen hard to hear the phrase. Nobody shouted it from the rooftops; it’s not a buzzword, or even a new idea. It was more of a whisper, an aside that came up in the context of other topics: continuous delivery, better business alignment, mobile testing—to name a few. Yet it seems to me that this whisper is crucially important – that a mature Agile practice is the key underpinning for successful software development.
But what exactly does "Agile maturity" mean? It appears to run that gamut from advanced beginner teams flush with their first solid success to those are that doing continuous delivery, with high levels of test automation that entails.
What is your definition? Is your Agile mature? What are you working toward?
I hate to admit it, but I’m a relatively ad-hoc agile coach. I don’t use a lot of frameworks or tools. I mean I have a few that are well used and well worn, but I don’t have a toolbox the size of Montana (that’s big for folks outside of the United States).
I compensate for the tools with my overall experience. I’m coming up on 40 years of overall experience and 25 years of leadership experience in software development, so that helps me quite a bit in my coaching. And I’ve been leveraging agile approaches since the mid-to-late 1990’s.
That being said, I’m aware of this gap and I’m frequently looking for powerful tools to add to my coaching arsenal.
A short time ago I was working with an agile coach. He was quite experienced and well known in the agile community. He also held a wide variety of certifications.
We were working together on a project that had, if I were to be honest, quite a few cultural and organizational challenges.
There was one specific individual who always seemed to be the most challenging. My coaching colleague and I were talking about them one day and he was grousing (complaining) about them to me.
In several previous posts,
I’ve explored agile metrics as a set of 4 KPI areas that are typically monitored in agile instances. In this particular post, I want to drill into team health or “happiness” as a viable and important agile metric area. In fact, I might argue that it’s your core metric.
Let’s look at a couple of approaches.
Crisp – Team Barometer
I’ve occasionally shared blog posts related to questions from my good friend Lee Copeland. Lee will occasionally send me an email asking a question related to an article or talk idea that he has. In this case, he asked me about – “bad things that Scrum typically exposes”?
He sent me this list to illustrate the sorts of things he was looking for:
- weak people (who managed to hide),
- time stolen (by people for pet projects), and
- Parkinson's Law (work expands to fill the time allotted).
I thought about it for a couple of days, as I didn’t necessarily resonate with his short list. In fact, my initial reply to Lee was that – Scrum exposes EVERYTHING; so making a list could be a long effort. But upon reflection, I’ve created a “Top 10” Baker’s Dozen of things (challenges, dysfunctions, problems, etc.) that I typically see when organizations transform to Scrum.
It’s not intended to be exhaustive, but I hope you find it thought provoking…
I remember it was approximately 2008-2009 when I read a blog post, then article/paper about this idea. At the time Jeff Sutherland mentioned it, but the leading voice behind the idea was Scott Downey who worked at MySpace at the time.
Part of the reason I was intrigued was that agile coaches were really struggling to find their hand or balance when it came to “spinning up” Scrum teams at this time. Quite often the approaches were really soft and non-prescriptive. The coaches often hinted at a combination of practices, perhaps giving the team a link to a basic reference (the Scrum Guide), and then the teams were left to fend for themselves.
Often the results were horrible. The teams picked the practices they were comfortable with and left behind the rest. Often they picked such a trivial combination, that the results were hardly agile and hardly effective. This was also the time when Ken Schwaber coined the term Scrum Butt and the Nokia Test was being used as a litmus test to see if you were really doing Scrum or not.
Of course it’s going to happen. No matter how good an agile team is, eventually they’ll have a tough sprint and something bad will happen. They’ll miss the work they committed to in the sprint and some of it will need to carryover to the next sprint.
Mike Cohn had this to say about demonstrating that work in the current sprint in his December 10, 2015 newsletter:
A standard rule in sprint reviews is that the team should show only work that has been completed. This rule prevents a team from feeling that they've made more progress than they really have. Additionally, it avoids any risk that attendees leave a review confused about what has really been completed.
And so, teams are told they cannot show slides or partially finished work.
This is a great rule. But, just like my daughter tells me about her curfew, some rules are meant to be broken.
And so I sometimes break the rule about only showing finished work. A sprint review often brings together important stakeholders who are rarely together otherwise. That is a wonderful opportunity to ask them collectively, "What do you think of this screen [or other work] that is in process?"
It would be a shame to forego this opportunity just because of a Scrum rule.
Mike echoed my own advice for teams. But I usually adopt a harsher, no review posture, and Mike’s newsletter forced me to reconsider that advice.
I want to explore several aspects of sprint work that weren’t all covered in his newsletter.
