Transformational Leadership

I followed two recent Software Testing Conferences on Twitter, Eurostar 2015 (I took part in the mobile deep dive day) and Agile Testing Days.  What struck me was the difference in management styles that were promoted in contrast to what most people experience in their day job.

This blog is about what I perceive to be one of the differences –                Transformational Leaders vs Transactional Leaders.

Starting with the latter the Transactional Leader is the typical ‘stick and carrot’ type. The goal is compliance promoted through rewards and punishment. The emphasis is on maintaining the status quo by rooting out apparent faults and deviations from the process driven way of working. Apparently this is supposed to work well in a crisis, same as micromanagement, I do have my doubts.

The goal for a Transformational Leader is creating a self-sufficient team that can handle any of the numerous changing aspects of modern software development projects. The underlying idea is that there’s more intelligence and ideas in a whole team than in a single person. The leader serves the team by providing guidance and removing obstacles.

The four components for the Transformational Leader according to Wiki are

• Idealized Influence (II)
• Inspirational Motivation (IM)
• Individualized Consideration (IC)
• Intellectual Stimulation (IS)

That view is very focused on the leader rather than what the changes mean for the team and and how to get there. So I’m using a slightly different model using the four aspects below. I used the original (sub-)points from Wiki but also added a few of my own.

• Environment – how the work environment has to change to reach our goal
• Individual – what changes for the individual (with help from the leader)
• Team Identity – promoting moral standards for the whole team that everyone can identify with
• Leader tasks – how the leader can help reach the team’s goals

These aspects form the framework that a Transformational Leader is aspiring to. Before we get there we have a few pre-requisites that have to be in place, otherwise the change (and leader) is doomed to fail.

These are not hard and fast rules, for example trust from the team and senior management will grow over time but a base level has to be present.

While implementing the changes and working with the team I learned a couple of golden rules over time.

Most rules are self-evident, a few had to be learned the hard way though. Hopefully someone will find them useful and will not step into all the traps I encountered along the way.

That concludes the first part of the Transformational Leadership blog. The next will describe a few examples based on my experience.

If you have any comments or suggestions how to improve any of the above please leave a comment.

An Introduction to Transactional Analysis

After a recent Twitter discussion about treating adults like children I started thinking about Transactional Analysis (TA) again and how important it was when I learned about it (and it still is). It helped me a lot in the day to day tasks as a Test Manager and in private life as well.

Luckily understanding the basics is pretty easy and with a bit of patience the learnings can be applied quickly, be it in a work environment at home or anywhere else where people communicate.

In TA social transactions are analyzed to determine the ego state of a person as a basis for understanding behavior.

TA uses the PAC ego state model

• Parent (learned behaviour from own parents or parental figures)
• Adult (objective appraisal of reality – strengthening the adult is the goal of TA)
• Child (using behavior from our childhood)

In this example the ego states are easily guessed, the woman in child state and the man in parent ego mode.

We constantly switch subconsciously between ego states but it is helpful to observe the current state not only in oneself but also in the partner of the social transaction. If I know the ego state I’m in I can take a conscious decision to change it. If I also know the ego state of my opposite I can influence it and steer the course of the conversation. Note that there are also substates, for example the parent state could be caring and nurturing or commanding and demanding. I’ll leave out these substates as this would become too complex for this blog.

There are no right or wrong states, it depends on the context. I can tell my son off for not doing his homework putting me in the classic parent mode and him in the child state. Or he can tell me off for being late potentially putting me in the child and him in parent mode. I say potentially because I don’t have to go into child mode, I can choose. Splashing about in a swimming pool we could both be in child mode which would be entirely appropriate in that situation.

Why is this important in the context of software development? When a project manager asks the tester how much longer it takes until testing is finally done in what ego state is he/she?

The PMs question could be a request for information (Adult -> Adult) or it could be a dressing down in waiting (Parent -> Child). Without context we don’t know for sure but the ego state we choose will influence the course of the discussion. Let’s play through this example.

