Getting Better Before You Get Bigger

At most of my Scrum training classes, people ask about how to scale agile at their company. When coaching at a company, what we are doing is typically the #1 need for scaling - getting better.

As Woody Zuill said so well at the Agile Open SoCal conference last month, "People ask how to do it right in the large, when they're not even doing it right in the small."

Yes, there are methods, tools and techniques for doing agile with 10+ teams, or multi-team projects, or distributed team members. But those practices won't solve the most common problem - lack of organizational alignment, buy-in and support (and from top to bottom). Most of the issues I find are with mid-management handling the change that come with introducing agile. But this is the same challenge that happens with introducing any change. The book Leading Change reinforces this point with 10 years of stories around introducing change at difference organizations. 

My experience has been that you'll be much better off getting one or two teams excellent. And by that, I mean success that everyone can see, and that is obvious. Nothing wins arguements and gets support like success, and this helps mid-management's willingness to go out on a limb with this new thing that will surely: raise more questions, change they way they do their job, move them out of their comfort zone, upset some of their reports, make mistakes. Help make that gamble for them as easy as possible. 

And keep in mind that we're in the Late Majority with agile adoptions. These are companies, customers, and managers who generally do not like change, resist change, and have been at the same company (and maybe job) doing things mainly the same way for 10, 20 or 30 years.

Listening to Your Team

Sometimes for a retrospective, I'll have a team play the ball point game. I do this because it let's be see the team dynamics as a whole in only 20 minutes. Is someone dominating the rest of the team? Is this a team afraid to take risks? Is this a team that innovates? Is this a team that has trust, is close and works well together, or are they a group of individuals who begin to blame and finger-point when the pressure is on?

Recently I had a picture of a team that was unique to me, but perhaps common to others. It was a team that I would give an A+ to for effort and energy. They were trying as hard as the possibly could, and that was part of the problem. They were so intense, so focussed, trying so hard that they weren't listening and giving weight to everybody's ideas. Instead, in the craziness and loud voices, it seemed they found themselves guided (or more appropriately, driven) by the energy and passion of a few.

After several iterations, and even my sharing with them the performance I've seen from the vast majority of other teams, they were beginning their next iteration with exactly the same approach as before, yet committing to significantly more work. "What changes have you made since last sprint?" I asked. "We are going to be more focussed!" they said emphatically. I wish you could have seen the situation - these guys had been giving more effort and energy than a playoff team, yet were saying the missing key to success was focus? Essentially, they were saying they were going to try harder, but make no other changed and more than double their productivity.

In the quiet moment while I had their attention, I asked if anyone on the team had any ideas that hadn't been tried yet. Immediately, one then two then three people shared great ideas that would enable the team to hit their goal. Now, these people sharing their ideas were not the loud, gregarious, driving leaders. They were more likely introverts. Just like the ones that statistically make up the majority of your technical team.

Often, I'll lead retrospectives by having everyone write down their thoughts one what's going well, not-so-well, and any ideas. This ensures that I hear the voice of even the quietest (or newest or youngest) team member. Our agile teams do not succeed based on the old, traditional approach of a project manager in charge who, often, is expected to make all decision (and therefore often the only person trying to solve all problems). Agile teams rely on collective intelligence. The same way that Google has come up with great products such as AdWords and Maps, or the way that Barrick Mining found fresh approaches to find where to mine based on contest submissions from around the world (as described in Mavericks at Work). 

No one of us is as smart as all of us, so make sure that you're creating space to hear all voices and great insights of your team.