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.
4 thoughts to “WTF Are You Doing? Tell Your Teams!”
I can relate so much with the thought that “This Would Have Been So Useful Back Then”. It happens to me often even after years of working with testing, specially with automation. Whenever I learn a new trick, code standard or start using a new tool or framework I think back to when I tackled the same issue in a not-so-appropriate way and how I could have left better code for the companies I worked for. But as you said, too late for that. But i’m ok with this feeling, at least it means I’m still evolving and learning.
Thanks for the text, I’ll keep this in mind when onboarding future newcomers 🙂
Thanks for comment.
You’re right, it’s a great sign that you’re still evolving and learning. I fear many aren’t!
Excellent, I hope it helps newcomers and the team as a whole!
That’s an interesting point of view, I can definitely see the benefit of defining the way a team works.
For me, I got to experience the flip-side of this: we are doing a scrum-but (which means “we do scrum, but…”) and on several occasions in the past we were having someone rant about “this is not how you do scrum” whenever things didn’t go his way. In that case, saying “we do scrum” actually blocked having a proper discussion on the benefits and constraints of an activity and enabled religious-like stances.
I guess that if we were to frame your way of working a bit more elaborately, as you did in your example, it would have been a bit more constructive in this manner. I’m not sure most people I know would be interested enough in the theory to define their work methodology this way – generic boxes are easy.
Thanks for your comment.
You’re right and I can certainly see that being an issue. The intent is to aid learning, but it’s definitely possible that it turns into policing instead, which isn’t good for anyone. As you said, hopefully a more elaborate example like the one I gave will help with this.
Regarding people not being interested enough in the theory to define their work, this is a really good point. It made me wonder if perhaps the reason why no one could tell me what we were trying to do is because no one else knew either… Perhaps no one else in the team had ever been given this information and couldn’t (or didn’t want to) work this out either, perpetuating the cycle of confusion and lack of guidance.
To me, this would indicate a more worrying / bigger issue of unstructured, unguided working in general. That perhaps no one was really leading efforts in that respect or taking advantage of the knowledge from the experiences of others on a similar path. I think that even if you were to try and “invent” your own, new methodology, your research and learning into other things already out there would allow you to talk about it in those kind of terms and open up more discussion about why there was a need for something new.
Lots to think about!