Over the past few months I’ve been coaching my clients who are in the early stages of adopting agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.
Universally, one of their complaints is that their teams aren’t “stepping up” to the
- Empowerment
- Responsibility
- Accountability
- Passion & Energy
- Creativity
That is implied as part of the culture of self-directed, agile teams.
To say that they are disappointed is an understatement. And these comments are coming from all levels of the client leadership teams.
Giving feedback is one of the things I like most about agile methods. There’s this thing about it though. It’s not that easy to give effective feedback. Lately, I’ve been hearing agile team members start their feedback with the following statements:
- I don’t want to rain on your parade, but...
- I don’t mean to be negative, but...
- I don’t mean to criticize, but...
- I don’t mean for you to take this the wrong way, but...
And then there’s the Ricky Bobby quote from the movie Talladega Nights regarding – “With all due respect…”
I get bombarded with different points of view from agile coaching firms all of the time. This one crossed my screen from Mike Cottmeyer just this morning.
http://www.leadingagile.com/2015/03/lets-acknowledge-safe-for-what-it-is-and-move-on/
and here’s a snippet from Mike’s post, just to give you some flavor:
So… I want to say this one more time for emphasis… either you create the conditions to do agile well… or you do something else. SAFe is that something else.
We can say that SAFe is a cop out… or isn’t really agile… or that it’s the second coming of RUP… but don’t underestimate the complexity, the risk, or the cost of totally refactoring an enterprise to be the kind of organization that can really do agile at any kind of scale. Some organizations simply can’t or won’t invest in this. At the end of the day small batches are better than big batches. Iterative and incremental is better than waterfall, even if it isn’t agile.
I frequently get asked about the dynamics of building agile organizations from an organization structure point of view.
The most important point is that you don’t create a high-performance agile organization by the defined structure. Managers don’t do it; neither do VP’s or Directors.
Surely we set the stage. But the teams are the ones that create the organization. We don’t have to optimize the structure for every technical hurdle or risk. Or create a structure that perfectly balances skill-sets and experience across all functional roles.
Whew! I’m glad, because I never figured out how to do that perfectly anyway.
I’ve recently been reading about and discovering some agile coaching firms who have different views towards client coaching. To be honest, I’m struggling to understand and accept some of their perspectives. So as is often my practice, I thought I’d write something about it to clarify my thoughts and position on the matter.
But first, let me share a story from a close friend of mine in Southern California:
A Coaching Story
I’m one of the best, most experienced personal trainers on the planet. If you view my website, you’ll see testimonials about my:
- Helping transform the health of large groups by running health camps;
- Assisting incredibly famous actors and actresses increase their physical performance to get ready for challenging physical roles;
- Serving as a lead fitness consultant on The Greatest Loser show;
- There’s even a rumor that the President will be inviting me to serve on the Council for Physical Fitness.
I challenged a service organization leader the other day about their agile journey. The firm provides outsourced software development teams – mostly for agile-centric clients. I was asking him about his internal application of agile practices and he asked me the question:
But Bob, when are we “done” with Agile?
From his perspective, his clients were asking for agile aware and literate teams and he was providing them. But he really hadn’t wrapped his head around agility. And he struggled with the notion of adopting agile practices internally.
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.
