Learn Scrum and Agile Using Paper Airplanes️

Build, fly, review, and iterate

Songtham Tung
Jan 21 · 12 min read
Original Photo by Daria Nepriakhina on Unsplash. Modified by Songtham Tungkitkancharoen.

I became inspired to write this article after reading a book on Scrum written by one of the original creators himself — Jeff Sutherland. While the book mainly focuses on why teams should use Scrum, the author did mention how he uses paper airplanes to teach it.

As I read those words, I remembered one of my coworkers making paper airplanes in the office one day. I also remembered that one of my quarterly OKRs was to introduce the Agile methodology.

So, I put two and two together, tried it with my team on the following Monday, and the results were electrifying.

The rest of the blog covers my experience introducing Scrum to my team with paper airplanes and goes over how you can do it, too.


Outline


1. Definition

Note: These are textbook definitions that only scratch the surface. To truly understand what they mean, you must learn by doing.

Scrum vs Agile vs Waterfall by Songtham Tungkitkancharoen
  • Scrum: A framework used to implement Agile methodology.
  • Agile: An approach to managing projects with continuous iteration.
  • Waterfall: An approach to managing projects in linear phases.

Project management is the common thread here.


2. How to Get Started

The materials needed are a stack of preferably used paper and a timer.

Sutherland’s instructions

Below is an excerpt from the book where the author talks about how he uses paper airplanes to teach Scrum.

Chapter 2: The Origins of Scrum

TL;DR

I’ve summed up the instructions into a single slide which I shared with the team below.

Learning Scrum with Paper Airplanes by Songtham Tungkitkancharoen

The main idea is that there is an objective to achieve and the way to accomplish this is through the PDCA cycle of planning, doing, checking, acting, and repeating.

Although I did not explicitly mention “act” in the slide, it can be inferred that acting — or to change the way you work based on results — is the natural transition between checking and planning.

Always reflect on what’s working and what’s not and ask yourself how you can make it better. This is key for continuous improvement.

“Fall down seven times, get up eight.” — Japanese proverb


3. What Actually Happened

After presenting the slide to the team, I asked if there were any questions or concerns. There were none. So I began with assigning the roles.

Assigning roles

The team consisted of six members excluding myself.

Although it isn’t explicitly mentioned, the person leading this exercise acts as the facilitator. As the facilitator, your role is to keep the team aligned, to keep track of time, and to help answer any questions that may arise throughout the workshop.

Photo by Danielle MacInnes on Unsplash

To assign the roles, I randomly selected one person for quality checks and one person for process improvement using “eeny meeny miny moe”. Feel free to use other random selection techniques like picking cards, rolling dice, and so forth.

You can also accept volunteers, but I prefer to leave it up to chance. You’ll soon find out that roles can and do change and eventually the right person for the right job will emerge.

Great! Now that we’ve picked our roles, the next step is to start the PDCA cycle.

First iteration

The first iteration started a bit slow to say the least.

I told everyone that they had one minute to plan and reminded them that their goal is to make paper airplanes that can fly across the room. I stood back and watched from a distance as discussions arose.

Some began prototyping while others were sketching various models. The quality check person that I’ll refer to as QA from now on asked me what they should do since they could not test anything yet. I smiled and told them to join the team in planning.

Photo by Lukas Blazek on Unsplash

The minute was up and I announced to the team that they had three minutes to do. Everyone in the team started building airplanes at this point, except for the QA.

Their role was to verify if the planes could make it across the room. Some gave their models for the QA to test, while others, incapable of holding in their excitement of throwing paper airplanes in the office, decided to test it themselves.

The team produced about six paper airplanes that were tested. None of them made it across the room.

I told the team to stop when the do phase was finished and that they now had two minutes for the checking phase.

Interestingly enough, the first question that the team asked me was whether or not it was OK for them to use a computer for research. I said: “Sure, why not?”

Team sitting locations

So they got to work. One person opened a laptop in the center of the group while another went back to their desk with their back facing against the team.

The QA was then telling the team how one of the models might be good since it flew the farthest and if it were optimized, they think that it could make it across the room.

