Category: Technology

I’ve had a couple of inter­est­ing com­ments on my piece about Cod­ing vs Non-Cod­ing Pro­ject Man­agers; in my case it was the way things worked out rather than a delib­er­ate choice.

After my degree in phys­ics, and a couple of years of post-doc­tor­al work (which involved some com­puter stuff, of course) I got post-gradu­ate dip­loma in inform­a­tion man­age­ment that included all the good stuff such as data­base design, unix sys­tems admin­is­tra­tion, trans­ac­tion pro­cessing, C, etc., etc. And then went to work for a small SGML doc­u­ment con­sult­ing house doing, amongst oth­er things, the motif inter­faces for a doc­u­ment retriev­al applic­a­tion, schema design for dic­tion­ar­ies and encyc­lo­pe­di­as, and oth­er related work. I ended up doing more of the cus­tom­er-facing work, and less of the back-room cod­ing, mostly because I was bet­ter at it than some of the oth­er people who worked there, good at talk­ing to the cus­tom­er and tak­ing their require­ments back to the developers, and good at trans­lat­ing the developers’ con­cerns in terms the cus­tom­ers could understand.

When I got to SoftQuad, the idea was that I’d spend 50% of the time cod­ing, and 50% doing oth­er use­ful stuff. The oth­er use­ful stuff, as is its wont, grew. As an example, when we loc­al­ized HoT­Met­aL Pro, I was the one work­ing with the trans­lat­ors to make sure the strings made sense for the con­text. I checked the Ger­man ones myself since I speak flu­ent Ger­man and worked with a French-speak­ing per­son on staff for the French ones. I worked with the Adapt­ive Tech­no­logy Resource Centre on ways to make the pro­gram access­ible, as well as fig­ur­ing out the best way to incor­por­ate access­ib­il­ity check­ers to encour­age users to make the HTML access­ible. I rep­res­en­ted SoftQuad on many W3C and OASIS tech­nic­al com­mit­tees, bring­ing back the res­ults of com­mit­tee dis­cus­sions to the engin­eer­ing team and try­ing to make sure the com­mit­tees did the right thing without mak­ing it more dif­fi­cult for us to imple­ment. I coded demo scripts and taught tutori­als on how to use the macro sys­tem in XMet­aL, but that was the extent of my pro­gram­ming. Everything else took enough time that by the time I left SoftQuad after 7 years, the joke was that I owed my boss 3.5 years worth of coding.

In my post­ing about becom­ing a Scrum Mas­ter, I talked about teams with non-cod­ing pro­ject man­agers often being more effect­ive than teams with pro­ject man­agers who also code. It seems that that’s a minor­ity view; most com­pan­ies appear to assume that any pro­ject man­ager should also act­ively code. I agree that any pro­ject man­ager in the soft­ware industry should have a cod­ing back­ground; if you haven’t been in the line of fire for a cus­tom­er deliv­er­able, or a demo for a con­fer­ence, then you don’t under­stand the needs of the coders on the team. You also won’t under­stand when they’re pulling the wool over your eyes, or mak­ing excuses because they don’t feel like doing some bor­ing but neces­sary task.

In a mid-sized to large com­pany, a pro­ject man­ager does the bor­ing stuff, talk­ing to leg­al about copy­right or licens­ing (for open source pro­jects in par­tic­u­lar), talk­ing to sales people about when the pro­ject might become a product they can sell to their cus­tom­ers, mak­ing sure the vari­ous parts of the team not only talk to each oth­er, but under­stand each oth­er, and mak­ing sure the vari­ous parts of the pro­ject mesh togeth­er. A pro­ject man­ager makes it pos­sible for the team to work as effi­ciently as pos­sible. This might mean shield­ing them from a man­ager who wants to change require­ments every day (one of the good things about Scrum, BTW, is the sys­tem for mak­ing sure that does­n’t hap­pen), or schedul­ing the secur­ity reviews for the right phase of the product design and release cycles.

In a small com­pany, the pro­ject man­ager is often also the product man­ager, doing all of the above as well as talk­ing dir­ectly to cus­tom­ers, tak­ing part in online dis­cus­sions, attend­ing con­fer­ences, and tak­ing part in rel­ev­ant stand­ards activities.

