I recently attended a Project Managers meeting where PM specific, day to day problems were discussed.
Some were quite generic in nature and similar to a tester meeting, for example how do we make sure that people are properly trained, dealing with communication problems, etc. Others were more specific, for example talking about managing customer relationships, how a customer may perceive problems in a project from a completely different angle (for the better or the worse for the PM in question).
What occurred to me there is that we put a lot of emphasis in testing on adding “value for the customer”, however most testers that I know have no idea about customer management, and how our customers priorities might be different from the ones that the development team (programmers and testers) are thinking of. Managing that relationship sits squarely in the corner of the PM or Account Manager (where available). In a way it’s good that the Project Manager is shielding the development team from sometimes difficult customers, but to what degree can a tester really say that what they’re doing is actually adding value for the client?
That reminded me that what we think of as “adding value” is actually based on a model. To quote George Box “All models are wrong, some are useful”. Is our model built on validation and verification – in a broad way ensuring that the system works as intended and works without glitches? But what do we base that on since we all know that requirement documents are notoriously lacking? The argument I often hear is that testers bring their experience in adding what they perceive to be of value to other customers so it might be of value to the current project as well. With no knowledge of the customer or our relationship with them how can this be true?
At the next team meeting it might be an idea to invite the Account Manager as well or, if the PM is fulfilling that role as well, ask him about our relationship to the client. Is it perceived to be a difficult one? Have we worked with that client before? Is the project seen as a start of many others to follow? Do we know of particular things that “bug” the client that would help us direct our test effort?
I don’t know how other people address that but these are not questions that I have asked in the past but maybe I should. I attended a Project Management course and think that all testers should do that sooner or later, ideally followed with actually managing a project or two as well.
Many testers have an idea of how programmers think, many having a background in programming themselves. Maybe it’s time that we start to look through the eyes of a Project Manager as well and walk a mile in their shoes.
Great post Thomas! I think getting to the point where there is a shared understanding of what the customer really wants is crucial to doing a good job for testers and PMs. Unfortunately reaching that point is often a painful process because we have to accept - testers, developers and product owners - that our own viewpoint might not be the right one.
ReplyDeleteI like the idea of inviting the Account Manager along to the next test team meeting because it also stimulates interest in the part testing has to play in the process.
Stephen
Thomas, thanks for this excellent post. It's something a lot of testers consider & think they can solve just by thinking what the customer wants, having a customer mindset. While that might make you think of a few more test conditions you can't say for certain that your thinking for the customer, he has a mind of his own and his perceived end product can often end up very different from what’s delivered if not carefully managed.
ReplyDeleteAt my company we try to gather as much feedback as possible from PM's, BA's on the customer & when ever possible sit in on a demonstrations of in progress features to a customer, to get that vital feedback.
How much value can we add though? We can make sure the customer is getting what they originally requested & from monitoring communication we can see what additional scope is coming in from them. Can we also suggest improvements to the customer? Some think this is not a tester’s role but is something I do often via the correct channels. I don't think it's a bad thing I'm adding value still & by going through the correct channels it's carefully handled & monitored.
I recently attended a Learning Tree course on 'Critical Thinking and Creative Problem Solving' where we learned about different thinking styles. We talked about left and right brain dominance, the Herrmann Brain Dominicans Instrument (HBDI), identified our own natural brain dominance and participated in group exercises to help learn how to communicate with those who think the same as you and those who think differently. We had to work on pseudo projects and address issues while applying a different thinking mode from our natural one. What a challenge that was! For me acting as a 'B' thinking type was close to impossible. Tackling matters as 'C' type was hard as well so I am not convinced that testers that I know or I, myself, can actually manage projects.
ReplyDeleteAccording to this model, a successful and effective project manager should be quadrant dominant. I was fortunate enough to have worked for a few. Most of our managers are 'home grown' and are still doing either programming and testing part-time and ultimately favor their thinking types. Our subject matter experts handle liaison tasks between the implementation group and the customer which helps a lot.
According to the HBDI model there are four modes (see Wikipedia):
*A.* Analytical Thinking (programmers/testers) - logical, analytical, fact-based, critical, technical and quantitative.
Preferred activities: collecting data, analysis, understanding how things work, judging ideas based on facts, criteria and logical reasoning.
*B.* Sequential Thinking - safekeeping, structured, organized complexity or detailed, planned.
Preferred activities: following directions, detail oriented work, step-by-step problem solving, organization and implementation.
*C.* Interpersonal Thinking (manager types) - kinesthetic, emotional, spiritual, sensory, feeling.
Preferred activities: listening to and expressing ideas, looking for personal meaning, sensory input, and group interaction.
*D.* Imaginative Thinking -Visual, holistic, intuitive, innovative, and conceptual.
Preferred activities: Looking at the big picture, taking initiative, challenging assumptions, visuals, metaphoric thinking, creative problem solving, long term thinking.
Thanks for all your comments, I'm glad you liked it.
ReplyDeleteLena, I haven't come across the HBDI model it sounds interesting, a bit like a personality model that I'm familiar with.
I can see parts of my personality in all four groups although B is probably my weakest.
Thanks for sharing that.
Thomas
Its good to imagine in the PM shoes to understand the needs and to offer solutions.
ReplyDeleteFor example the PM needs to justify and measure testers work. And unfortunately test cases are quick dirty convenient way to do.
So we need to find solutions that fit the needs of everybody.
Sebi
Good post Thomas. It's important for testers to get wider experience, and I still think the best route into testing is to move sideways after several years in some other discipline. it helps you understand the role of testing better if you have seen it from the outside.
ReplyDeleteI particular, it's easy to undervalue the role of project managers. A good PM will shield the team from all sorts of pressures and distractions, taking care of time wasting tasks and meetings.
When I worked as a PM a coder, who was a good friend(!), once said to me, "What exactly do you do? We just get on with the work, but I don't see what you do". That was exactly the point. My job was to ensure they could just get on with the work, without having to worry about the crap I was paid to keep away from them.
James Christie
Recently I asked the account manager to describe the customer to me. She thought this an odd question and was slightly irritated by my questions.
ReplyDeleteIts less complicated and simpler to ignore the fact that the tester really has no idea what the customer wants.
Sebi,
ReplyDeleteyou made a very good point that PM's need to justify the testers work to their superiors as well - something that is often overlooked. Once we understand what a PM needs to report to his/her superiors we can get other measures apart from counting test cases into place as that's seldom the goal but just a (bad) method to convey information.
James,
thanks for your comment, I agree wholheartedly with "A good PM will shield the team from all sorts of pressures and distractions, taking care of time wasting tasks and meetings."
I'd argue that this is not only true for PMs but also for Test Managers - to remove the stones from the road so that the project (test) team can concentrate on the task at hand.
If you're invisible in doing that you've done a good job indeed.
Anne-Marie,
thanks for commenting. I found it quite surprising what amount of information we can get from Project or Account Managers - they are usually the first to hear complaints about the software so know what annoys them. It's nice to hear that other people had the same experience.