The course on Communicating with Management given by Tom Gilb finished Friday. As is usual with such courses, the material he wanted to cover on the last day was more than the allotted time afforded so it was a bit rushed at the end. However, all in all, the course was profitable for me and, I’m sure, for the rest of the delegates.
Interesting points:
- One of the delegates was disruptive in a major way. I’m sure you’ve all been in courses or classes where one or two people ask questions incessantly, not particularly to gain any further understanding but really to show off their erudition, education, or experience. These people are the main cause of classes running over, I believe. Tom was fairly deft at parrying this guy’s questions but I think we would have had about an hour more if the guy had just kept his big fat bazoo shut.
- While the course was fascinating, one of the things about Tom Gilb is that he’s been around the software development arena since 1958. He worked for IBM for a few years, and has been an independent consultant since then. Fifty-two years of working has gifted him with a fund of war stories, most of which end by Tom either saving the day or by Tom being ignored, with a major catastrophe for the client ensuing. So, in a way, all the courses Tom gives are about Tom Gilb. This is not necessarily a bad thing, but I would like to hear about some times when Tom tried to do something and failed at it. A long succession of successes doesn’t teach you much, while one instructive failure can bring a lot more insight into a subject.
- I should thank TSG for making their classroom available for free for an entire week for this course. Not many training organisations would do something like that.
- The major reason for software (or any) projects to fail is, in Tom’s opinion, is Prince II, the management method adopted by the UK government and large corporations. You can get certificates in it, take training in it, but when applied to projects it produces a mountain of paperwork and usually unsatisfactory results. Tom’s method is to determine requirements, produce a metric by which to measure them, do a reasonably accurate estimation, and then chunk the project up into iterations of about 1 a week (no more than 2% of the total effort), where each iteration delivers value to somebody. Each of these iterations is estimable, but estimates become clearer nearer to the time when the iteration occurs. This is, of course, an oversimplification. He has created a planning language called planguage in which all this planning and engineering is written. His book, Competitive Engineering, gives a much more comprehensive (and very dense) treatment of the subject.
- He claims, and I have no reason to doubt it, that his methods (which have been around since the late 1960’s/early 1970’s) were drawn upon by Kent Beck in the development of Agile, Extreme, SCRUM, and other forms of evolutionary and cyclical software development methodologies. Apparently he has written statements from Beck and some other people to this effect. I think he was probably the first.
- His major problem with Agile, Extreme, and SCRUM is that, rather than aiming at delivering value on each iteration, these methods aim at delivering lines of code (the “burn rate”) or chunks of program but not necessarily value with each iteration. Gilb’s Evo method is planned so that every iteration produces something of value for some stakeholder(s) in the project.
- His website has a multitude of interesting documents on this and many other subjects.
I caught up with my chum Steve, who is still unable to offer any work, despite the work being just over the horizon for years. He was on the course and will be on a similar, shorter, more technical course next week with Gilb.
I look forward to reading the Competitive Engineering book and perhaps gaining some insight and useful tools for both project planning and general life planning—he gave examples of where people used his planning methods on life goals as well as project goals.