I have been buying a lot of hats lately. Real hats, and some nice ones too. I have around 22 hats now. But although the average developer only walks to the bathroom, occasionally, and otherwise sits quite still, I think we probably have more hats to wear as software developers.
We know the usual ones, coder, tester, documenter, team leader, mentor, but there are lot of them that we don't really think about that often. All these hats make it hard to understand what methods should be applied to a team of such diverse people, doing such diverse activities, albeit comfortably sitting in a chair. There are other hats we wear.
Miner Helmut
We delve deep into chasms Inventor's Caps
We tinker, until it works. Explorer Hat (Fedora)
We discover things, sometimes it can be dangerous Detective (Deerstalker)
We analyse and find culprits. Events Organizer (Conical hat)
Drinks anyone?
We all have one or more of these roles in us all, and we all like some roles more than others. To find a methodology that will work across this, we have to look at these traits.
For example: An explorer, is often accompanied by a small group of people, specializing in certain areas. A medic, a soldier, a botanist, and a few peons to do some grunt work.
An inventor is usually a loner, who mumbles to themselves a lot, and disappears for days while working on the 'problem'.
A detective, is a very good communicator, and applies logic and analyses to people and things, trying to create abstract connections, to finally trace down the killer. Sometimes just conducting a stake-out, watching the suspecct for hours, doing nothing.
A miner works in a team, and knows he is an important cog in the machine. He is careful and dutiful. He is constantly aware of his fellow miners. He is safety concious, and works hard in hard conditions.
One size fits all?
These kind of traits can be found, often, within the same developer. One developer, has all of these things, and that makes it quite hard to pin down working solutions.
Uncle Bob, in TalkWare, spoke about the Sensei, and the martial arts concept. This too has merit, because there are many people who would love to learn from someone more 'enlightened' than themselves. On the other hand, you get individualists, who are better at leading, than being the humble learner, and everything in between.
The answer my friends, is blowing in the wind. A process must cater for teams that have varying traits. Each company will forever have their own way of doing things. A methodology needs to derive and adapt for teams that want apprenticeships, or martial arts, or even developer peons. However the ultimate answer is having tools that offer guidelines, from really simple to really complex. At each level, you can optionally have more definition. An upside down triangle of methods. Starting with something like SCRUM at the bottom and something like RUP at the top. Something less defined, and easier, to something more defined and expert.
To do this well, we must first understand the people, and then the processes will follow.
Previous Topic
