The main idea for creating this event emerged under the motto “Testing to learn, learning to test”. We saw it as an opportunity to share our knowledge with less experienced testers and to learn something new from them.
We wanted to build a common ground and provide the participants with a firsthand experience of working in Scrum as a team with a cross section through the entire cycle of our work – from planning to retrospective. This way we had an idea, we even had a target group – the time came for preparations. First, some numbers:
The first meeting was on 4th of July. At this meeting, we decided that we would plan our workshop just like in agile methodology – by dividing the tasks and constantly checking the continuous improvement. At first, we created our page, so we could start gathering applications for this workshop. Also, we prepared a draft plan for communication on social media – company LinkedIn, Facebook event and page, twitter and information about the event on other sites (testerzy.pl, CarpeDiem, WhereEvent, AllEvents). We wanted to make sure everything is clear for our participants, i.e. why we do it, who we are and how we prepare for the main event.
During one of our meetings we wrote down everything we want our attendees to learn and how we want to achieve it. With this knowledge we created background story and detailed tasks. We even drew a map, that could be divided into sections. We decided to ask our teams to build from Lego blocks:
- Hospital quarter with main priority
- Residential area as the secondary objective
- Park terrain mixed between villa and common buildings
- Living quarter for the final task
Next thing on our list was to build our own adaptation of Lego for Scrum. Since we were inviting people not familiar with agile methodology we decided to start with some theory. Then client would show up and share his vision of what needs to be built. This would imitate Business Analytics going to the real life client and gathering requirements for the projects. With his knowledge teams would build the list of tasks to do – Product Backlog – and order those tasks by their priority. We knew that during this phase a lot of questions would appear, so to avoid frustration for our participants we created a short phase called Question & Answers. This would imitate fast call to the client to clarify some questions at the beginning of the project. With this knowledge we could go into estimation, just to teach our attendees how to assess the difficulty of the task. For the main event we planned a short break after that, so we can talk and integrate a bit before the hard work. Then we would go into typical cycle of work – planning, work session, review with the client and retrospective. We planned three sessions – first would probably be a disaster, second would be better with all fixes after client review and third would show our attendees that achieving the goal is possible. After that our plan is to sit down with pizza and exchange lessons learned.
We couldn’t run this workshop for the first time for our applicants. We decided to first check it on our own colleagues. To make it more fun and instructive, we invited not only testers, but every single co-worker from our company. This way we had totally different points of view on our workshop.
During this dry run, we not only learned a lot – we also decided to introduce this workshop to newcomers at our company as a permanent solution. Interested how it looked like? Check our gallery to learn more: AgileLegoTests Dry Run
At the end, we felt everything was prepared – every single task marked as “done”, knowledge in our heads, hopes in our hearts and a smile on our faces!
We had 33 requesters for the main event. At the end, we held this workshop for 12 participants in total. It differed so much from our dry run! All our participants were very focused on the task. They listened quietly to our client and wrote down every single word he said. When they started to ask questions – they were very smart and direct, so they gained all necessary knowledge in the blink of an eye.
With these notes they prepared the backlog and assigned the priorities without any problems. They even had absolutely no problem with splitting into three teams. They called themselves Agile Frogs, 3MA and Team Under Window.
And then the chaos came in! The planning with that many people cannot be quiet and orderly. This chaos moved to the next, execution phase. Missing Lego blocks combined with short time didn’t help. So as suspected – the first sprint review with a client was very hard, because nothing was delivered. But our participants learned their lesson – with each next phase they were working more efficiently without making the same mistakes.
After 3 sprints and a short phase of bug fixing, Test City was built and accepted by the client. In the end observers shared their knowledge about what was happening in each phase and how it is a lesson about working in Agile. You can check all the fun we had in our gallery: AgileLegoTests Main Event
“Learning to test,…”
We shared our knowledge with wide variety of participants with hope, that this experience will make them better testers. At the end we gathered as much feedback as we could from our participants. The question we asked was “What you learned during this workshop?” and they pointed out:
- How important is a tester role (that he verifies client requirements before deployment)
- How agile works both in practice and theory
- That it is awesome to see our work moving forward and that it gets challenged by a client
- How we can adapt agile in our work to make it better, faster and smarter
- Management techniques trained in practice
- Problem solving techniques learned
- What is MVP, why we use it and how it works
- How important is retrospective
We were also very proud, that this workshop was fun for our participants. We even wrote down funny moments and shared it on our Facebook page. This way the lessons will stay with everyone for the long time.
“… testing to learn”
After this workshop each of us pointed out top 3 lessons learned from this new experience.
- Communication – the more efficient and cohesive, the better you shape the relationships with people and more efficiently deliver entrusted tasks.
- The ability to ask questions – this skill is valuable, especially 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.
- Quality – it is the whole team that is responsible for the quality of the product, not only the testers.
- Observation – it is a good practice, to stand outside of the process (or a meeting) and observe how things are going
- MVP – when we deliver a first version to the client, we can get a quick feedback and build a product which meets his expectations
Finally we believe that organizing workshops like this one and exchanging knowledge in practice make us not only better testers, but also better workers and even better people.