“How much longer” instead of “how long” and “finally” to me indicates a disgruntled parent mode. Unfortunately a common reaction to someone asking in parent mode is to answer in child mode. If that happens the tester may become apologetic addressing the (perceived) hidden aggression in this way; in an adult ego state the tester may give a timeline and also address the perceived aggression and ask if there is dissatisfaction in an attempt to resolve the situation in a peaceful manner; in parent mode the tester may become equally aggressive and just push back.

If I’m aware of this mechanic I can take a step back and choose my ego state. The ego state of the discussion partner is not always clear but can be figured out quickly by asking leading questions. This is a lot easier with people we know better.

A little picture may help visualising the ego states.

In a work situation a Child <-> Parent setup is usually not a healthy discussion, ideally we’d try and move the ego states to Adult <-> Adult.

There can be crossed pathways as well, for example one starts with Adult -> Adult

“Can you please tell me what the time is?”

and the second person responds with Child -> Parent

“I know that I have to hurry, no need to put more pressure on me!”

If there are crossed paths no fruitful discussion can take place.

When we know someone better it’s likely that “Games” are being played. By that I mean ‘repeating sequences of transactions that lead to a result subconsciously agreed to by the parties involved in the game’.

Say an old married couple is going over an old argument where the result of the discussion is known already and the actors and texts (arguments) are defined. These games can be played in a variety of situations and the outcome will only change if one or both actors change their ego state.

This concludes this blog. Experiment with the PAC model next time you have a conversation and see if you can spot the ego states. I’d be happy to discuss further- please leave a comment or get in touch via Twitter, email, Skype.

A bug count in context

Counting bugs and creating metrics out of the numbers is a widely (mis-)used practice in software development. I understand where Michael Bolton is coming from and agree to a large degree. Apart from the obvious problems it also fosters bad behaviour as people try to game the numbers reducing their value. Of course there’s a however looming…

I’ll raise my hand and profess myself guilty of counting bugs in the past and creating metrics and diagrams out of it. For a variety of reasons explained below it looked like it was helpful.

I made the mistake of thinking of the bug count as information which it isn’t. It’s data. It becomes information with context and someone attaching meaning to it, right or wrong. I’ll try and make the point that the counts are meaningless but that the context information is actually the important part.

Here’s one such example where I tried to read meaning into the data. In a non-agile development project (with variations for company and type of project) I expect a relatively steep rise in the bug count, a couple of waves when new builds are coming in, bugs are fixed and new ones found with a tapering off towards the end. Note: In agile projects not all bugs may actually get reported but are fixed on the spot so it becomes even more meaningless.

So the picture may look something like this:

Looking at the graph I’m wondering what I’m missing (yes, context). Are these the total number of bugs? Or just the high priority ones? The numbers are going up and down in a certain way, is that expected? For example was there a new big feature in the build around 11/14/10? If not, did we get more testers on the project to explain the sudden rise? What about the drop?

In short the bug count doesn’t answer questions, it triggers questions which most likely could have been asked without it or are meaningless if we want to actually know about the quality of the product. A talk with a tester is more meaningful than looking at bug count data.

In a past project I had a very sudden bug count rise where the answer was that I assigned a new contractor to the project. She found plenty of problems within a very short time span showing her experience which is why I hired her. After a review of the bug reports and subsequent discussion with both testers it became clear that pairing with the new contractor was a good idea to ensure that the knowledge rubs off. I used the metric not to inform me about the quality of the product but as a trigger to find out something, that I could have had with a 5 minute chat with the new contractor.

That’s where I see one of the problems with looking at bug count data, replacement.  I could have spoken to the tester immediately instead of wasting it on looking at a graph first.

Another example – the drop at the end seems off to me. Again from experience something similar happened when we lost the connection to the database – a network error. Since I was the first one in we could get the problem fixed before the rest of the team arrived by looking at the bug count. Note that we later added Splunk for proper monitoring not only of the operational machines but for the test environment as well rather than relying on this crutch. This problems was caught as a lucky accident, not by design.

