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.

Back in My Day: Confessions of a Curmudgeon

When I first got into software for a living, the idea of "structured" anything was the red-hot burning idea that was going to save software from the horrible/bad/evil practices of people who were inept/wrong-thinking/clue-less practitioners of hocus-pocus.  Structure was going to save us.  Then it was CAD.  Then it was Object Orientation.  Then it was blah, blah.  You get the idea.

I heard some folks talking about some "New Ideas" that they had heard about.  Fantastic ideas, I thought.  Instead of centralizing everything on a host server, they could have servers in a bunch of different places and have them all talk to the host.  Then response times would be faster and the users would be able to get faster response.  Astounding, eh? 

Anyone else remember that new idea from, oh, 20 years ago?

Wait, that is sounding really, negative. 

Let me try again.

Back when I was heavily involved in bagpipe bands, there was an amused expression that was reserved for folks who had been involved in pipe bands some years before, and no longer were/

"The older I get, the better I was."

The fact is, people's perceptions will change over time as our experiences inform those same perceptions.  In the pipe band world, it seemed to inflate what the abilities were.

In reality, I have learned, now that I am part of the same "club," is that some folks really REALLY don't like change.  Change in any form is bad.  At the same time, things change as they grow, or they wither and die.  You can't maintain existence without change.  Well, maybe you can, but it is not really existence, it is a museum display - almost a "living history" lesson. 

Change is inevitable. 

Once it was suggested that since I was so "set in my ways" I may not like the changes that were coming and I could have a hard time adapting to them.

I resisted the temptation to look around for my cane and wave it about calling that individual a "young whippersnapper."  For one thing, I don't use a cane or a walking stick.  For another, I sympathized with his perception and lack of life (and maybe professional?) experience that would lead him to say that. 

The thought that crossed my mind was "It is this very experience I have that allows me to see how he could have a view like that.  I have been around a while and I like things a certain way.  I have liked things in different ways before that, too.

When comments like the above are made, or when I think on change and flexibility, my mind sometimes wanders back to the companies I have worked for, the shops I have worked in.  No two were the same, even remotely.  Some were happier than others.  Some were more efficient than others.  Some turned out really good work.  Some were just jobs. 

Some are examples of the same things I mentioned before.  My own experiences shaped my perception of each of those organizations.  As I learned more, I wanted to learn more.  My views changed related to that job as I was working there.  I learned and experienced different things in different areas.

What does all this have to do with anything, let alone each other?

Well, simply put, I read a blog entry by The Maestro a couple of weeks ago.   My first reaction was "YES! EXACTLY"  Then it made me think on some things.

What I discerned from that thinking is that each of these "revolutionary ideas" was intended to address a problem.  Or at least, a perceived problem.  The thing is that many are just that - perceived problems.  I think the real cause is that people, myself included, don't want to do the painful self-examination that is required for real improvement.

It is easier to follow the herd and the glossy marketing people when they hold out a promise than it is to dig down and work on the problem we have.  This leaves us the desperate grasping at the just-out-of-reach silver bullet.

This is, I suspect, the core issue with all the trends over the last 30 years in my experience, and more.

Unless you are willing to face and address your real problems, you will never fix them and will keep grasping at quick-fix solutions that are not.

Well, maybe I'm just being a curmudgeon.