I’ve often held the perspective that there is no real ‘L’eadership roles within agile teams. The entire notion of a self-directed team in some ways confuses the role that leadership plays within agile contexts.
One of the leadership dynamics, at least from my perspective, is at the agile or Scrum team level. I’ve always observed that leadership is one of the central ingredients to a successful agile adoption. In fact, the larger the scale, the more important it becomes.
That being said, the larger the scale, the more incumbent managers and leaders struggle to figure out the new role they need to play in the shift. And quite often the organization really doesn’t support them (coaching, training, funding) in this effort. It’s sort of left as an exercise for the student; which mostly fails.
I spent about 3-years working at a company called iContact from 2009 – 2012. While there I reported to CTO – Ralph Kasuba.
Ralph was a wonderfully skilled leader and I’ve been reminiscing about him of late. Sure, we still stay in touch, but it’s not the same as working together each day.
Ralph had one “pet peeve” that I’d like to share and it involves interviewing. At the time, iContact was growing quite steadily, so it seemed as if we were always interviewing team members for our technical staff. We went through a period where no one seemed to pass our technical screens.
It was frustrating because the recruiters kept saying they were sending us qualified candidates, but the team-based interviews would just chew them up.
The language we started to use was that we were looking for Unicorn’s and not finding any.
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?
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 once worked as a coach at a large financial firm that had been “going Agile” for quite awhile. They were one of the worlds largest firms, so the teams and the projects were often distributed.
They had invested in a relationship with a Ukrainian firm to outsource a significant part of their software. This had been going on for a while, so there was integration between internal and outsourced agile team members.
I was pulled in to help the outsourced teams with their understanding of agile practices. You see, even though they “said” they were agile, their behaviors were really suspect and more indicated cowboy and self-centered development.
A month or so ago I was invited to do a podcast with my good friend Cory Bryan. The podcast is Deliver It and I highly recommend listening into what Cory has to say. Cory said something during the podcast that has been running around my brain ever since. He said:
I sort of like it when leadership can’t make decisions. I’ll tell them if you can’t decide, then I’ll decide for you.
The implication was that he would drive all decision-making as the Product Owner – even decisions that senior leadership should be making. He was quite firm in his tone, seeming confident of his ability to step in and drive.
More than a year ago I wrote an article about how important “capacity management” was in agile teams. To be clearer the point was really…realistic capacity management.
At the time, I’d just come off a coaching roll where I’d encountered quite a few organizations that were pushing their teams too hard. Not slightly over their capacity, but two, three, four or more times their healthy capacity. And this created some distinct side effects:
- Employee satisfaction and morale was down and attrition was up. And they didn’t just loose their average people, they were losing their best people;
- Product quality was usually in a crisis mode and customer trust was continuously eroding;
Now that I think about it, a “rule” sounds a whole lot more formal than I intend it. Perhaps I should call it a guideline or a heuristic or a thinking tool?
Ah, I don’t know. Let’s get into it and make that determination afterwards.
The Rule
It’s simple really. It revolves around telling your teams what to do. That is providing your directives, strong opinions, and guidance when you’re interacting with your fledgling agile teams.
The premise is that for every 100 opportunities that you are confronted with in your organization to provide prescriptive advice to your teams, you get no more than 5 times to actually tell your teams what to do.
One of the core ideas or principles of agile teams is this notion of a self-directed, self-managed, and self-organized team.
In my experience, it’s one of the hardest things to “get right” in your coaching and team evolution efforts.
Often I see two extremes…either:
the teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being agile”.
Or the other extreme is that:
the management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.