If you’re looking for reasons to doubt the quality of your own work, you’ll find them.
At one client, I was managing a team of five testers and working with an agile development team overseas. There was no time of day where the developers and testers were online at the same time. Our primary modes of communication were emails and defect comments.
When the Programme Manager called me into his office and said that my team was adding no value to his project, I was dismayed. All I could think of was that I’d just returned to the workforce after a year-long maternity break, and my first project was an epic failure after just six weeks. My role was to provide information about product quality to the PM, and he had just given me the worst feedback that I could ever imagine giving a team:
It will be better if you do nothing, because you’re distracting the development team with all of your questions. They’re very busy, they’ve got a lot of work to get through for this sprint, and you’re wasting their time.
I was so surprised and upset by this that I excused myself and thought about where I could have gone so wrong on this project.
For about the next 40 minutes, I found plenty of reasons to doubt the quality of my work.
I was working with a new cloud application, and having some trouble completely understanding the backend structure.
The questions we were asking development made sense to me, but maybe we should have added more detail to avoid misunderstandings, in the absence of face-to-face or at least real-time conversations.
I’d been asking for feedback every two weeks and it had all been positive, how could I have missed something this big?
I’d just been off work for a year, and maybe all my instincts were off.
At about that point, I wondered why no one from my team had questioned me on our approach, and whether they’d also been doing anything wrong.
My team had been doing all that they could with the information available during the day.
They’d been sending through a single email of concise questions daily, when our team couldn’t work out the answers amongst ourselves.
They’d been notifying me daily about issues blocking their main priority tasks, and finding other things to test in the meantime.
I came to the conclusion that my team had done nothing wrong, and had been adding as much value as they could given that they were usually blocked for at least half of each day on testing the highest priority product areas.
Then I finally realised, I had been adding value too. Quite a lot of value actually. Perhaps if I’d been at the top of my game, I would have come to this conclusion during the meeting, rather than 40 minutes later.
I had been uncovering major oversights in terms of product development and deployment planning, some of which had a large impact on the project budget.
I’d worked hard to develop solid test plans in the face of ever-changing information.
My decision to use a visual coverage map approach to test planning had provided thousands of dollars in savings, from the effort we saved when changing the plans as often as was necessary.
I had worked closely with the Training Department, to ensure they had early access to the system.
We were regularly blocked by lack of real-time access to the development team, and sent them daily summary emails with lists of questions and requests for clarifications.
I’ve taken away a few lessons from this unpleasant experience. Some are lessons that I’ve learned before, like ‘Get everything in writing’ and ‘Seriously, get it all in writing’.
And that when a team say they are ‘agile’, that can mean just about anything.
And that some people interpret my questions about project gaps as blaming, rather than genuine interest and concern in taking corrective actions, which is their problem and not mine.
But those lessons are off-topic for this post.
A new lesson I’ve learned is to criticise my own work instead of relying on feedback, and not wait to be criticised by someone else. This will improve my confidence in my own work, and give me some practise at promoting and/or defending my test approach. Here’s hoping that next time I hear statements as ridiculous as the ones above, I will react with appropriate confidence and indignation.
UPDATE: Writing this blog helped me a lot. The next time my work was called into question, I responded appropriately with confidence, evidence, indignation and pride.
If I’m ever in a similar situation with a manager who buckles under the immense stress placed on them by stakeholders, and that manager decides to lash out at the team in a moment of weakness, I will defend myself and my team.
Vaagai Virtual Admin Services
April 13, 2014 at 9:49 PM
Great article. Asking questions adding no value? Who said? It is really a bull****
May 13, 2014 at 5:33 PM
Very interesting article. Distributed agile team, e-mail communication mainly, different timezones – these are really dangerous conditions. Better to avoid this kind of work but sometimes one just doesn’t have possibility to choose.
June 10, 2014 at 10:14 PM
Nice post, Kim. It’s hard to write about the difficulties we face during a project. Which is funny, because they’re so abundant. Thanks!
June 19, 2014 at 5:41 AM
It’s great that you didn’t let that person make you doubt yourself, you took a step back and looked at your contributions objectively. That’s hard to do sometimes!
I once was on a troubled team where, for several weeks, our CI was red, we couldn’t get a deployable build to test, and even if we had, we had no working test environment to which we could deploy. I brought these issues up every day in the standup as blockers. I didn’t go on and on about it, just raised the issue every day and notified the team we were still blocked.
One day the ScrumMaster of the team called me (I was working remotely) and told me, “You’re an impediment to the team. Stop bringing up these issues, and don’t ask any questions”.
I was speechless. It affirmed my other observations about the dysfunctional culture in the company which I had been unable to help make better despite my best efforts. Needless to say I did not stay much longer at that company. Change your organization, or change your organization.
LikeLiked by 1 person
April 10, 2016 at 8:59 PM
There are always going to be troubled teams. There’s neutral teams and occasionally there are great teams.
Most times we are going to be put in troubled teams. At least if you have reputation for doing quality work, the chances are you will be asked to do this type of work.
In many of these cases, we have little control over what people ‘think of us’. Of course, doing great work is a bonus, but that doesn’t always mean you will be valued.
Sometimes no matter what you try, others will not be able to see the value you offer. People are not always logical, reasonable and objective and that will impact your work. Sometimes it will work in your favour, sometimes not.
We don’t have as much influence as we’d like to think we have. And perhaps that’s ok.