Tuesday, September 26, 2006 

Quadrants

I use quadrants a lot. Quadrants help simplify complex situations, which in turn helps devising overall strategies. Sometimes quadrants are guided by measures (e.g. Cyclomatic Complexity Vs. LOC), sometimes by intuition. Of course, in order to be useful, you have to pick the right axis for the problem at hand.
A few days ago, I was consulting on a troubled project. Progress is slow; we don't have enough people. Senior developers are in Italy, but they're too concerned with other projects to help on this one. We have [mostly] junior resources in India. There is an overall optimistic plan, but reality is not going according to the plan :-).
The only viable path right now is to grow the team in India, adding senior and junior developers. However, this won't help unless we radically change the plan. We need a complete reordering of activities. Here is the most useful quadrant for this project:

Each task is a point inside one of the quadrants.
On one axis, we have the dominant complexity of the task. Some tasks are dominated by the business complexity. Some by technology complexity.
On the other axis, we classify the dominant force as stable or unstable. Someone may complain that there is no such a thing as a stable task, but that's simply not true. We may have instability at some granularity level, but we always have several stable decisions. Stability may be on the technology side (when the dominant complexity is technology) or on the business side.
Now, why does this help with re-planning? Because the original plan was built around senior developers, with significant exposure to this particular business and several (up to 20) years of programming experience. So, the original plan tackled several unstable problems from the very beginning, as part of an exploratory phase + risk identification strategy.
This is very different now. [Mostly] junior programmers, with limited exposure to the business, structured in a delocalized team can't follow the same plan. Note that it's not a problem with the new team: it's a problem with the old plan!. Anyway, we need to gain momentum on this project, and that means immediate, useful progress.
Now, the simplest tasks for any programmer are the technology-centric. It's much easier to explain a technological problem than a business problem, especially to someone with no experience in that particular line of business. Working with stable technologies may not be so fun, but will give back results quickly. So, we need to identify "quadrant 1" tasks and start from there.
We can't ignore the other quadrants, of course. We have a few resources in India knowledgeable about the business. They'll soon have to take more responsibilities. We need some investments so that they can help with quadrant 3 (starting at the edge between 1 and 3).
Time can help with quadrant 2: the involved technologies will naturally translate from 2 to 1 (or die) in the next few months, so I don't really feel any pressure to deal with them (actually, I feel some pressure not wasting time dealing with them right now).
Quadrant 4 must be handled locally. There is only one guy who can make key decisions about the best way to model some business concepts. We have to make sure that he can actually spend some time on that. Which is another problem, not well suited for quadrants (but just fine for effect diagrams :-).
As an aside, this may (and in fact did :-)) not look agile to someone (as by staying away from quadrant 2 for a while I'm not "embracing change", and I'm also trying to have [gosh!] a detailed plan, and so on). I guess it depends on your definition of agility. In my book, doing whatever is necessary, useful and possible with the resources you can find beats following a recipe (not a plan :-), any time. I'm pretty sure true agile guys would somehow agree with me at this level. Then, we may use different approaches and tactics. I think agility is not in the practices. It's in why you do what you do. Following recipes (that includes TDD, Pair Programming, and whatever else if not carefully considered in context) just doesn't look agile (or plain old sensible ;-) to me.
In this sense, I would even say that I have embraced the biggest change: from a tight team of experts in Italy to a delocalized team that has never worked on similar projects. My plan is entirely based on the new environmental conditions. That's the most important choice at this point in time; but a good plan is dynamic, and we'll steer as the environment changes...
Comments:
I would say this is agility without doubts but I'd rather ask a couple of questions about the issue at hand instead of discussing (again) Agile vs agile. Shall we? :-)

I know it depends A LOT on the project context (internal, external, involvement of the customer/user, etc, etc) but gaining momentum usually is about delivering something the user can give feedback on asap.

If I got your description right I would say this is someting to be found, in order, in quadrant 3 and quadrant 1.

Tackling quadrant 3 with a distributed team and a lack of domain/business knowledge is of course a problem but you say there is someone in India with some business knowledge.

Is this the reason why you've decided to start with quadrant 1 or you don't share my view on quadrant 3?

Thanks
 
The project is rather big and (considering it's the fourth generation of a rather successful system) we won't ship it until we have a critical mass of features. So, we won't have user feedback very soon, although we will have early internal users, as the product is also used inside the company. The bright side is that, being the fourth generation, we already have learned a lot from customers.
In this context, we need developmentmomentum. When progress is slow, developers get easily reallocated to other projects, to "urgent" maintenance tasks, and so on. We need to bring this project up to speed, hence the focus on quadrant 1.
Quadrant 1 won't last forever, of course. And there isn't much "visible" value in quadrant 1 for end-users and marketing (of course, there is a lot of invisible value there). So, we need to build up team confidence on business issues as well, to gradually move people toward quadrant 3. We need to support more the senior guys in India on this issue.
Ideally, I would focus a little more on quadrant 3 from the very beginning, as quadrant 1 is usually less risky. However, this is a peculiar situation, where I believe the "first 1, then 3" strategy will give us more chances of success.
I guess we somewhat agree on the theory though :-). I would say that even "momentum" is highly context-dependent. In corporate development, it may well be defined as you did (gaining early user involvement). For shrink-wrapped software, it's usually more on the "development momentum" side, as many projects tend to compete for limited resources. And then, of course, we have all the in-between spectrum...
 
Post a Comment

<< Home