All of these are neces­sary activ­it­ies, and they all involve meet­ing with oth­er people, wheth­er in per­son or via some oth­er com­mu­nic­a­tion mech­an­ism. They aren’t tasks that require you to shut your­self away and think for hours, unlike, say, design­ing the serv­er-side archi­tec­ture, or hunt­ing down a recal­cit­rant bug. Paul Gra­ham recently wrote a rel­ev­ant piece entitled Maker­’s Sched­ule, Man­ager­’s Sched­ule. Using this ter­min­o­logy, each team mem­ber is a maker. It’s the pro­ject man­ager who takes care of the man­ager­’s sched­ule on behalf of every­one else, it’s the pro­ject man­ager whose sched­ule is inter­rupt­ible. The pro­ject man­ager does­n’t have the lux­ury of look­ing for­ward to a whole day of unin­ter­rup­ted work, the time to get deep in the zone, the abil­ity to ignore the phone and email. A lead developer will get more done, and the team as a whole will get more done, if s/he does­n’t also have to worry about HR issues, or nego­ti­at­ing an NDA, or telling a sales per­son why that large fea­ture for one cus­tom­er can­’t be added between now and tomor­row morning. 

So now I’m a Cer­ti­fied Scrum Mas­ter, or at least I will be once the paper­work is sub­mit­ted and checked. Right now it’s a fairly pain­less pro­cess, you show up to a sem­in­ar, take part in an act­ive way, and emerge at the end cer­ti­fied by the instruct­or. In a few months people will have to do an exam as well, which may or may not be an improve­ment in prac­tic­al terms.

The two-day course was intense and I was glad I’d read up on Scrum first. The book I read was Ken Schwaber­’s Agile Pro­ject Man­age­ment with Scrum; the one recom­men­ded in class (run by Danube’s Jimi Fos­dick) was his Agile Soft­ware Devel­op­ment with Scrum. After a brief intro­duc­tion to the prin­ciples of scrum, we went to work on an immer­sion assign­ment using those prin­ciples. The energy level was high giv­en the com­pressed time frames, all the teams came up with some­thing worth­while, and I for one left with a reas­on­able under­stand­ing of how scrum works when it’s in an ideal setting. 

Which, of course, is the issue. Scrum is not a sil­ver bul­let, and won’t make up for prob­lems in the organ­isa­tion. Mr Fos­dick was care­ful to point out that imple­ment­ing scrum is risky, it tends to uncov­er prob­lems in the organ­isa­tion, and it often fails to give the res­ults com­pan­ies want for those reasons.

On the pos­it­ive side, the Scrum Mas­ter role is very sim­il­ar to what I’ve always under­stood the role of the pro­ject man­ager to be — keep the team mov­ing, get rid of obstacles for them, keep med­dling man­agers or sales people out of the way. It form­al­ises those aspects of the role, and I like the idea of the sprint being a defined length of time, so you can always say to a man­ager or sales per­son that their import­ant item will be taken into account at the next pri­or­ity-set­ting meet­ing on a defined date. One issue that came up in the dis­cus­sions was wheth­er the Scrum Mas­ter should also be a pro­gram­mer. Mr Fos­dick­’s opin­ion was that no, in prac­tice a team with a ded­ic­ated Scrum Mas­ter is, as a whole, much more effect­ive than a team with a Scrum Mas­ter who also codes. The main reas­on­ing was that the Scrum Mas­ter who does­n’t code con­cen­trates on get­ting imped­i­ments out of the way of the team, keep­ing track of pro­gress, and think­ing of ways in which the team per­form­ance can be improved while the Scrum Mas­ter who codes is also think­ing about the code to be writ­ten, how much s/he can com­mit to doing on any giv­en day, etc. This makes sense to me, though I know a lot of com­pan­ies who insist on the pro­ject man­ager also being one of (per­haps the lead) developer on the team. If that con­fla­tion of roles works, there’s no reas­on to change it. If it does­n’t, it’s some­thing to think about. I know in my work as a pro­ject man­ager, I’ve always found there is lots to do without also being respons­ible for deliv­er­ing qual­ity code as well.