The Agile Consulting Magic Act
This week, after several months at home writing, blogging, and working my startups, I’m back at BigCorp doing some agile consulting and meeting some great folks. I’m helping out with Scaling Agile using SAFe and making developer’s lives more fun and productive. Because I’ve been gone so long, it provides me an opportunity to look at things with fresh eyes.
The guys I’m working through are tools experts, so naturally when questions come up like “How do I know when this will be done?” they answer something like “Once the tool is installed and you put the data in, it’ll be right here on this screen.”
This is both correct and incorrect. Yes, it’ll be there, but the real question was probably something more along the lines of “How can I observe and influence when this will be done?” In that case, the tool serves only to communicate, and only after the data has been entered. The real work is happening in the team room, where organizational constraints and personalities are creating and solving difficult problems, many of which will never ever appear in any report.
Likewise, I was asked to talk to a team about Agile. During our conversation, I realized that scoping was an issue. How does the backlog change? It appeared to me that the Product Owner was only an observer; it was effectively un-scoped. So as I identified this as an issue, I started describing how to write features and epics so that they could be tested, and that would decompose logically and keep scope in check. Next I was going to describe how the Product Owners and Product Managers worked.
“But that’s just Agile stuff.” the guys said. “We need meetings and organizational structure!”
Of course, they were right: all I was doing was saying that once you scoped the project, the project would be scoped. Not very helpful. But they missed it as well, because their formulation was something like “Once we are organized so that we are communicating well and coordinating our activities, our activities will be much better coordinated and communicated.”
What are we all doing? We’re doing what comes naturally to us. We are confusing something that we can get a handle on and understand — tools, process, or organizational structure — with something that is completely out of our control — the decisions people make and the way systems of people evolve on their own.
I’m reminded of an old joke. A couple of guys in Washington state go for a balloon ride. The winds were strong that day and soon enough they found themselves completely lost. As they floated over a tall building, they saw some guys on top. They yelled at the guys “Where are we?” and the guys yelled back “In a balloon!” So one guy says to the other, “We must be over the Microsoft building” “Why?” “Because that answer was true yet totally worthless”
But the cool thing is that all of us were doing the right thing: working around the problem in order to find a solution. People are not stupid, and many times when you set up a program or project it’s immediately clear what the people-problems are. Joe and Sally don’t agree on much, Jim and Sue solve problems in a completely different way, Bill is totally OCD, analytical, and cold, while Nancy is the best artistic, creative, unstructured thinker we have, and so on. People immediately figure out where there are going to be personality issues, everybody digs in, and the game is on. People misconfigurations — and this is another way of saying “communication” — is the number one problem on any project larger than 3 people. Note that this is not an issue of who’s right and who’s wrong. That doesn’t come into it all. It’s all about communication and honest, respectful, direct conversations.
As consultants, looking at these situations, many times we work some other problem like tools, process, or structure. Working on another problem, if done well, allows us to address the communications problems in an indirect way. If done poorly it just leads to a big waste of time for everybody.
In this way, good consulting is like a magic act. We direct attention elsewhere while we work the problems out in a way that’s not obvious. People are all looking at tools, org charts, schedules, or information radiators and meanwhile the communication and hard conversation problems are smoothed out and things begin to hum along.
The sad thing is that, like any magic act, the people watching when it works great have no idea how it happened. They were looking the wrong way. There are a lot of companies out there today thinking that if you just get a couple sexy girls in bikinis, a funny handsome man in a suit, a box, and a saw, you can start sawing people in half. Heck, there are probably a lot of people getting sawed in half while you’re reading this.
I’d argue that the soul of Agile allows us to understand this. People first. Technology development is foremost a social problem. Communication and flexibility allow us to work better and happier. But even then, we still work the problems like we’ve always done; misdirect and facilitate. In a way, as good as all of the Agile practices are, they are only good when they allow us to identify and solve people problems. If we focus on the rituals or artifacts, we’ve missed the point entirely. Agile consulting, like other forms of true consulting, is a bit of a magic act.
July 27, 2012