One beautiful day when I was reading my e-mails I found a message from Daragh Murphy about a TeamSTAR Competition. I wanted to join the fight badly, so I forwarded the message to all testers in my company. Almost immediately Patryk Hemperek, Bartłomiej Bugajny and Robert Kalina answered and decided to participate in this competition with me. It was kind of fun, since they all are my direct superiors. Also hosting an event like this would be a first timer for most of us.
The main idea emerged under the motto “Testing to learn, learning to test”. We understood it as creating an event for testers with lots of practical learning for everyone. Even for us. 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.
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. It was for example:
|Lesson to be learned||Tool to achieve it|
|Theory and practice about agile methodology||One of us would be a moderator, responsible for presenting a theoretical background for our participants|
|Scrum rituals||Creating time boxed process and making theoretical introduction before each phase|
|Advantages of being agile in our work||Observer would point it out during summary at the end of workshop|
|Cooperation between strangers||This would be achieved by default. Additionally, we would prepare Lego sets in the way, that each team would need to exchange parts|
|Time management||We would create very short and time boxed phases|
|Chaos management||We would give one goal for many individuals|
|Impediments handling||We would stage the missing tool situation for one task|
|Working closely with client||One of us would be a client. He would be present and active during planning and sprint review.|
|Learning the technique of asking only direct and important questions||We would give only short time for asking questions|
|Focusing on goal and priorities||We decided to make only 3 iterations|
|Setting the main goal on quality||This would be a task for client to be gained by very detailed review sessions|
|Showing, that motivation is a key||Pointing during summary, that at the beginning no one believed that they have enough time and tools, while at the end they were able to finish the task|
|Learning through play||The whole workshop is about achieving 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 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.
Our plan required, that we are sure achieving the goal is possible in three sessions of 7 minutes by three to four teams. So we started experimenting with many Lego forms. Others from our company have joined our experiment. At the end introducing Lego bricks into Objectivity was crazy fun and super creative. They will definitely stay with us!
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!
Social media updated? Check. Posters hanging in our office? Check. Cookies and coffee on the table? Check. We were ready for the main event!
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. We gathered as much feedback as we could from out participants. We asked them what they learned during our 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, 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
More about our experience from client, moderator and observatory point of view you can read on our company blog.
We believe that organizing workshops like this one and exchanging knowledge in practice make us not only better tester, but also better workers and even better people.