The Case of the Missing Visionary
September 16, 2008
Commentary on The Art of Agile Development's Vision practice.
I talked with a client recently (we'll call him "Andy") about one of his teams' approach to agile planning. "It's going well," Andy said, "even exposing some underlying problems."
That piqued my interest, and I inquired further. "We've discovered that we have a lot of requirements thrashing," he said. "We think the requirements are ready, but then we discovered they aren't. Our old approach hid this problem, so I'm glad we found it."
I was happy to hear that they were discovering problems, but the thought of requirements thrashing sounded an alarm. I like to see cross-functional teams working in simultaneous phases, so the idea that one person fleshed out the requirements, got them to "done," and then handed them to the rest of the team didn't sound right. I dug further.
It turned out that the person passing on the requirements (call her "Beth") wasn't the actual source of the requirements. Instead, the actual source of requirements ("Charlie") was someone who worked part-time in another state. Charlie had a lot of other responsibilities, so Beth couldn't get much of his time--not to mention that he worked part-time and they didn't meet face-to-face. No wonder the requirements were never quite right.
What we had here was the case of the missing visionary. Charlie was widely respected and the ultimate visionary for the product. He knew the market backwards and forwards and everyone trusted him to come up with the product direction. He was too valuable to devote to the project full-time, though, so Beth became the team's de-facto product manager.
As often happens in these situations, though, Beth didn't have the information or authority she needed to be an effective product manager. She was smart and capable, but everyone knew she wasn't Charlie. So the team thrashed. Requirements were ready a day or week in advance--not slowly enough for the team to sit on their thumbs, but slowly enough that there was no overall roadmap or plan.
"In this situation," I said, "I would watch out for 'Agile Thrashing.' In other words, your team makes steady progress, but when you look back at the work they've done, it doesn't form a coherent whole. You end up shot-gunning a bunch of little ideas rather than making progress on any big ideas."
Andy agreed. "In fact, we're already seeing that problem. But I'm not sure what we can do about it."
He raised a good point. Andy knew what he could do, but, as often happens with Agile problems, fixing the problem requires getting people to think and work differently, and that is a much more difficult challenge than it first seems. In this case, there are several possible solutions, but none that are politically easy.
The most straightforward solution to The Case of the Missing Visionary is to put him on the team. Poof--problem solved. Except that it's not so easy. Visionaries' time is hard to come by. Still, it's the best option if you can use it. When you think about the cost/benefit tradeoffs, don't forget to factor in the opportunity cost of misunderstandings that cause the team work more slowly and sometimes build the wrong thing.
A much easier approach, but still politically sensitive, is to separate the role of visionary from the role of product manager. In other words, give the on-site customer authority over the product direction and roadmap, and have her use the visionary as a resource rather than deferring every decision.
(When the on-site customer isn't qualified to play the role of product manager, you'd have to bring someone else in. The point, though, is that you make sure the product manager can devote her time to the team.)
The easiest solution of all is to do nothing... to wait and see what happens. Believe it or not, this can be the most responsible approach. Sometimes pushing for a solution when people don't see a problem can be more disruptive than the problem itself. People need to see a problem for themselves before they'll consider solutions, and sometimes the product is mature enough, or small enough, that a bit of meandering isn't worth the cost of fixing it.
So what would you do? The Case of the Missing Visionary is incredibly common. If you've had an agile project, you've probably experienced it to some degree. Which solution is best for you?