During the planning session on the first day of the BAT conference a program for day two had emerged, a full day of presentations and interaction. The format for our conference involves presentations followed by a period of “open season” a structured (facilitated) discussion. I’ve attempted to make a summary of the presentations and I’ve tried to capture some of the takeaways I got out of it.
The day started with a session by myself, with the title “From A to B – From Insurance to Influence”. In this presentation I basically described the history of my testing career and the road to recognition.
Currently I am working in a very effective and highly sophisticated environment. We are refactoring a legacy system that has become very complex and difficult to maintain, all touched functionality is ported to a new state-of-the-art infrastructure, where every commit goes live in production instantly. Testing is a shared effort. My task only involves limited hands-on work and mostly consist of getting requirements to the right level of abstraction and understanding. My influence on the actual product is substantial, this is the closest I’ve ever been to doing stuff like impact mapping or feature injection. Together we decide on business value and in production we measure if the goals set in advance are actually met.
It has been a long time coming and in no way resembles the work I used to do when I started out as a tester. I have a feeling that when I started some 16 years ago, the reason for hiring me was mostly based on fear, testing was done as sort of a insurance policy on a project. Specially in the period I worked for a large consultancy firm, the actual outcome of my work was often found unimportant (and basically annoying). As long as peoples asses were covered, everything was fine. My influence, even with great effort from my side, was limited to none at all.
This view on testing has reflected in the way the profession has developed over the years. People seem to have no sense of responsibility, lack skills and take little pride in their work.
One of the larger questions raised after my talk, was how we can deal with incapable or demotivated colleagues. We spend most of the “open season” trying to find an answer to this question and contemplating on how we should go about spreading our values, introduce craftsmanship and how we can motivate colleagues to be more inspired.
The second experience report was very on topic (theme for this first conference was Agile Testing: Your Passion) and was presented by Maaike Brinkhof. She described the road she had followed to become a passionate and involved professional. Although her experience sounded in many ways familiar and much related to my own, unlike me she did not go through years of unsuccessful projects, before seeing the “light”. After a less glorious beginning of her career at an insurance company (if i remember right), at some point by becoming a tester she found a way to transform work from a dragging daily routine into a resource of wonder and inspiration. She explained how she is still somewhat insecure being a “newbie” in many aspects of her work, where being a newbie is not necessarily a good thing. Opposite to that, we, her colleagues respect her and see her as a valuable member of the agile (testing) community. So we elaborated on the idea of being a newbie or feeling like a newbie and the actual beauty in that. If you get to live your life feeling as a kid and experiencing marvel in everyday events, it is actually a beautiful thing! We should cherish the learning experiences we have and as Luca Maraschi‘s (see previous blog post) tattoo tells us: “Stay Hungry, Stay Foolish”
After lunch Pascal Dufour introduced us to the world of Innovation Games. Innovation games are a simple but powerful tool to make meetings more fun and often more effective. Simple creative methods can make seemingly complicated things very easy. The examples that Pascal gave were games that help doing better retrospectives, improve project estimation or help to better prioritise user stories. One example was the speedboat game. Picture a speedboat with different anchors holding it back. Each anchor represents some project obstacle, obstructing the “boat” from going forward. Now the team is challenged to find solutions for these obstacles. Each team member can come up with solutions for removing the obstacles and place them somewhere on the anchor lines, the order (lower/higher on the anchor line) determines the order in which it should be picked up. This in the end gives a very complete overview of what is preventing your project to be successful and what steps need to be taken to improve. Many more examples can be found here.
The final session was by Kishen Simbhoedatpanday on “the whole team” approach. Kishen recently attended a workshop on Mob Programming by Woody Zuill (the spiritual father of the concept) and was very impressed with the effectiveness of the method. Mob Programming is a way of doing agile development that extends on the idea of pair programming. Rather than having only two people working together, the entire team works on the same code, on the same computer, at the same time.
One person is assigned to be the Driver. The Driver sits behind the keyboard and may only type what people suggest. The rest of the people generate idea’s and guide the Driver toward the final code. With short intervals (say 15 minutes) the role of the Driver rotates over the team members. The thought behind it is that there is a lot of room for creative thinking and complex matter is dealt with by all disciplines at once. Problems with knowledge sharing, decision making, technical debt, doing more than is strictly necessary, planning, estimation etc., seem to vanish once you introduce this system.
As an entire group we tried to write a piece of code for printing FizzBuzz values, which turned out to be a bit of a challenge. When you put a group of testers behind a single computer and ask them to write Java code, it might just turn out the individual coding skills are somewhat limited (and opinions abundant :). But the experiment actually worked quite well to get the basic concept and I would expect with a balanced team Mob Programming could actually be a very productive approach.
One day of experience sharing, using the model we choose for this conference, is a very limited period. In advance I would have expected more presentations, but the discussions as a result of the 4 presentations were priceless, leaving me hungry for the next BAT conference. Putting passionate peers together for a-day-and-a-half is an extremely educational and joyful experience. Much thanks to all attendees!
Thanks to Wim Heemskerk whom provided me with this great sketchnote refreshing my memory