The important part here is not the bug count but asking the right questions and implementing the proper tools.

Counting bugs usually has a very low initial cost as it’s provided with most bug tracking tools. This is one of the reasons it’s so widespread in addition to how easy it is to read meaning into the numbers.

At the time I made it very clear to the test team that they are not judged based on the number of bugs they find or that this would even find a way into their reviews which is the case in some places. If everyone understands what data we have in front of us and more importantly, what it doesn’t tell us it can be a useful tool in the context of your project. If we remind us of our biases we are less likely to interpret something into the data that is not there.

Will I continue looking at the bug count? Probably but the emphasis is now on finding the real and context information.

To make sure everyone is paying attention, the graph that you see above is not a bug count graph but an edited user count graph. So just because it looks like what you’re expecting doesn’t mean that’s what it is. In short, the numbers are meaningless. Context information is what we really should be looking for.

Happy hunting, not for bugs but for the right questions to ask.

Making notes while learning

It’s been a while since I last blogged – mostly as other things in life took over and I needed the headspace to concentrate on non-testing stuff. In order to get back into the mood I re-read some older testing books but also a few new ones which are not exclusively about software testing plus a variety of blogs.

Here are a few examples from the ones I read in the last couple of months:

Tacit and Explicit Knowledge by Harry Collins

#Workout: Games, Tools & Exercises to Engage People, Improve Work and Delight Clients by Jurgen Appelo
The Cynefin framework in testing explained by Duncan Nisbet

In previous training courses I did one trainer mentioned that if we remember 30% of what he taught we all did well. I’m naturally cautious if someone gives me a percent number but it sort of feels about right. Because I didn’t want to forget the important parts after reading the books I started taking notes in OneNote (any text editor will do).

To  keep my notes arranged in a (for me) intuitive way I created a couple of documents; General Management, Testing and because it’s such a large area one for Management 3.0 for Jurgen Appello’s work. In each document I created sections and then pages where I keep a summary of book, article or blog that I think is useful to remember in a years time.

For the Tacit and Explicit Knowledge book, which isn’t an easy read as fellow testers have affirmed, I found it useful to learn the terminology of the book; I summarised what is tacit, explicit and ostensive knowledge, how does he define an action and a string and what are the enabling conditions of communication. Taking notes while reading the book helped understanding the rather scientific style of Harry Collins writing.

For other books and articles what often helps most, because it’s usually a summary in its own right is using diagrams or pictures. The Cynefin framework is really visual and with the picture and a few explanations underneath I’d be able to explain it as an elevator pitch. Sometimes a single picture like the one from Michael Bolton’s blog Oracles from the inside out  is enough to let me remember what it was about and show the model to someone else.

For the Management 3.0 workout book I created its own document and there are many different sections that couldn’t be compressed down into a single page. In addition to summarising the content I also created single pages with lists that would come in useful when using some of the examples in earnest. Adding a couple of my own ideas what would work or where I’d see problems or at least question marks means that I can take what I learned and apply it whenever I need to.

This way I can now delve into the different areas (documents) if I want to get inspired or only vaguely remember a specific model and look it up. The summary is usually enough for me to remember corresponding details as well so creating it was time well spent.

I hope you find this useful too.

The first post – an explanation

A few people may remember my site over at Googles Blogger. Unfortunately I ran afoul of Googles security processes as they were thinking someone is hacking the account when I was logging in using an IP Spoofer, Cyberghost, making my location Amsterdam instead of my home town in Germany. Long story short, even though I have my username and password Google support is denying access to the account and it’s lost to me. Needless to say I’m not happy, I’ll likely write a blog about details of this fubar in the near future and Google’s horrendous support practices. If you’re still on Blogger I’d urge you to rethink your choice, move somewhere else and just leave a redirect in place.

This site is a continuation of the old Blogger site. If you have any comments for any of the old posts, please leave them here.