I’ve had a couple of interesting comments on my piece about Coding vs Non-Coding Project Managers; in my case it was the way things worked out rather than a deliberate choice.
After my degree in physics, and a couple of years of post-doctoral work (which involved some computer stuff, of course) I got post-graduate diploma in information management that included all the good stuff such as database design, unix systems administration, transaction processing, C, etc., etc. And then went to work for a small SGML document consulting house doing, amongst other things, the motif interfaces for a document retrieval application, schema design for dictionaries and encyclopedias, and other related work. I ended up doing more of the customer-facing work, and less of the back-room coding, mostly because I was better at it than some of the other people who worked there, good at talking to the customer and taking their requirements back to the developers, and good at translating the developers’ concerns in terms the customers could understand.
When I got to SoftQuad, the idea was that I’d spend 50% of the time coding, and 50% doing other useful stuff. The other useful stuff, as is its wont, grew. As an example, when we localized HoTMetaL Pro, I was the one working with the translators to make sure the strings made sense for the context. I checked the German ones myself since I speak fluent German and worked with a French-speaking person on staff for the French ones. I worked with the Adaptive Technology Resource Centre on ways to make the program accessible, as well as figuring out the best way to incorporate accessibility checkers to encourage users to make the HTML accessible. I represented SoftQuad on many W3C and OASIS technical committees, bringing back the results of committee discussions to the engineering team and trying to make sure the committees did the right thing without making it more difficult for us to implement. I coded demo scripts and taught tutorials on how to use the macro system in XMetaL, but that was the extent of my programming. 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.
One of the things Scrum promotes though is for the programmers to interact with the customer, not to issolate them away, which I think was lost in your prior post. You want them interacting so they can gather just enough requirements to get that particular user story implemented. Gathering the requirements and feeding them to the programmer is not the best way to promote this interaction. In fact the product owners and those that are potentionally using the product should be involved during the sprint to provide early feedback. Customers can’t change the requirements until the end of the sprint. I agree though that the Scrum Master should not be a coding on the project. They have to deal with the issues that are keeping the programmers from getting their job done. (i.e. no build machine, so they can’t get reliable feed back, product owner that wants to look over their shoulder, etc).
Hi David, I agree with most of your points, but there are a couple of nuances that I think are worth pointing out. In many cases the product owner represents rather than being one of the end customers (this is what many companies call product managers). It’s often not feasible to have the true end customers directly involved in the sprint; you need a proxy or representative instead. Where it is feasible, you still need to be careful that the interaction sticks to the rules you pointed out, and that early feedback is distinguished from changing requirements. This can get tricky at times 😉 and a good facilitator (aka Scrum Master or project manager) helps.
I ended up doing more of the customer-facing work, and less of the back-room coding, mostly because I was better at it than some of the other people who worked there, good at talking to the customer and taking their requirements back to the developers, and good at translating the developers’ concerns in terms the customers could understand.
That’s pretty much what I do for Google now, except our customers are other in-house teams. Consequently I’m that currently unique thing, a developer-relations specialist who doesn’t work for Developer Relations (which deals with outside developers).
[…] Lauren Wood blogs at laurenwood.org […]