We have a development culture that says developer work is ideally directly associated with a user story. And that more or less any developer could work on any user story.
We like to think that if there are technical problems they will be solved by the developers on the user story that is encountering the problem. Technical problems include things alien to the actual user story: tooling and IDE plug-ins, code and project organisation, continuous integration requirements, and deployment complexities.
Implicit in our arrangement is that any developer should be able to solve any of these problems. That isn't the truth for us.
In reality not all programmers are equally able to solve all the problems we face. We hire developers after testing their programming and design skills, and we pay some attention to their interpersonal skills and customer focus. There's a lot of stuff we don't test for, and if we have better than average skills with that other stuff then it's luck not planning. And we have made some poor quality systems that hold us back because of it.
Our CTO says that we are a group of generalising specialists, which to me means we should be first of all specialists who can also serve in general roles. I think that's an aspirational statement: we don't look for specialists and our hiring process wouldn't favour them. Similarly if you go with the flow of our development process you'll become more and more generalised. So far as I can see our baseline is generalist.
And yet we do have developers among our number who are interested and able to do well at many of these things that are problematic for us. Specialists and people interested in specialising.
So my puzzle is how to maintain our user story focus, because I'm proud of that at the end of the day, but also how to encourage developers to usefully pursue their interests and apply their particular skills where they add value. Genuinely, how to be what my CTO would like to say we are, specialists who can work in general situations.
Frankly I don't want to feel vaguely guilty when I say that I don't like some of the stuff I do, and I don't want to feel guilty for doing the stuff that I do like when it adds value. I want to feel allowed to add value rather than just ticking off story cards.
I imagine a situation with developers respected for taking some hours of the week to step away from specifically story centred work and giving attention to technology questions that they particularly care about.
When I say step away, I mean this literally. For my own part I get up from my regular work when I hear people having trouble with the front end and go and get involved. Sometimes I just listen in to understand new things. Sometimes I actively contribute. Sometimes other people call on me to help. Sometimes I identify problems and go fix them myself. It's not all of my time, it's not as much of my time as I'd like, but I enjoy it and it's good for overall productivity.
If that's valuable and it's just me then it's a company vulnerability: we miss the opportunity to get value from efficient use of specialist skills. Also, I'd love people who have big ideas to have a sympathetic forum to share them and also to be informed balancing opinions for big decisions. So I'm thinking about working groups (my CTO wants advisory groups) intended to satisfy those roles, shouldering the load together and encouraging each other to better, without being a drag on our growing development team. Let's see how it works out.
I should say, the simple words "Working Group" are important. "Group" because I don't want specialisation to promote single points of failure. And "Working" because it's about actually doing the work we see needs doing rather than feeling we shouldn't do it because it's out of story.
No comments:
Post a Comment