Others were prototyping newer models. There were no discussions on how the process itself could be improved.

Second iteration

It was time for the second iteration.

When I told the team to transition from checking to planning, I did not notice any difference in the team’s behavior. One person even pointed out that there’s no difference in terms of actual work being done between checking and planning.

They were reviewing, researching, and strategizing amongst themselves about how best to accomplish their objective in both stages.

Photo by Kelly Sikkema on Unsplash

Their minute to plan was up and now they had another three minutes to do. You could feel the momentum shift and a groove starting to form. Team members were more committed to making the best paper airplanes and the QA was trying to perfect their testing technique.

To raise the stakes, I jokingly announced to the team that I, Songtham Tungkitkancharoen, would invest in their paper airplane company if five models successfully made it across the room during the final demo. To my surprise, this made the team go even harder.

Paper airplanes were flying across the room and some even made it to the other side. You could hear cheers and high-fives going around. I looked at the timer and it had about 90 seconds left.

Suddenly, I started seeing paper balls getting thrown across the room.

Photo by Turinboy on Flickr

One of the team members asked me if it was OK to do so and I paused for a second. Then I said: “Sure, why not?” There’s nothing in the requirements that prevents you from making paper balls.

In fact, there’s nothing in the requirements that actually specifies what a paper airplane is.

So, off they went, paper airplanes, paper balls, and eventually a paper airplane connected to a plush ball. This time, the team produced about nine planes and two of them made it across the room.

Not much changed during the check phase. The QA continued to give their input on which planes flew the best. You could see a “how to create the best paper airplane” article opened on the group laptop.

Various models were scattered across the table and floor. The one team member who went back to their desk with their back against the team was still there, focused in isolation on a YouTube video about making the perfect paper airplanes.

Time was up and we were now on the third iteration.

Third iteration

I began the third iteration by announcing that there had been a change in requirements.

  • Paper airplanes must be an airplane shape. (Hint: no paper balls!)
  • Paper airplanes cannot be attached to other objects.
  • Paper airplanes cannot be thrown past the designated area.
  • All paper airplanes must use tape.
  • All paper airplanes must have “M” written on it.

This time, in the planning stage, the person responsible for improving the process suggested on finalizing with the best variation and forming an assembly line to mass-produce it.

The QA was given the new responsibility of making sure there’s tape and an “M” written on every product produced.

Photo by Georgie Cobbs on Unsplash

In the do phase, more products were produced than one can test, so team members started testing their products themselves. One made it across. Then two. Then three and then four!

About a dozen paper airplanes were produced and four reached the other side.

Yet, they were still short of their goal. The plane that the QA threw which failed to make it across the room was the same plane that successfully made it when thrown by someone else.

In terms of the models produced, they still varied by two to three types, which made the results inconsistent. The plane that the lone member produced never made it across the room.

Time was up and the final demo was right around the corner. The team collectively asked for one more “sprint”, which is the agile synonym for iteration, and I agreed.

The last iteration

The last iteration was the most focused that I’ve seen the team.

The lone member rejoined the group. They then collectively decided on the best variation and divided the tasks in the planning phase, mass-produced one product in the doing phase, and tested amongst different throwers in the checking phase.

To put it simply, the teams were self-organizing and highly performant.

Actual plane models built during the exercise

Demo day

At last, it was time for the final demo.

I reminded the team that I would invest in their paper airplane company if five of their models made it across the room. It could be thrown by anyone, but once it’s thrown, it cannot be retrieved. This was the definition of success.

Photo by Stephen Isaiah on Unsplash

There was an eerie silence that resembled the final inning in baseball when bases are loaded, your team is behind by a few points, and you’re down to the last strike. All that’s left to do is to hit a home run and the victory is yours.

I took a deep breath and asked who wanted to step up to the plate and swing. The response was democratic. The people had chosen and they chose the member whose role it was to improve the process. I watched as they took their stance while the other members placed the finished models by their side.

With a continuous motion, they threw five paper airplanes. One directly after the other. And guess what? They all flew to the other side of the room. Every plane made it.

