Lego automation workshop by Richard Bradshaw

This year, I had the opportunity to attend Lego automation workshop at Test Bash hosted by Ministry of Testing. The workshop has been running for 2 years and I have heard many positive comments about it. Obviously, I had many questions  How can someone learn about automation with Lego? Are they using Lego mechanics? I have only seen Lego Duplo on tweets, they are just big blocks; can they be used for automation? How automation and Lego will joined up together?


The workshop was about automation theories. We had to pair up, one became the robot/program, and the other became the programmer. There were five challenges, which had their own learnings. I paired with Yuki (@k_k710). We were given different images of shapes to build, and the programmer had to write instructions so the robot/program could build it. It sounded simple. However, it had its own complexity. Language had to be simple, should be understood by the program, assumptions needed to be set, etc.  Then the robots had their opportunity to run the program. Pick Lego from different locations, bring them back to the table, and fix them as of the instructions and compare with the original picture. Robots were robots. They could not think. Therefore, the robots bumped in to other robots. Different sizes and colours made them confused. How to fix, how to compare. Long instructions got them confused. Things got complex when we swapped the scripts with other teams. Some found that the instructions were difficult to understand because they were very technical, or assumptions were not clear. Whether raised concerns were issues or not. Next, we were given more complex images, we had to then refactor the instructions build the new shapes. On top of everything, we had to keep the instructions simple so the mindless robot can execute them. What we had to remember was that robots could only see what we told them to see. They could not decide anything by themselves and could not see anything that we did not ask them to look at. Lesson learnt. Thank you Yuki for being such a great robot!


Did I enjoy being part of the workshop? Yes. Was it instructive? Yes. Was it memorable? Yes. Was it entertaining? Yes. I believe these are the characters of a successful workshop.


So what did I learn? What made me think? Reminders that I needed?

  • Fine details on a script will make a difference
  • Give the robot the ability to voice what’s happening – logs / messages
  • Define how detailed each test should be. More detailed, complex they become.
  • Experience in writing code makes a difference
  • KISS – Keep It Simple Stupid
    • Start tests simple
    • Improve later
  • Complexity emerges but
    • We are learning while we code, and we explore
  • Who do you want to be?
    • A programmer; thinking about design and code, or a
    • A coder; who just writes code
  • What do you want to do?
    • Check – Does it do what exactly you asked it to do?
    • Test – Think logically and be critical
  • Give people the space to figure things out. Let them learn than instruct
  • Make sure your code is understandable by others
  • Get away from the IKEA effect
    • I built it, so it is fantastic!
  • Utilise the code and improve re-use


Richard summarised the workshop with following image. He gave many examples from his experience for each point. He mapped the points to what we experienced that day.


I agree with the points he raised. One thing I realised was that I knew these things. I had experienced these things as well. I also knew I should adhere to these things. However, do I practice them? Do I know why I should practice them? Do I understand the consequences?


The workshop was targeted for everyone. Anyone who wants to understand the complexity of automation were welcome. I saw a clash between the novice and experience. Yes, we can learn from each other and see different point view. However, this can make some participants get a bit isolated or drift away. May be this workshop could be promoted for beginners and then extended it to experienced audiences. This might help each audience to focus on what they wanted to learn than try to find things to learn and enjoy the workshop at the same time.

Well, that is just from my point of view.

Why you should go to the workshop? It gives you a different perspective. You will learn about the basic automation concepts, use different programming languages to reach your testing goals, using different methodologies and best practices. You can attend the workshop to get a good understanding of them by simple exercises. Learn and share! I highly recommend this workshop; I hope you will enjoy it as I did.

Recreate Building Quality in With Distributed Teams

After attending an exciting and educational workshop in Brighton (read more), Steve (@sjwatsonuk) and I decided that, we should recreate the workshop for our colleagues in Reed Business. I am very grateful to Lisa (@lisacrispin) and Abby (@a_bangser) who not only helped us with sharing all materials but with plenty of encouragement as well.

Since we are a big organisation with many different projects, we thought to stick to the projects that we are in as the pilot. We also included members from a team who deals with internal clients as well. The presentation tweaked but the rest of the workshop was as it was originally.

