Anyway

Some­how I missed the news about Google’s Pro­ject Oxy­gen earli­er this year. This was a large pro­ject that meas­ured what skills the most effect­ive man­agers at Google use, and the pit­falls poor man­agers fall into. As one might expect from Google, the res­ults are but­tressed by a ser­i­ous amount of data: over 10,000 answers about 100 vari­ables. If you work for any­one, or man­age any­one, it’s worth read­ing about, even if what you do isn’t in software. 

What I found inter­est­ing was this quote, from https://www.nytimes.com/2011/03/13/business/13hire.html:

“In the Google con­text, we’d always believed that to be a man­ager, par­tic­u­larly on the engin­eer­ing side, you need to be as deep or deep­er a tech­nic­al expert than the people who work for you,” Mr. Bock says. “It turns out that that’s abso­lutely the least import­ant thing. It’s import­ant, but pales in com­par­is­on. Much more import­ant is just mak­ing that con­nec­tion and being accessible.” 

It’s been recog­nised for some time in oth­er busi­nesses that the skills required to be a good man­ager are not neces­sar­ily the same as those needed to do good tech­nic­al work. I’m glad to see the data com­ing from Google to sup­port the notion that good soft­ware pro­ject man­agers do not have to be tech­nic­al enough to be lead developers (although they do need to have enough tech­nic­al skills to know what’s going on).

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.

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.