Revisiting Agile TeamsThis post is inspired by this article by Derek Huether - https://medium.com/@derekhuether/stable-teams-should-be-non-negotiable-59af0972f77
His is the sort of the position I used to have. However, I’ve been rethinking my position over the last few years. Not that I’m moving away from honoring the team. I’ll always do that.
But I’ve started to think that a little adversity isn’t necessarily bad for a team.
I want to use this post as an update to my writings about agile teams. The following post best captures my thoughts – http://rgalen.com/agile-training-news/2018/3/5/stop-norming-performing
Back to Derek’s point
Derek makes 3 key points in the article:
Teams that stay together are more productive. (more stories)
Teams that stay together are more predictable. (higher throughput)
Teams that say together are more responsive. (less time in process)
And he supports those conclusions with data from Larry Maccherone while he was with Rally/CA and reviewing data collected through their tooling. Another key point Derek makes is against the frequent reorganizations that run rampant in many companies. That they undermine all three aspects.
I’m not going to challenge the data or Derek’s key point. Let’s assume that everything is right. That we want to focus on team productivity. However, I think there are things to consider equally (and perhaps even more importantly) than productivity.
Sometimes my clients ask me which are the best organization structures that support a move to agile approaches. There are many ways to characterize their organizational structure and focus, but a common view I use is this:
Are they aligned as a Project-based organization or a Product-based one?
You can move to agile methods with either focus, but I think a Product-based focus makes it much easier. Let’s explore the dynamics of each. This will help you determine where your organization currently resides AND how you might want to shift your focus if you’re thinking about agility.
I spent over 10 years working at a company in Connecticut called Micrognosis. I wrote about an aspect of my experience there in this post.
During my tenure at Micrognosis we delivered many, many products and projects. We made millions of dollars on our technologies and our customers were fairly happy with our efforts. All of this happened in the span from 1986 – 1996. If you asked me today whether anyone, and I mean anyone, really cares about the efforts we made (products, effort, blood-sweat-tears, etc.), I’d say no.
One of the hidden factors in all of our legacies, and I know technologists don’t want to hear this, is that what we’re working on really doesn’t matter in the long term. No matter what you’re working on!
For example, Netflix or Google or Spotify of today really won’t matter (technically) 20 years from now. Sure, they’ll be historical notes about them on Wikipedia, but the products themselves won’t matter.
So, what does matter?
Late last year I took the Leadership Circle Profile certification class with Shahmeen Sadiq. It was a 3-day class for the core Leadership Circle Profile and then a 1-day follow-up for the Leadership Culture Survey.
I was looking for an instrument (360-degree tool) to use in my Certified Agile Leadership (CAL I & II) workshops to provide insights for leaders making the shift towards a more agile mindset. I’d been using Bill Joiner’s, Leadership Agility tool and I found it unwieldy for my purposes in the class.
Well, after four days, I’m excited about my new tools. I believe the LCP is a great tool for individually coaching leaders. And I’m even more excited about the LCS and how it will nicely dovetail into my private CAL I classes.
The Leadership Circle
I can’t do the instruments/surveys justice in a short blog post. What I will say is that the focus is on showing us the balance between our reactive tendencies and our creative competencies. Reactive focuses more on controlling and managing our teams. While creative attempts to achieve results by building and leveraging our teams’ capabilities.
My colleague and friend, Anthony Mersino runs VitalityChicago. And agile coaching and training firm in, you guessed it, Chicago. He recently shared a post about 3 Key Steps that leaders should be taking to create business agility. The steps are:
Get Executive Buy-in and Agile Mindset
Agile Leaders Should Get the Right Mix of Talent
Foster an Agile Friendly Culture and Organizational Structure
While I really like Anthony’s 3 Key Steps, I’d like to add to or augment them…just a little bit.
In my experience, there’s a HUGE difference between getting buy-in and achieving an agile mindset. Most executives have a modicum of buy-in. Otherwise, they wouldn’t be embarking on an agile journey. However, achieving an agile mindset is different.
I was approached to speak at a startup event for a local Business Agility Institute user group here in the Raleigh/Durham area. I was quite pleased to be approached and am more than willing to present an agile topic to the group.
But the request made me think…
I’ve been engaged in agile approaches for nearly twenty years. So, I have quite a lot of experience with the core methods, practices, scaling, agile leadership, cultures, etc. But what the heck is “Business Agility” and what sorts of topics would that group be interested in?
The answer escaped me and I realized I had to do some research.
Here’s what CA (Rally Software) had to say regarding a definition and 3 key aspects:
A company’s way to sense and respond to change proactively and with confidence to deliver business value—faster than the competition—as a matter of everyday business.
1. It’s making the customer the central focus of your organization
2. It’s driving value faster, better, and more efficiently
3. It’s transforming how your business operates to achieve successful outcomes
During the years 2009 – 2012, I worked at a small company called iContact here in the Raleigh/Durham area. iContact had developed an email marketing, SaaS application that competed (still does) with the likes of Constant Contact and MailChimp.
Ryan Allis was our CEO at the time and he was very innovative when it came to organizational change & evolution and leadership development. He happened to read The Five Dysfunctions of a Team, by Patrick Lencioni at that time, and became enamored with the ideas contained within.
At the same time, we were adopting agile (Scrum, Kanban, and Scrum of Scrums for scaling) across the organization. Quite successfully, I might add. So, the two efforts naturally converged. And I was pleasantly surprised how well our Agile efforts and the 5 Dysfunctions blended together. That’s really what this article is all about.
5 Dysfunctions & Agile, like Peanut Butter and…
I received an email from Strategic CIO Journal entitled – Top CIOs Become Business Process Czars.
The key focus of the article was raising the bar on CIOs to become more broadly engaged in the overall business and the processes to deliver value.
Now, I’m not going to critique the article. Because it was the title alone that inspired this response. It made me think about senior technology leaders – CTOs, CIOs, and any senior technology leader in a larger organization.
It made me think of their Prime Directive. Is it:
Business Process Leadership?
Or is it, Culture Builder?
The article seemed to allude to role moving from a focus on #1 to #2. And that is a relevant and important shift given today’s Digital Transformation strategy focus.
But that being said, in some ways, I think the article set the bar too low or in the wrong direction.