The teams were well mixed up and distributed over different floors (we were not able to book the rooms in the same floor). We took the liberty to mix and match people and that they work with majority of people that they do not know than the number of people they know.

We got two excellent and exciting helpers as well. Saima Poorghobad and Michael Lopez (@lopezma) was continue to support us by showing thing that we have not noticed. Fantastic!

All started well on the workshop. Steve and I had a plan but not rehearsed a thing. Therefore, we thought we would improvise as things go. We got people to talk. They came up with the issues that they face with working with distributed teams. Everyone was facing the same issues such as communication, culture, language etc. The examples we gave related to each business. We also mentioned the internal teams that support different projects that have a different level of distributed team challenge, which normally overlooked.

Then two teams sent away to different rooms with their tools. Straight away communication issues bubbled up. Lync was not working properly. Sound quality not there, video not working.

In the team I looked after as the Product Owner (PO), rushed to get in to work without even looking at the schedule. They wanted to get things done. Therefore, the inception and planning sessions were almost wasted. Many assumptions made. They did not ask me the right questions in the beginning until I clearly said I am not happy with the work they done. Offshore was asking what my favourite colour was than asking the right questions. Then they all started asking what my requirement is for each individual piece of work than one person dedicated for that – because of not planning the session and not assigning roles. Offshore team tried to gather the requirement with the work that they assigned but it was harder. Therefore, Lots of frustration! Time pressure! People running up and down! It was chaos!

In the retroactive it was highlighted that product owner did not have any bandwidth to answer all questions. I hinted saying I would be happy if one person talk to me than all. It was fascinating how teams forget the basic roles under pressure.

Another thing I observed was that the offshore team were trying their best to get the attention from the onsite team but they all busy either talking to me or colouring away. The offshore contact had to talk very loud several times and to shout to get the attention. Also later, I have to know that they were there with less or no work for most of the second sprint.

Everyone came back together and discussed the issues that each team faced. Offshore teams were frustrated and was very vocal about the whole thing. Then we decided to give additional 5 minutes to the teams to decide how they want to do the next sprint from the challenges they have/had. That was something Steve and I came up at the time so the people can learn the importance of planning and communication.

There were team members who wanted to talk to me and gather requirements while the planning, share information and retrospective sessions. This shows how people want to get on with their work than making sure they work as a team and achieve a common objective. Alternatively, let the others do the communication while these individuals busy with the ball rolling. Either way it was not helping the team.

The third sprint was a success. Steve and I took 2 minutes holiday and done a change of mind on a requirement. Teams did not seems to mind it at all. The requirements gathered for most of the work so they were caring out the work. How great is that!

Later we talked about the culture differences a bit more. I talked with my personal experience. As I speak about how other side of the table might be thinking I saw some eyebrow raises, nodes, note taking, and look of surprise. I might have invoked some thinking and awareness.

At the end, there was real light bulb moments in most people on how to do things differently. We asked what they would do differently and things like make sure communication issues (technical, non-technical) resolve sooner than later, involve product owner with offshore discussions, gather / clarify requirements early, make sure the offshore see the bigger picture and be more understanding are some of the things came out.

Well, all workshops we have people who think it is a waste of time, as they know the subject better. We had couple of them and they had given us negative feedback. One response was that, that person already knew these challenges and nothing new. Well in my point of view, everyone knows the issues but how they react to solve the problems is the key.

Two negative feedback against 21 from 23 participants. I take that as success!


Next, we have to collate the feedback and present to a wider group and who knows we might be able to take another group of people the same journey and help them to build quality with their distributed teams…

We learned a lot how this could improve. Such as dedicate someone else to coordinate the timing, bit more descriptive in the inception, bit more organised with the rules and do some adjustments to the schedule.

You still reading? Great… Few more lines…

Finally would like to thank Steve for encouraging me to do this workshop and made me believe that I can talk in front of many people without making myself a fool. Great co-host to work with. In addition, Saima and Michael was so helpful and given us fantastic feedback. Could not ask for more enthusiastic helpers than them. We were very lucky.

In summary, it was a great experience for us and as for the participants. Looking forward to recreate the workshop and of course looking forward to learn more.

If you like to read Steve’s experience you can find it here.