About smooth agile transformations and the “why” leader

For my annual conference trip, I decided to skip the always-great QCon conference for once and instead attend Agile DevOps East in Orlando, Florida. In addition to the typical conference schedule, I also registered for some of the half-day and full day tutorials. One of them, How to lead high-performance agile teams, was a great interactive meet-up with about 50 people organized around a couple of big round tables and led by Mary Thorn and the very funny and inspiring Bob Galen. They started the morning with a couple of interactive self-organizing tasks that required people to move around the room and order themselves based on various predicates. This did break the ice a bit more and allowed the speakers to gauge the level of “agile” experience the people in the room had. To my surprise, only a handful of people had more than five years of experience. So for me, it was mostly a nice summary of reminders of things I must have heard before but forgot in the wake of time.

Best practices don’t exist and patterns can never be understood without understanding the context. But if there are any anti-patterns that always apply regardless of context, I agree with Bob and Mary that trying to “do agile” instead of “being agile” is one of them. It’s all about adopting a mindset and most definitely not about adopting a methodology or tool. It’s an organization-wide transformation that affects all management layers, in particular middle-management. Bob specifically warned us about the folks in that layer. With exceptions, they often feel uncomfortable with moving away from traditional command-and-control and sometimes tend to (unconscionably) undermine the agile adoption process. If you’ve ever seen a project manager turn into a product owner, you know what I’m talking about.

They also shared a couple of tips & tricks to smoothen the agile transformation. For instance, holding the team responsible for their work, rather than the individuals in that team is something that we all know we should be doing. If things go well, reward the team and celebrate the success. If things don’t go so well or teams are relatively inexperienced, consider shorter iterations so they have more opportunities for reflection. But don’t fallback to a blaming mode. Also make sure you foster innovation and create enough slack time for people to breath and rethink their work. To reinforce this thought, Bob quoted Tom DeMarco by saying that slack is the degree of freedom in a company that allows it to change. If you think about this a bit deeper, you must agree that that’s a very powerful statement.

For the individual leaders in this transformation, Mary and Bob had a lot to say as well. They believe that being a good leader requires you to stop telling developers what to do. Supposedly, every time you do that, the developer looses a little bit of their soul. Instead, they want us to start inspiring people and mentoring them by telling stories and sharing experiences. And instead of pointing developers at their mistakes, they wants us start coaching people by asking questions instead of offering solutions. In a way Bob wants us to become “why”-leaders. But he also wants us to be trustful and providing the team with support when they ask for it. And being trustful doesn’t mean you just observe from a distance. It’s perfectly fine to verify that they are using that trust wisely. Just don’t do it too often. It also means you should actively give the developers feedback and coach them in areas you consider them weak. But it’s all based on a pull-model, so the developers should come to you for help. Bob’s rule-of-thumb is that is what should happen in 95% of the cases. You only have about 5% to push things into the team. And lead-by-example, or as some say, walk your talk. The culture of any organization is shaped by the best behavior the leader is willing to amplify…

What do you think? Is this the way you lead your teams as well? Or is your manager doing this already? Let me know by commenting below. Oh, and follow me at @ddoomen to get regular updates on my everlasting quest for better solutions.