GANTT, BRUF, GRIT, and You… and The Client too.

These sound like characters from Aesop, no?

Okay, so I am at a bit of an impasse. Problem is, I see value is the Agile approach but I also see the need for something tangible to pass around the conference table. Something like a GANTT chart. I hate GANTT charts. They are one of those things that are too easy to make in a meaningless way that satisfies 90 percent of your stakeholders, but to satisfy the other 10 percent, you have to do stuff I dont think can be done (like, tell the future… and if I could I would not be writing this blog… I would be living off of lottery money and dictating the blog entry to someone).

I am not talking about GANTT charts that show blocks of development or releases or sprints. I am talking about the ones that show development tasks and dependencies and draw a nice line from the beginning to the end. David Christiansen says:

Gantt charts look cool. The ones I can make using MS-Project show task names, durations, assigned resources and milestones. All in color…in whatever fonts and fill patterns I want to use. In my experience, few things about a project proposal impress people so completely as a really nice-looking Gantt chart. Sad, but true.

He is right, and articulated it better than I did (which is why I stole from him). Thanks, David.

ASSUMING you have adopted some flavor of Agile, you could of course produce these charts with a lot of wiggle room by organizing them in blocks that are understood to be malleable. However, this is not what a GANTT chart is supposed to be. At least, not classically. I am all for breaking new ground, but the 10 percent I mentioned before will be of two types:

1. Where is the detail?
2. Why are you making GANTT charts?

In case (1), they will also want to know “how much and when”. In case (2), they will want to know how much and when but understand you are not building a shed with supplies from Home Depot.

You will have to read what Ambler says about GANTT charts in this cached page, but to save you the trouble, he came to find they are regarded as the least valuable project asset.

I am a fan of educating Clients. Agile works, although for me it can be a bit cowboyish without a good leader on the team. Accordingly, I try to be that leader and explain THE PROCESS without sounding condescending, preachy, or singing. I tend to break into song when discussing THE PROCESS. It is majestic, afterall.

Recently, I learned a nice lesson, again (and this time it will stick, truly). Education is great, but among the people you are educating needs to be the person who sits at the conference table waiting to flip out when what may be perceived as ambiguities cost money. It is not even education, now that I think about it. It is more explanation. So, THE EXPLANATION needs to reach the right ears and mind. THE EXPLANATION makes sense. THE EXPLANATION is no good if it is on some random PM’s notebook and the CFO says, “I need to know when this project is going live and how much it is going to cost by end of day! Why don’t you know this? And dont give me that EXPLANATION!”

Because that happens.

A lot.

So again, this stuff all starts with people, not technology, and not THE PROCESS. It might not always be easy to do, because the people at the conference table are often busy, but you really need to reach them, even if indirectly.

GANTT charts are also BRUF and detailed specifications for System features that are a glimmer in someone’s eye. Now, maybe BRUF is bunk, but RUP, or better, what has been termed GRIT, has value. Even if you are going into a cave and know you dont know which way it will twist or turn, you bring a flashlight and good boots (I guess… I dont know much about spelunking).

The idea of GRIT is that an integral part of delivering great software is delivering a great requirements model. Rather than trying to completely document the requirements in one big effort early on, the GRIT approach looks at modeling as an iterative process that runs in parallel, but slightly ahead of, the agile development iterations. Early in the project the requirements are typically not well understood at any level of detail but the business objectives should be clear. As the project proceeds through the initial iterations the high level requirements should tie directly to achieving the business objectives. Each subsequent iteration should add to the model, adding detail and precision to the requirements, ‘just in time’ for development. The end result, along with great working software, is a great requirements model.

So yeah, GRIT is what you have probably been doing, but didn’t know had a cool acronym.

And that’s that for today.

Best,

Josh