Who Do You Tweak?

Yourself or the team?

Recently I’ve been coaching a team that is full of wonderful people, but in all honesty it has to be some of the hardest work I’ve done in a long, long time. Trying to get us all through the maze of neurosis, conflicts, petty jealousy and uncertainties has been enough to drive anyone nuts. We’ve made some terrific progress, but it has been slow, deliberate work. There haven’t been many dramatic breakthroughs. We aren’t hyper-performing. Hell, sometimes I think I’ll just be happy if we can make it to “stable”.

Along the way I’ve noticed something funny happening. When I first joined the team, I was told they were the “problem team” for the organization. Much of my early approach to coaching the group might be described as “tweaking” the rules that the team operated with. By tweaking I mean trying out different ways of working with each other that seemed to best address the myriad of problems we faced. Early on, I was definitely the one who was tweaking them (with the team occasionally tweaking me back just to keep me from getting too cocky).

But I found that I could only get limited success by treating the team as a black box with knobs on it that needed adjustment. A good friend of mine pointed out that I was still referring to “them” as the problem team. I realized that the “me” vs. “them” dichotomy had to be eliminated if this was going to be a success. Easier said than done.

That meant I really needed to become one of the team – in essence, I needed to tweak myself a bit. I had to take off the surgical gloves and dive into the black box with the rest of the team. Changing the rules had to impact me just as much as it impacted them. I found myself spending more time focused on my own behavior (in relation to the team) than on their behavior. Am I allowing them to speak their minds? Can I really give up control over certain things and still be a good coach? Nebulous stuff to be sure. These days, I’m no longer really sure who I’m trying to change – the team or myself. The line is blurred. Sometimes it is uncomfortable, but I must say that I’m much happier with the result. We’re making great progress. I caught myself telling someone today that “we rock!”

So I guess I’m coming to realize the being a coach is not just about being skilled at influencing others – it’s also about being willing and able to change yourself. Rock on.

Frequent Small Releases

With scrum, we try to deliver business value every sprint. That’s easier to do with some projects than others. If you have a mountain of technical debt facing you, delivering business value every three or four sprints can be a huge achievement. You might get lucky and find the occasional creative way of delivering business value quickly and easily, but most of the time you simply aren’t going to be able to manage it. Forget about it.

There are a lot different factors that make up a technically mature team, and they often take a long time to put together. Until you overcome those lower level issues, you won’t be able to properly address the higher level issues related to delivering business value quickly. Here is a graphic that I use to help make my point:

There are different levels of technical competence that need to be in place in order to support the rapid delivery of business value. If any one of these levels is missing, it is very unlikely that a team will be equiped to manage their work efficiently enough to deliver business value on a rapid and consistent basis. Teams need to be using source control tools and practices. Until they have source control, a team will not have the technical foundation in place to begin to put continuous integration in place. Once you have continuous integration working, you really aren’t getting the full benefit unless you can provide automated tests with every build. So on the technical side, a team has to have a lot of infrastructure in place in order to even think about delivering business value quickly.

There is another side to this issue that is very much tightly releated – how large are the releases that we make? Here is another diagram:

Here, instead of talking about technical maturity, we are looking at deliverables. At a relatively low level of process maturity, a team is really only capable of delivering files and resources with any real frequency. As the team becomes more technically adept, they are able to deliver components more frequently. As you can see, as the team becomes more and more efficient, they are able to deliver features and ultimately meaningful business value on a rapid schedule. These two hierarchies, the technical maturity and the deliverables maturity are linked tightly together.

So what’s the point? Well, if you are working on a team that is just adopting agile, don’t let anybody tell you that you are going to be delivering significant business value frequently – especially if you are like most teams and have a fair amount of technical debt accrued. It’s not that you can’t get there – you can, but it’s probably going to take a lot of work before you are able to deliver on that promise. People tend to expect immediate results when they switch to agile, and I’m here to tell you that often it just doesn’t work that way. If your teams are anything like the ones that I have worked on, you have a significant number of technical, personal, and other issues to overcome before you are going to be able to deliver the promised frequent delivery of business value. It’s definitely the way to go – I’m not saying it isn’t worthwhile, I just think expectations should be reasonable.

In the meantime, instead of trying to deliver business value every 5 mintues, why not focus on Frequent Small Releases (FSR) instead? Yeah, you heard me right. Learn how to deliver something – anything – frequently first. It’s all part of building a mindset of frequent releases that will ultimately (once the team is ready) culminate in the hallowed goal: the frequent release of business value.

Amen.

Modeling

Look out Heidi Klume, I’m taking up modeling!

OK, maybe I won’t give up the day job just yet…

Sometimes I think there is no better way to teach something than by doing it. By modeling the desired behavior. Sometimes people just don’t want to trust you. They won’t beleive it until they see it. Especially when you are trying to sell them a new process. Maybe that’s the way it should be.

It’s one thing to believe in a process and share the perceived benefits, but it’s quite another thing to demonstrate those benefits yourself. As agile practitioners I think we need to prove our case to our stakeholders and our teams. To teach by doing. We have to demonstrate what a high performing team looks like. Sometimes people need to see it first. Words simply do not suffice.

Getting down and dirty and working on a team also tends to be a cleansing experience for me. A lot of the B.S. that I sometimes buy into will not withstand the metaphorical blowtorch of a team struggling with real, messy, problems. That’s a healthy thing.

Modeling also helps to remind me that I like working on small teams. I like the commeraderie. I like the challenge. And modeling also reminds me, usually with a swift kick to the head, that process won’t solve all of the worlds problems. Sometimes it doesn’t matter whether or not a team is agile – sometimes there are forces at play that agile development can’t help us with. In those cases, you may model and fail. Call it a learning opportunity.

So the next time that you feel frustrated that “they just don’t get it!” Maybe it’s time you tried a little modeling.