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.
I used to think that there were basically three forms of agile transformation. They were and are:
- Bottom Up
- Top Down
- Middle Out
and I used to say the most effective strategy for a true transformation is…all three!
I still basically coach that as an effective strategy. But as time has passed, and I’ve gained more and more experience, I realize that there is a fourth option that intersects all of these.
It’s:
And it doesn’t apply to the organization at all. It applies to the individuals within the organization. Let me explain.
