On Improvement, Or Teams and Process

I sometimes find it funny.  I mean writing a blog and posting ideas and getting comments or seeing who agrees or disagrees via twitter and other "networking" sites.

My last post, on team building, had a reasonable number of hits from unique locations, garnered a few tweets/re-tweets and one public comment. I also got a couple of emails from people I know that essentially said (paraphrasing) "We need to assign people to jobs they want to do? What if we end up with three people on one function and functions with no one assigned to them?  That's crazy! You can't operate that way!"

I kind of blinked and thought to myself, "Is that what I said?"  So I reread that post and thought about it.  I can see where someone might take that away as my point.  And still, I don't really think that was what I said.

Consider this.

When talking about process improvement, particularly test process improvement, I say flat out that no cookie-cutter model will work in every shop and then will rarely work for every project in the same shop.  To be able for a team to test effectively, someone must have a decent understanding of what the individuals on the team are capable of doing, what they are good at and how well they work together with other individuals on the team.

When you have some idea about the individuals, and you can look at the overall team's work (essentially looking at what the team as a whole is good at) then you can look for ways to optimize the strengths.  If you can off-set weaknesses with strengths and make the areas of less-than-optimal performance a little closer to where you'd like them to be, you can free more time and resouces (like money and training/reading material, not people) to grow your whole team's capabilities.

Pairing testers where one is stronger in certain areas than another and allowing them to learn and develop skills while doing them, is one way to spread the workload and allow testers to experiment with mentoring other testers.  It can also help develop a closer sense of teamwork and encourage people to turn to other testers for help, if they are not doing that already.

I have found no way to do those things without getting to know what the team members like to do, want to do and are good at doing. 

I know we can't always get the fun tasks - the ones we really like doing.  We can, however, learn about other things, or maybe find ways to improve and get better at the un-fun tasks.  I know for me, some of the things I really find un-fun are the tasks I feel less than comfortable with.  Yet as I learn more, those un-fun, scary, frightening things, the ones where I am an absolute novice at, are also the ones that as I learn more, and become better at, become more fun than un-fun.

I think that is the key right there.  If we want to get better, sometimes we need to work on the un-fun things and learn about them.  The team leader (manager, whatever) may have some idea of what the "fun" tasks are, but if each individual on the team has a different idea of what those fun tasks are, it is almost certainly going to lead to an un-fun experience.

Team leaders, I suspect that if you look, ask, talk and communicate with your team members, you'll find their idea of fun tasks and what they like doing and what they are good at will tend to be the same things.  I exoect the same thing will be true with the the un-fun tasks, what they don't like doing and what they are not very good at will probably be the same.

By making the pool of un-fun tasks small for the individuals and the team, by getting the team members to expand their skills, I believe your core testing wull improve.  I likewise believe your core team work and cooperation will improve.  Finally, I believe your team's morale and sense of working together, their joint craftsmanship, will improve. 

Those things will tend to improve the testing your team does.  Then everyone will have more fun.