I think a lot — and I mean a lot — about methodologies for software development teams; it’s part of my job and it’s a part that I haven’t exactly relished over the course of time.
Back when I worked at the university, I struggled getting people to understand the importance of methodology — which is unsurprising as most of the people I worked with were doing the kind of things that have a tendency to disappear as soon as someone who has heard of methodologies involving automation turns up. It was, alas, not so for my former workplace, there was an almost pathological desire to keep the status quo and only acquire “solutions”, rather than finding them. This kind of thing made my move to my next workplace inevitable.
At Big Oil & Co., I was introduced to the heavy-handed methodologies favoured by the likes of Big Oil & Cos. To be honest, I had no qualms accepting the approaches they choose and I think that my naïveté lead me to believe that the other people I was working with took them seriously. As it turned out, the methodology was largely kept to reports in meetings, while the rest of the gang did their own thing. Indeed, due to want of actual methodologies we could apply locally, myself and my team leader invented a way of doing test-driven development that slowly spread out to other teams.
Moving on from Big Oil & Co., back to the university, I took the lessons of how really not to do things and tried to do the reverse with my old colleagues: softly-softly and explaining things in a way that made it self-evident where there was a benefit to be had, rather than imposing a regime. Part of the point of working in this way was to introduce the benefits of structured approaches to work at the same time as adapting the way we were working and our view of the methods. This actually works quite well — in fact, I’d say it’s the only approach that works. Take a known methodology and apply it to the context, taking constant feedback and adjusting things.
After having moved to a new workplace again, new methods showed up — some smart, others less so. Heavy-handed versus lightweight is one aspect (the former just doesn’t work); a more interesting aspect is how the methods are presented.
As someone with quite a bit of experience doing things with groups of people, I can illuminate those that believe being a bit of an arsehole is a good, pedagogical way of introducing methods: it isn’t. Neither is being distant.
You’ve read a book and that’s great. You’ve worked on a project where you used Jira — hell, yeah. You’ve heard of XP, Kanban, Scrumban or some other irrelevance. This isn’t going to cut it because you need to apply a broad knowledge of methods and human behaviour to the task of getting the team to where it needs to be in order to get the individuals functioning together.
And this is the point, if any, of methodologies — taking disparate people performing tasks and making them work together. I’ve know A-star programmers, who have literally shit in the common bed because of an inability to work with others. If we have a functioning methodology, we can ameliorate the harm caused by personality and habit. We can introduce new team members and get rid of old ones without mucking things up for the project.
I have worked with many people that seem to be immune to methods that don’t originate within themselves; I have tried-and-damned-tried to get supposedly smart engineers to wake up and yet it doesn’t sink in. I haven’t been alone in this endeavour either — teams of people trying to get one person to understand the importance of following the methods…and yet we fail.
Why are these people so immune? Because they haven’t got a clue? Sometimes, but it’s equally true of good programmers with long experience. Maybe the latter category thinks their experience puts them above such tawdry matters, but the crap they produce has to be eaten by others on the team — and you’re really never that good. I’d sooner have two mediocre, cheap programmers that could follow simple instructions than ten kings of development.
So, what to do? Firstly, make it clear in the interviews that WE DO IT LIKE THIS AND IF YOU DON’T YOU’RE OUT. And follow through. If you have management that undermines you, tell them and if they don’t change their ways, leave. There is no point killing yourself with a team that is constantly encouraged to ignore the thing that will keep their efforts glued together.
So, the next time you have a team member tell you they don’t mind doing work without following the methodology or find your develop build broken, but software nevertheless in production…you know what to do.