The raging battle between the process vs non-process people and Michael Bolton’s recent burning issue article got me thinking. If I assume that everyone in the testing field, be it tester, test lead, test manager and the wider software development arena wants to do a good job, why are their points of view so different?
OK, that question is too wide so let’s try again. Why does someone wants to put the process first and someone else the problem first?
In my experience that’s due to at least two major reasons, personality and experience. Let’s look at personality first.
Some people feel trapped by processes and limited in their freedom and abilities. They rely on their skills and abilities and trust whatever comes that they will find an answer even it they don’t know it, yet.
Some feel that with a process and documents in place there is something that they can fall back on to prove that what they’re doing is right. That they can give the process to someone else and that they can then also repeat it providing a base for a bigger group of people to learn from what they did before.
As a test manager I can’t influence people’s personality, that’s why there’s always an amount of touch and feel in any project decisions. Most decisions are emotionally impacted, I haven’t seen people looking at ROI and NOT decide based on their emotional reaction.
For the experience part, someone might have worked in a big, process driven corporation where there was a reason for processes. Or they worked in a small shop where anything goes and only a result counted, any result. I worked in the pharmaceutical industry and research scientist for a good number of years. GLP was a regulation we needed to comply with and if you ever heard of thalidomide you’ll know why that is a good idea. There’s an interesting article for further reading.
Processes were in place to satisfy these regulations. However having done a lot of the "work on the floor" most of the processes just didn’t make sense to me. After working for several years in the IT industry I now understand what they were trying to achieve, but no one explained it to me at the time. But I also now understand why the processes failed miserably. My point is that if you always worked in process driven companies you don’t know any other approach as very often there is a good reason why the processes are in place. That doesn’t mean they’re always working in practice though. I worked with a lot with red tape, ditched it all, and are now coming out the other end being somewhere in the middle.
Most companies want to be able to run a profitable project, have a satisfied customer and be able to repeat that over and over again. So why not putting your working habits into processes? Wrong, no two development projects are the same and a habit is just that. Wikipedia has this for Habit:
Habits are routines of behavior that are repeated regularly and tend to occur subconsciously, without directly thinking consciously about them.
The question is, do we actually want that? When you document a process and don’t want people to think about it but follow it, that’s fine. But when your next development project encounters an unforeseen problem don’t be surprised that your team can’t deal with it as you created a culture where people don’t think about what they’re doing.
I see the clash not between the process vs non-process approach but if you want to invest into training your people so that the whole team understands what’s expected from them and what’s important; or if you think that this route is too expensive and that you rather tell them what to do and have a few “in the know” who are creating the processes.
I think that training or lack thereof is at the root at the problem when we’re talking about processes as they’re often used to mask that people are not trained enough to do their jobs without them. If a developer doesn’t understand that throwing software over the wall to the testers impacts their work this is essentially a training issue. If a tester doesn’t understand what information is essential to the PM this is a training issue. If the PM doesn’t understand what to ask from the developer or tester, you guessed it, that’s a training issue as well.
I gave my 6 year old son a LEGO game, a Star Wars plane with some Androids to assemble. He was able to do that without help using the instructions. When asked if he could do that without he said that it would be quite hard. In other words, he would need to get out of his comfort zone. I prodded him a bit and he assembled the next one without the instructions. Of course that was harder and took longer. But what he learned there will stay with him, he’ll assemble the next one much easier. And the one after that. If he’s always following the instructions he learns exactly that, don’t think, follow the instructions.
In many ways it was easy for him to do something different as he’s a child and therefore constantly challenging his comfort zones and I’m encouraging that. But if that was never high on your parents agenda and your employers don’t expect that from you I can see why following a process is the easy option.
Comments welcome..
Thomas
