Interview With Lisi Hocke
Having graduated in sinology, Lisi fell into agile and testing in 2009 and has been infected with the agile bug ever since. She’s especially passionate about the whole-team approach to testing and quality as well as the continuous learning mindset behind it. Building great products which deliver value together with great people is what motivates her and keeps her going. She received a lot from the community; now she’s giving back by sharing her stories and experience.
She blogs at www.lisihocke.com. In her free time, you can either find her in the gym running after a volleyball, having a good time with her friends or delving into games and stories of any kind.
What is ensemble testing? Have you ever come across resistance or apprehension when introducing ensemble testing?
Ensembling or ensemble working is a collaborative approach where a group of people all work on the same thing, at the same time, in the same space, and on the same computer. It got quite commonly known as mob programming or mobbing, and then received a new name.
Ensemble testing is performing testing activities in an ensemble, yet you can basically do any hands-on activity together in an ensemble and accomplish the work in an effective manner.
Having the people all together brings in their different experiences and expertise, uncovering implicit knowledge and instantly spreading it across the group. It’s learning and contributing in a way that in my experience is one of the best options to level up everyone at once while achieving better outcomes due to considering and integrating all perspectives.
Resistance and apprehension can come up due to a lot of different factors. For example, when this kind of highly collaborative approach is too far from the style of working we’re used to, when the disconnect is too big it’s hard for people to even imagine why this would be a good idea to try.
I’ve come across many people who never had the opportunity to run any kinds of experiments or never dare to. Many were skeptical that it’s worth having all these people working at the same thing - how could this ever be productive? We could work on several things in parallel, right?
It’s quite counter-intuitive for most who have not tried it, or not in a good manner, that this step of slowing down intentionally lets us go a lot faster in a better direction earlier.
It also brings a lot of other desired benefits with it, like reducing waiting time for anyone’s feedback as we’re all together, reducing context switching as we’re limiting our work in progress to the one task at hand, reducing distractions as we’re all keeping each other focused, and more.
Another reason for pushback: if people are not used to showing their work right away in all its raw and unpolished and drafty phases, it’s hard to suddenly have people “watch you” or “look over your shoulder”. While good ensembling is not like that, it still requires courage to show yourself as vulnerable, not knowing everything that you think people might expect of you, showing any kind of perceived weakness.
In my own upbringing and the education system I went through, we were supposed to be solo fighters. Individuals were getting evaluated on their own, we were even pitted against each other in competition.
Now suddenly emphasizing the complementary part of bringing the best of us together and building on it is something that requires us to unlearn trained behavior and relearn from scratch.
All in all, in my personal experience most apprehension came from team members like developers, testers or product owners - a lot less from managers who were very interested in fostering collaboration, communication, building relationships and a supportive culture.
That being said, most systems still evaluate only individuals and not the whole team, which is not making it easier to convince people to change their behavior and try something different to accomplish the work we want to achieve.
Do you have any tips for people who want to try ensemble testing? Any recommended reading/resources?
Absolutely! I have a whole page of resources regarding collaboration that proved very valuable to me. One complete section is dedicated to ensembles. There’s a lot you can learn about the approach, you can read lots of posts, watch talks, listen to podcasts.
No resource, however, will ever be as good as your own experience.
Therefore, I recommend you to look for ensemble sessions you can join yourself, at meetups or conferences or asking around in your network. And if there’s nothing out there, consider trying to create this opportunity yourself! My very first ensemble experience started out like that.
You and Toyer triggered this learning partners movement. What should people be looking for in a learning partner? What should people be considering?
Toyer and I are both very glad that our learning partnership resonated with people! As we shared about our journey, more partnerships evolved, people finding each other and growing together. For our learning partnership, it was crucial that we both showed similarities as well as differences in traits and experiences.
When we met back at Agile Testing Days 2016 it just clicked, we saw each other’s eagerness to learn and grow, and we had mutual challenges we both considered scary (like conference speaking). We both were inspired and hence created our first pact!
What made this work was that we really held each other accountable from the start. This made a lot of the daring things easier; we were in this together and we definitely did not want to disappoint each other. Bold moves came out of that and I don’t want to miss one step of our journey.
If you’re looking for a learning partner, I recommend to check a few things with each other right from the start. Are you on a similar journey? Maybe you have a common goal you want to commit to? For Toyer and me it was our conference speaking journey to start with, followed by other learning topics. They sometimes differed in focus yet always were something that scared us and forced us out of our comfort zone.
Once you found a potential partner, clarify administrative things like how often to meet, when, where, what to exchange, do you want to have documentation about it, and so on. What about expectations towards each other during your learning partnership - make them explicit and make sure both commit to them. Any kind of agreement has to be bilateral, otherwise this is prone not to work out.
Last but not least, what do you need from each other on a deeper psychological level? How to give each other feedback? What do you deeply care about? Which topics not to address, which boundaries not to cross? All this helps set you up for a successful partnership. It’s a learning journey that includes building this relationship - and it’s really worth it!
You embarked on a coding confident journey as a personal goal one year. What could you do at the start? Where were you at, at the end? Roughly how much time did you dedicate to this goal, outside of work per week/fortnight/month?
This was the third of my personal challenges that originated from pacts with Toyer. My #CodeConfident journey in short: I started out very conscious about my lacking programming skills, very eager to improve them yet quite unsure how much I could learn anyway. I decided that I wanted to tackle this finally, no matter how scary it was (and it was scary indeed), by doing many small hands-on coding exercises and challenges.
I went from test automation through the whole tech stack, to API and unit testing, to extending a backend feature then making a frontend change, and finally to creating a small application on my own as a proof of concept. I even managed to do my first ever live demo on a conference stage!
To provide more background, I was labeled “non-technical” for a long time, and no matter that I grew up with computers and technology and my passion for it, I labeled myself non-technical for a long time, not realizing that I was just perpetuating what the system made me belief. At some point I started to stand up against this and stopped calling myself non-technical (inspired and influenced by Andrea Goulet). Then I started talking about myself as technical and started acting like that.
For the last two years, no one questioned me anymore, everyone saw me as technical. All this had to do with changing perceptions and increasing confidence, first my own, then others followed. My code-confident challenge was a big part of this, and it indeed let me grow a lot of the confidence I’m still building on. I wanted to share this further with more people and encourage them to grow their own technical confidence, hence I’m now offering a workshop to do just that.
I cannot recall the time I spent for either of my personal challenges. Estimates would be far off as well so I’ll not even try. I can tell you, however, that I spent quite a bit of my non-working time on it, investing in myself and my growth. I am very privileged that I was able to do so, having the time and money and support at hand.
There are other options though. I would encourage everyone to see if there’s overlap with your work. If what you want to learn supports your work, there’s a good chance you can use part of your working time and no one is going to complain about it. I am grateful I learned quite early on that this was one of the cases where it was feasible for me to rather ask for forgiveness than for permission. I just did it, I talked about it, I shared what I learned, and my managers and colleagues appreciated it.
I found your testing tour talk very inspiring at ATD 2018, but the thought of approaching strangers or even people I only kinda know intimidates me. Any tips on how to get around this and why I should embark on a testing tour?
My testing tour was yet another challenge I had, pairing with lots of different people on lots of different topics. I really relate to the difficulty of approaching strangers and setting out on such tour, especially publicly. Well, it was meant to be scary and get me out of my comfort zone so I could also really grow with it!
What really helped me was to make use of relationships I already had built and start with them. My very first tour sessions were with people I met at conferences and colleagues - this way I could also gain experience on how to prepare for these sessions, run them and follow-up to get the most out of it for everyone. The more sessions I did, the more confident I grew, and the more it enabled me to ask further people to join me.
At some point, I did not even have to ask myself anymore, strangers approached me directly or just booked a session! That made it easier regarding getting connected, yet came with different challenges to get us started on the right track.
Why to embark on such a journey? Whatever it is that makes you set out on a tour, it should fit with your personal goals. For me it was the fact that I always was the lone tester, or the most experienced one - and I was very unsure about my own testing skills. I was eager to see how others approached testing challenges, get to know different specialties like security or accessibility testing, and more.
What I gained was a lot more knowledge, skills, tools, and a lot more awesome human connections as well. Doing these sessions for ten months was one of the best things I ever did during my testing career and granted me lots of opportunities later on.