We use necessary cookies for the functionality of our website, as well as optional cookies for analytic, performance and/or marketing purposes. Collecting and reporting information via optional cookies helps us improve our website and reach out to you with information regarding our organisaton or offer. To read more or decline the use of some cookies please see our Cookie Settings.

Skip to content

I was a client - my Agile Lego Tests story

Business

Sep 13, 2016 - 3 minutes read

Objectivity Blog 416 306
Robert Kalina
I am a Testing Guild Master at Objectivity. I believe that working on strengths we can get the amazing effects. I use this philosophy in my daily work with project teams.
See all Robert's posts
Data Driven Organisation Blog Ebook 416X300

Share

I’ve been occupied with testing for 8 years now, although I prefer to call it creating reality, because that’s what testing is in many ways. The way I approach testing and which/whose example I follow is pretty well reflected in the blog by Rob Lambert ‘The social tester’. It’s a good deal of really interesting topics and issues that may be encountered when working in the Agile methodology, aptly described by the author.

A few days ago, I had the opportunity to participate in ‘Agile Lego Tests’ workshops, in which I took on the role of the client. Why I undertook this task, why it was me, who played the role of the client and what I’ve learned – that’s what my story will be about.

Before Agile Lego Tests, I thought that the role of the client (apart from the client, there were also a moderator and observers) is not difficult. There is a ‘chap’, who knows what he wants and has a budget to carry out the project. I couldn’t have been more wrong. It’s been a very exhausting task. The ‘Dry run’ before the actual Agile Lego Tests carried out with the participants from our company showed that 6 people asking questions at the same time about the vision and details of the project can put you off your stride so much that the question, ‘what is it that I wanted?’ and ‘do I really need what I want?’, appear not without a reason.

At the beginning of my adventure with the Agile methodology, in the development projects, I very often asked the client a million questions that shouldn’t have asked at that specific time. It was much more important to ask the right questions, so that the client could devote some time to me, which usually is so scarce. This is what I had the opportunity to experience working as a client in the ‘Dry run’ before Agile Lego Tests. What this experience has taught me, is a way to communicate the vision of the product and the final result, so that the team could ask relevant questions and achieve the designated goal.

After learning my lesson from the ‘Dry run’, I was better prepared for the role of the client during Agile Lego Tests. My goal was to present the vision of the product, an error-free city, in such a way that a team of people not working in Agile on a daily basis was able to identify the priorities from the vision, take the mode of action, and create a city during three iterations. The vision of the city, for the purposes of Agile Lego Tests, did not abound in details, which was of key importance, particularly for testers, who participated in it. Capture as much details as possible, build an image of the city, then knowing that the availability of the client is limited, ask relevant questions – it was really a great challenge. Well asked questions brought the team closer to accomplishing the task, much better than during the try. The ‘project roles’, naturally selected during the project phases, allowed to control over the chaos. Interestingly, in a team consisting solely of the testers, the role of the tester was not clearly marked. There was an architect, a project manager, builder, but not the tester ...

Did it result in a quality decline during work acceptance after finishing the iteration? – I’ll leave this question without answer.

And at the end, here’s the list of my conclusions after the Agile Lego Tests workshops:

  1. Communication – the more efficient and cohesive, the better you shape the relationships with people and more efficiently deliver entrusted task.
  2. The ability to ask questions – this skill is valuable, when you’re working under time pressure and you are looking for the best method to solve the problem. By asking the right questions, you’ll reach to the heart of the solution more effectively.
  3. It is the whole team that is responsible for the quality of the product, not only the testers.

Participation in the workshops and playing the role of the client turned out to be a great challenge for me, and also, a valuable experience. Once again I was reaffirmed in my belief that a good product can be delivered only by a well-organized and well-communicated team, which clearly understood customer expectations. And ultimately, it was the greatest value that I gained from the workshops.

Data Driven Organisation Blog Ebook 416X300
Robert Kalina
I am a Testing Guild Master at Objectivity. I believe that working on strengths we can get the amazing effects. I use this philosophy in my daily work with project teams.
See all Robert's posts

Related posts

You might be also interested in

Contact

Start your project with Objectivity

CTA Pattern - Contact - Middle