The Agile Classroom: Embracing an Agile Mindset In Education
In 2001, a group of 17 software developers met at the Snowbird resort in Utah to discuss alternative ways of building software, and published the influential “Manifesto for Agile Software Development”. The roots of the Agile movement can actually be traced back to the 1930s and 1940s at Bell Labs and Toyota, but the work at Snowbird in 2001 proved to be a tipping point. It was the manifesto that first coined the term Agile for software development and that explicitly laid-out the 4 key values (see image below) and 12 operating principles that, since then, have underpinned the Agile mindset.
Fifteen years later, Agile has become a global movement expanding well beyond the software industry. It has spread into an array of organizations and functions, and even into the C-suite. According to a recent Harvard Business Review publication:
“National Public Radio employs agile methods to create new programming. John Deere uses them to develop new machines, and Saab to produce new fighter jets. Intronis, a leader in cloud backup services, uses them in marketing. C.H. Robinson, a global third-party logistics provider, applies them in human resources. Mission Bell Winery uses them for everything from wine production to warehousing to running its senior leadership group. And GE relies on them to speed a much-publicized transition from 20th-century conglomerate to 21st-century ‘digital industrial company’.”
It’s easy to see how this came about. At its core, Agile is all about innovation. It’s about dealing with uncertainty through incremental work delivered by self-organized and motivated teams, that are capable to adapt and respond to change. In today’s fast-paced and growing digital economies, navigating through uncertainty is essential to survive. “[Agile] permits firms”, writes Steve Denning in Forbes, “to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous”.
It’s common to mistake Agile for a methodology. After all, people often talk and write about Agile methods, Agile frameworks, Agile practices, and Agile techniques. There’s even a website called agilemethodology.org. Interestingly though, the first line in that website reads: “Not a methodology”. Which is true: Agile is not a methodology; it’s a way of behaving, it’s a culture, it’s a mindset. That’s precisely why the Agile Manifesto is a composition of values and principles: the two most important elements that underpin culture.
AGILE IN THE CLASSROOM
The beauty of Agile being a culture is that you can apply it to any organization, and to any aspect of work. And that’s precisely what we’ve ventured out to do at Laboratoria. We are applying Agile values and principles to education. What follows describes how the Agile culture has shaped our approach towards teaching coding at Laboratoria.
I. Running Sprints, not Marathons
A key Agile principle is to work on “incremental product development, delivering frequently in weeks, rather than months”. In other words, it’s better to run several sprints than just one marathon. Working on short development increments allows for a shorter feedback loop, making it easier to adapt and respond to change. The end of every Sprint is an opportunity to reflect on what happened, gain learning, identify improvements, adapt and change course. In environments of high uncertainty (that are, therefore, unpredictable) long feedback loops can be a recipe for disaster.
Education, unfortunately, is a field that traditionally runs very long feedback loops — with semesters being the preferred unit of time for achieving learning outcomes. In contrast to this, at Laboratoria we run Learning Sprints. A Learning Sprint is a time-boxed effort (usually 2 to 3 weeks) in which students commit to achieving certain learning outcomes. Each Sprint starts with a Sprint Planning Meeting, where students plan ahead and size the amount of effort required during the next few weeks. Each Sprint ends with a Sprint Retrospective, in which students reflect on the work carried out, identify lessons learned and determine areas for improvement.
Learning Sprints allow students to receive feedback early on. Giving students frequent and early feedback is crucial: research shows that students are poor judges of their own ability, tending to overestimate their level of competence. Most worryingly, the least competent students are the ones most out of touch with their performance level — and hence, least likely to change behavior. The end of a Learning Sprint is a great tool for students to “calibrate” themselves, comparing their performance against expectations and against their peers. Moreover, since the Sprint ends with a Retrospective, students also learn the power of reflection as a key driver of continuos improvement. Short feedback loops also enable teachers to spot problems quickly and make appropriate interventions.
II. Learning Squads
Agile is also about teamwork and collaboration, “valuing individuals and interactions above processes and tools”. That’s why, at Laboratoria, students learn in teams. As a tribute to Spotify — a global benchmark of running an Agile Culture — we call these teams “Squads”.
A Learning Squad is a group of 6 to 8 students that work together as a team to complete the goals defined in a Sprint. Learning Sprints are designed to have goals at the individual level AND at the Squad (group) level. Hence, students are not just preoccupied with their own learning, but are also concerned with their teammate’s advancement.
Every Squad has a coach (somewhat equivalent to the Scrum Master role in a software development team). Since we’re Star Wars fans, we named these coaches “Jedi Masters”. The Jedi Master’s role is to identify and eliminate learning barriers the Squad faces, and to foster teamwork and collaboration amongst the group.
Following the Agile principle of “close, daily cooperation between business people and developers”, the Squad meets daily with their Jedi Master to perform a Daily Standup. During the Standups, each student answers 3 key questions:
- What did I accomplish yesterday?
- What will I do today?
- What obstacles are impeding my progress?
Squads are independent and autonomous i.e. they decide how to plan the Sprint, how to organize themselves, and how to track progress. Regarding communication channels, for example, some Squads decide to use Slack, others create WhatsApp groups, others simply use G-chat. In regards to organization, sometimes teams decide to divide the work in pieces and each student (or pair of students) leads a piece. Other times, they all decide to do all the work and compare results. It really depends on the Squad, the task at hand and the goals. We’ve found that having independent and autonomous Learning Squads working towards an end-goal (tied to a learning milestone) is a great way to put students in control of their own learning process. At the same time, it’s proven to be, by far, the best way to teach collaboration and communication skills.
One final catch about the Learning Squads: at the end of each Sprint, new Squads are formed. We do this to build adaptability skills. With this, students learn to be comfortable with building new working relationships every 2 or 3 weeks. It’s also a great way of keeping the team spirit at a class level — not just at the Squad level.
III. Gamifying Education
Another key Agile principle is to build projects around motivated individuals. With student motivation in mind, and taking cue from video game design, we decided to re-contextualize grading. “From games we’ve learned” argue the folks at Extra Credit “that progress encourages progress, and that human desire for efficiency is a far stronger motivator than the fear of falling further from one’s goals”.
For this reason, at Laboratoria, instead of having a traditional grading system, we have a points-and-reward system. Students start at zero points and earn points as they go.
Students earn points in three distinctive ways:
- Points for effort: students are rewarded for completing certain activities, (like providing feedback to a peer) whether they do it well or not. These points value effort, not performance.
- Points for performance: students also earn points for doing well certain activities. The better they do it, the more points they earn. This is typically the case of Problem Sets, where to earn the full amount of points, students must correctly solve the problem AND demonstrate having used best coding practices.
- Points for outstanding work: students also earn points for demonstrating outstanding behavior in certain areas, like teamwork, communication and any other behavior teachers want to foster.
Additionally, we’ve built-in other incentives that foster collaboration among the Squad and among the entire class. So, for example, if all Squad members achieve the individual goal of the Sprint, the Squad gets invited to a fancy dinner. Similarly, if at least 80% of the students achieve the individual goal, the whole class goes out to a field trip, or we organize a movie and pizza night.
We are still scratching the surface of gamification as a motivator, and still have much to improve. An unwanted consequence, for instance, is that some students get caught-up on the issue of points, losing sight on the overall goal of learning. That’s something we are currently working to improve.
IV. The Art of Reflection
Agile is also about using reflection as a driver for continuos improvement. One Agile principle reads: “regularly, the team reflects on how to become more effective, and adjusts accordingly”. At Laboratoria, we foster reflection at 3 levels: i) at the individual level, ii) at the Squad level, and iii) at the Classroom level.
- Reflection at the Individual level
Individual reflection is embedded within the lesson structure. As shown in the figure below, every lesson at Laboratoria follows a similar structure. A lesson always starts with a pre-work, forcing students to face new material on their own. The reason for this is twofold: first, it allows for students to develop self-learning skills; and second, it makes the lecture time much more productive because students already come to class with a clear sense of where they need help.
After completing the pre-work, students are quizzed. This provides them with immediate feedback (an initial “calibration”), while also granting the teaching team a reference of students’ knowledge of the topic to be taught. Quizzes are graded on-the-spot, and results (Squad’s averages and Squad’s maximums) are shared with the class (see image below).
After the quiz, we have lecture time and practice time. Since we believe that practice makes perfect, most of the time at Laboratoria is spent working on Problem Sets — not on lecture.
After the allotted time to work on Problems Sets is up, students are provided the correct solutions/answer keys. With the answer key on hand, students are asked to compare it to their work, analyze their results, and reflect on it. This reflection is compiled in a short self-assessment survey that students complete at the end of each lesson (see example below).
We also ask students to compare the answer key with the work of a fellow teammate, in what we call “code review”. This is a powerful tool to (once again) provide feedback and encourage collaboration. Finally, the lesson ends by unlocking further reading material for students that want to dig deeper.
2. Reflection at the Squad level
Each Learning Sprint ends with a Sprint Retrospective meeting. During this meeting, every Squad — independently — answers the following 3 key questions:
- As students, what did we do well?
- As students, what could we have done better?
- As students, what new thing can we start doing to improve?
3. Reflection at the Class level
In order to ensure lessons learned are broadly shared with everyone, a student representative of each Squad shares the “highlights” of their retrospective with the class, along with 1 or 2 recommendations for a successful learning experience that Squads can adopt in future Sprints.
The learnings of the Sprint retrospective are documented in an “Improvement Board”, that consolidates action items that need to be improved; and a “Definition of Awesome Board”, that records the “best practices” every Squad should follow to succeed.
We also encourage “Storytelling Moments” every month or so. This is when a Squad (or a group of students from different Squads) share their experience of achieving something extraordinary. For example, when a group of Laboratoria students in Lima won 3rd prize in the “Ni Una Menos Hackathon” held at the Pontificia Universidad Católica del Perú (PUCP), we blocked a few hours during lecture to hear about it!
The End Result = Higher Student Engagement
When we first thought about including Agile principles in the classroom we were motivated by teaching students how tech companies operate. The concept of running an “Agile Classroom” started as an experiment to teach Agile in a very practical and hands-on way. We wanted students to be better prepared when joining software development teams in tech companies.
Today, however, after seeing the extraordinary results of the “Agile Classroom” — in terms of student engagement, speed and breadth of knowledge mastered by our students, and their growth in terms of socio-emotional skills — we no longer see Agile as a curricula item. It has become part of our education model. The fact is that by embracing Agile culture we have become better educators. Agile has turned out to be a critical component of Laboratoria’s “secret sauce” to build a better and more engaging education model. One that grows a deep love for learning in our students, building their confidence by showing them how much they can learn when the right values and principles are in place. In the end, the Agile Classroom is not only preparing them to excel at their first job as developers: it is preparing them to become well-rounded women, ready to make the most of this “volatile, uncertain, complex and ambiguous world”.
As it turns out, other people are also experimenting with the concept of Agile Schools and Agile Classrooms. If you want to learn more about this, please check the following resources: