If you were to have asked me about five years ago about agile team and organizational assessments, you might have gotten your head bit off. You see I used to be violently opposed to formally assessing agile teams in any way.
The roots of it probably related to aggregating team velocity. If you’re wondering, that’s not such a good thing to do either. I was worried about teams comparing themselves to each other and creating unhealthy or dysfunctional behaviors. I also worried about what THEY (leadership, managers, Project Managers, HR folks, etc.) would do with the information.
Now I’ve always felt that having maturity data around, in some form, was helpful to seasoned agile coaches. It just gets hairy when you start using it for organizational and x-team metrics. And it’s the inherent “metrics dysfunction” that is always lurking in the shadows this is a real concern.
Does anybody remember the Cool and the Gang song Celebrate?
I sure hope so.
I want to write a short post about celebrations. For some reason I've encountered quite a few teams lately who are struggling. They're completing sprints and releases without getting much in the way done or meeting expectations.
In other words, they're ending their efforts: sad, depressed, without a sense of accomplishment. In a word, they’ve got no reason to – Celebrate.
Of course there are many reasons for it and I can't possibly explore all of them here. But the examples have made me reflect back on some of my best experiences with teams delivering “the goods”, and I wanted to share an example.
I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead I’ll be much more succinct.
Is forecasting evil in agile portfolios?
YES!
The context for this conclusion and subsequent discussion is three-fold:
- Forecasting when you are just building your agile teams OR are in the early stages of an agile transformation;
- And, when you’ve been doing agile for awhile, and you’ve become overconfident with your capacity awareness;
- And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning and forecasting.
Not that long ago, I received an email from someone in the Northwestern part of the US. They were thinking of moving to agile approaches and they wanted to pick my brain surrounding the logistics of “going Agile”. It was an introduction of sorts, but it was also an assessment.
They were assessing whether I knew what I was talking about and whether they’d allow me to help them. They were also assessing cultural fit. But I was also assessing. Were they “ready” to try agile, were they serious about it, were they self-aware, and would I like to work with them.
It was a great meeting and it led to some interesting follow-up activity. But I remember a conversation distinctly to this day that I wanted to share with you.
I’ve written several times on the subject of how coaches and trainers in the Scrum and Agile communities often use “management” as a term implying dysfunction and marginalization. Not always as clearly as that might sound, because they’re often paying the bills, but behind closed doors they’re often complaining about them.
If an agile adoption goes awry, we often blame it on the leadership team –
Clearly our training and coaching of the agile teams was complete. The fact that the adoption is failing or dysfunctional isn’t my problem. It’s those pesky leaders. I tried to invite them to the CSM class…and they didn’t have the time. They only had time for a 1-hour leadership overview and half of them were on their cell phones the entire time.
They keep asking me to do more team training, and I’m doing that. But they really need to get their act together for this agile transformation to work. Sadly, I’m at a loss as to what I can do…
In my last post we explored a situation where a Product Owner had a long-term challenge with their performance that was weighing their team down.
But as I finished that article, I realized that there might be something else going on that I wanted to explore here.
In that situation, the teams’ coach assured me that conversations and escalations had happened between herself, the team, and the Product Owner. She even said she’d escalated things to the PO’s boss. She made it sound like there was a huge amount of clear feedback over the course of two full years.
Given this, they seemed to be at an insurmountable obstacle—a poorly performing Product Owner and nobody willing to do anything to improve the situation. In other words, they were stuck.
I was talking to a fellow coach the other day and she was venting a bit about one of her teams and their Product Owner.
Bob, she said, I have an outstanding agile team. We’ve been working within our product organization for nearly two years. In that time, we’ve delivered an application upgrade that everyone has viewed as simply fantastic. Now we’re onto a building a critical piece of new system functionality for them—so we’ve earned everyone’s confidence in our abilities.
We work hard, we work well together, we deliver high-quality working code, and we have fun doing it.
Ok, I asked. That sounds like a fantastic situation. To be honest, I’m a bit jealous.
About a year ago my podcasting partner Josh Anderson asked me this question. To be honest, I hadn’t even heard the term before he brought it up. It inspired me to write this brief blog post for Velocity Partners.
I was hoping to get some traction on the questions I posed in the post, but I don’t believe anyone responded. This was about a year ago and I recently attended a presentation that made me reflect back on it.
Here’s a link to the original podcast.
The five Core Scrum Values have been defined as:
- Commitment
- Openness
- Focus
- Respect
- Courage
The reference I’m using for this include a blog post by Mike Vizdos here. And you can see them articulated on the Scrum Alliance site here.
Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all his own. Here’s what Tobias had to say:
Whew! There, I said it, and now I feel a little bit better.
For years I’ve been coaching agile teams and one of the themes I’ve been emphasizing is:
- Co-location
- Sitting together at open tables
- Face-to-face collaboration
- Pairing: pair-programming, pair-testing
- Whiteboard, post-it notes, and flip charts
Have all been terms that I’ve emphasized during this time. I’ve pushed and tried to inspire teams to break down the walls and tooling and to sit together to build great products.