The team exploded in laughter and applause and was thrilled when I announced that I would be more than happy to invest in their paper airplane company.

Some members wanted to keep throwing their final products in more challenging locations to see if it can be successfully flown there, too. So I said: “Sure, why not?”

You could feel the electricity in the air. After a few throws, I took the team back into the meeting room and had a recap on what they learned from this experience.


4. Key Takeaways

Photo by Daiji Umemoto on Unsplash

Perhaps the most important lesson that I took from this is that the more you do something, the better you get. The challenge, however, was communicating this in a way that connects to the larger picture of agile methodology and project management.

I began by asking the team a simple question: “What is Agile?” We hear this term thrown around a lot in the startup scene, but do we truly understand what it is?

Some mentioned that agile is quickly responding to change. Others added that it’s cyclical. The benefit of this is that we can learn from our mistakes and improve in the next iteration.

Yes! Yes! And more yes! You’re all correct. Agile is what everybody said and more.

Because we’re using Scrum, one of the key elements of this framework is the Scrum Master — or the role that looks for ways to improve the process itself. And the process did improve (QA switching roles, forming an assembly line, and teaching the best design to name a few).

This is symbolized with the additional loop in the “Scrum vs. agile vs. waterfall” illustration. Agile is a process and Scrum is an approach to make this process even better.

Paper Airplane Results

Afterward, I gave the team a recap of each iteration or sprint:

  • First sprint — Six planes produced. Six variations. Zero success.
  • Second sprint — Nine planes produced. Four variations. Two success.
  • Third sprint — Twelve planes produced. Three variations. Four success.
  • Fourth sprint — Eight planes produced. One variation. Five success.

While the quantity produced fluctuated, the general trend shows that variations decreased since weaker designs were ruled out, and what increased was the successful flight of each iteration.

In other words, the more airplanes the team built, the higher quality they became. Their speed of production also increased, but decreased slightly in the fourth sprint since one member had to teach the rest on how to produce planes using their product design.

That’s not all. To drill the point home, I painted a scenario that juxtaposes agile and waterfall: Imagine if we had to accomplish the same objective using the waterfall method?

Waterfall Diagram

While the diagram does look nice, planning, doing, and checking is separated into different phases. Once you advance to the next phase, like time, you cannot go back.

This means that, for example, there’s no learning from your mistakes in the implementation stage and then going back to fix them in the design stage.

The process is linear. You have to do everything upfront in each phase and hope that it’s perfect and pass it on to the next person and hope that they get it right as well.

There’s a lot of hope in here and I don’t like depending my project deliverables on hope. That’s a recipe for disaster.

“A lot of times people don’t know what they want until you show it to them.” — Steve Jobs

Instead, I would rather bet my project deliverables on high performing self-organizing teams that can respond to change quickly and have something to show every sprint instead of only once at the end.

By delivering in short cycles, customers can tell you if what you’re producing is truly what they’re looking for. And most of the time, people don’t know what they want.

Recall that requirements changed in the third iteration because of the paper ball introduced in the second. How would responding to change look in the waterfall approach?


5. Conclusion

Thanks, Riyad Sharaf for capturing this moment

Congrats if you made it this far — this is not easy stuff.

We’ve learned the agile and scrum project management approaches by creating paper airplanes that can fly across the room using a few sprints. As simple as it may seem, this concept can be applied to your actual work.

Instead of viewing long-term projects as something where you only deliver once and at the very end, you can break it up into smaller, workable pieces and deliver results in increments. Your customers will thank you for it.

Thanks for reading! Let me know how it went for you in the comment section below. I’m curious to learn more about your experiences with agile, scrum, and/or waterfall.

Perhaps one day, we can also be like Elon Musk and build rocket ships that will fly across the universe.

SpaceX Learning from their Mistakes

Better Programming

Advice for programmers.

Songtham Tung

Written by

Technical Product Director @ Geddit | SF Native x BKK Resident 🇺🇲🇹🇭 | #b2b #saas #cloud

Better Programming

Advice for programmers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade