WTF Are You Doing? Tell Your Teams!

Reading Time: 5 minutes

 

This post is about helping your team to learn, by giving them simple, yet vital information to help guide their learning.

 

WTF Are You Doing?

 

I moved into my first tester role from elsewhere in the business, outside of the product team.  I wasn’t given any kind of introduction into how the team worked, and was relying purely on my previous outsider knowledge and curiosity to work things out on my own.

 

Slightly confused and eager to learn, I approached a senior developer.  “WTF are you doing?” isn’t quite the question I asked.  I tried to be a little more “business appropriate”.

 

“I’ve been trying to read up on different software development methodologies and techniques.  There are bits and pieces that I recognise in what we’re doing here, but none of them quite fit.  I want to read more so I can learn about what we’re trying to do here…  What are we doing?”

 

Give Me Something to Search For

 

I had been reading about Agile, Waterfall, Scrum, Kanban, TDD, BDD, extreme programming, to name just a few.  All on a shallow level only, in order to start building up my knowledge of the software development lifecycle and different ways to go about it.  If I was to continue learning about what was relevant for my context, I felt I needed to know which of those – or anything else – we were trying to implement.

 

To make things more complicated, I wasn’t justing acting as tester.  I was the product owner and business analyst too, and so there was a lot of learning for me to do.  I needed more direction than just “Agile”.  Incidentally, we weren’t following the principles of the Agile Manifesto either…

 

“Well, we kind of use an experimental programming approach, so not quite this or that…”

 

That was not helpful to me.

 

Don’t get me wrong, I’m not saying that all teams should conform strictly to one methodology or way of doing things.  It makes sense to take things from different places, so long as they work for you.  Experimenting until you find something that works is fine too.

 

I didn’t need a single, all-encompassing term to unequivocally describe what we were doing.  I just needed a direction; a few things to search for to start focussing my research towards areas more relevant to the business, and my place in it.

 

“We take the idea of planning meetings from Scrum and try to use the three amigos method from BDD.  We’d really like to start doing retrospectives too, but we just don’t seem to have the time.”

 

That would have been useful.

 

It would have given me five topics to search for and learn about.  I could have understood that those were the elements we wanted to incorporate into our way of working, whereas other elements weren’t so important.  I’d also know about one of our challenges, and could look for ways to overcome it.

 

Instead, I had this idea that we weren’t really doing any of that stuff, and so I shouldn’t read too much into anything because we did our own thing anyway…

 

This Would Have Been So Useful Back Then

 

Now that I’ve moved on from that company and that role, I’ve been free to start afresh in terms of my research and learning.  I’ve followed what interests me, and what is relevant for my current company, in my current context.  I’ve spoken to colleagues and gotten useful terms and topics to investigate in preparation for the projects ahead.

 

Through diving deeper into certain topics and methodologies, I’ve come across some really interesting concepts and information that would have been so valuable to me at the company I started testing with.  I’m reading things now and thinking, “Wow, this would have been really useful at my old company, and we could have tried all these things… Oh well, too late now!”

 

How unfortunate that this information, much of which has been available for several years, was left undiscovered by me because I lacked the guidance to look in that direction.

 

Of course, I continued my research and learning, but it was still very general and quite shallow, because I didn’t know what to focus on.  I read about software development only as much as I needed to in order to give context to my learnings about testing.  I didn’t want to go too deep into things that I believed would turn out to be irrelevant to me at the time; that I couldn’t put into practice in the near future.

 

I scrambled around trying to find things that I could use now (or then) rather than later.  I couldn’t find what I was searching for because I didn’t really know what it was.

 

Accidentally Re-inventing the Wheel

 

This is an experience from my first job as a tester.  Had I had more experience in the software industry, I might have found it easier to spot matching areas and practices from different methodologies and be better able to suggest relevant ideas and improvements.

 

As it happens, I wasn’t and I struggled to pull the right ideas from the right places.  On the few occasions I did, I was met with resistance because that’s not what we were trying to do.   But I still didn’t understand what was.

 

Instead of effectively applying the wisdom and knowledge that’s already out there, I had to come up with ideas and suggestions myself, trying to shoehorn them into the business context.  I didn’t realise that others had already developed and improved these ideas before me, and come up with better ideas too.

 

Tell Your Teams WTF You’re Doing

 

Whenever you have someone new joining the team or company; whenever you decide to try something different or implement a new technique: tell your teams WTF you’re doing.

 

This will not only bring them into “the circle” and help prevent them feeling as if things are just happening around them, but it will enable them to research and learn about it for themselves.  Why would you not want to facilitate self-learning?

 

I don’t think it’s an obvious or easy thing for a new person to just walk up to a colleague and ask, “WTF are you doing?” (even if with nicer words), particularly if they’re a complete newbie, like I was.  You should let everyone know what you’re trying to do up-front.

 

It’s not just testers and other people in product teams that will find this information useful.  It will help your colleagues in support or operations when they talk to your end users about any issues or complications.  It will help your colleagues in sales and marketing understand what’s involved in delivering a new feature.  It helps builds empathy for the product team (internally and externally) because people are more aware of the processes and challenges.

 

It helps everyone to have this information so that if they want to find out more, they know WTF to search for.

 

 

WTF are you doing?  How would you describe it to your teams?  I’d really like to know if other businesses make a conscious effort to give their teams this information.  Please let me know in the comments.