Last week we started a pilot to use Scrum for education, based on the eduScrum-initiative and the Agile Education Compass. The pilot is part of a research project to find out how Scrum can help us integrate 21th century skills with bachelor ICT and media education. Time has flown fast and this is what we learned so far.
1. Introducing Scrum takes at least three hours
The pilot is performed in two ICT classes (and two non-scrum classes for the same course in parallel that we can use as a control group) and 2 media classes. Due to the exam schedule the ICT classes just had one session (3 hours) to learn the rules and the process, the media classes took some more time: three sessions during the first week. Looking at the results after one week one session seems to be sufficient to work with Scrum, but we are interested to see if a longer (calmer….) introduction pays off in the long term.
2. Team formation based on personal qualities actually works
The eduScrum initiative described several ways to create teams, but most of the involve personal (core) qualities. We decided to create a short form with 20 aspects like planning, organising, researching, writing, presenting and listening. We asked students to select three aspects, write their name on top of the form and fold the form so the name is not visible. We randomly selected teamleaders and asked them to select forms of other students based on the qualities and the value of these qualities for their team. After unfolding the forms and disclosing the names of the team members the teams were set up and ready to start creating the flap:
3. Building teams starts with building flaps
The flap is the one single stop for planning, quality and learning. We insist on using a big paper flap instead of a digital planning board because creating the physical flap is a great team building activity. We also want to teach the teams to take responsibility for something small but precious before being responsible an a larger scale. The team is responsible for creating the flap but also for the availability of the flap in the classroom, no flap = no status. Taking pictures of the flap on a regular basis appears to be a nice backup plan.
To explain the why of the paper flap to the teams I used the example of my kids taking care for the rabbits: they first need to learn how to take care for the rabbits before we consider taking a dog (taking care for a dog takes more time and dedication, I wouldn’t dare to say that dogs are more valuable that rabbits 😉 ).
We left the design of the flap to the teams but Google appeared to be their friend, so most flaps are similar. Some teams got really creative with colour coding their post-its with tasks. We saw different colours for:
- different task sizes (smallest task 30 min, average task 1 hour, largest task 2 hours)
- different task assignees (individual, pairs, group)
- tasks belonging to a certain story having the same colour for the post-it
4. Inspect & Adapt is also for teachers
We have the luxury of teaching the class four times a week for a session of three hours with a sprint duration of two weeks.
Every session starts with a short introduction of a new subject, followed by the stand up meeting and a two hour time box for the team to work on tasks. When you watch the schedule more closely you see we originally planned the stand up meeting before the classroom training, but that required too much context switching for everyone so we changed our process.
The sessions ends with a short retrospective on the session: what went well? what can we do better? any learning impediments? It enables students to inspect and adapt but also enables us as teachers to reflect on the session. Instead of a course evaluation at the end of each period (8 weeks) we have 32 small evaluations: a simple way of continuous learning for students and teachers (we prefer the word teacher to lecturer although lecturer is more common at a university).
5. Learning objectives formulated like user stories
In Scrum it is very common to use user stories to group tasks. Although eduScrum uses a single level of tasks we decided to add an extra level based on user stories. It helps us to introduce a new subject (or theme) every session and describe a single story for every subject. For the first and second sprint the stories and acceptance criteria are predefined by teachers, for the following sprints the stories and acceptance criteria need some extra detail and specification by the teams.
We have several kinds of tests: programming assignments, a research report and a case study. For the report and he case study the normal user story format seems to be fine, but the programming assignments are performance assessments: students learn and work in teams for two weeks and the sprint end with an individual assessment. Therefore we tweaked the user story format to be able to describe learning objectives that address what, why and when:
- what is the learning objective, subject or theme?
- why is it necessary to learn this specific subject, what is the purpose?
- when is the story ready, what are the acceptance criteria?
The format we came up with is:
As a student, I need to learn <learning objective = what> so that <learning purpose = why>.
For example: “As a student, I need to learn Maven so I can automatically build, test and run applications with a script”. Just like a normal user story a learning story comes with a specific set of acceptance criteria (the when).
6. Acceptance criteria are key
How do students know they learned the right stuff? Acceptance criteria helps us to create small “requirements” and during the first week we saw it also helps students to scope their learning efforts. Given the Maven learning objective we created the following criteria (the last line gives a concrete hint where to stop with learning Maven):
- Student is able to add one or more external libraries with a Maven dependency
- Student is able to upgrade versions of current dependencies
- Student is able to use Maven on the command line to run, test and package a small Java application.
- Student can use an IDE like IntelliJ or Eclipse to import a Maven project and build a small Java application.
- Student does not have to know how to use Maven in a multi module setup.
7. Introduce something new using well known methods
Because of the short time we had for introducing Scrum we decided to use plain old planning methods (e.g. work breakdown structure and the critical path) for the first sprint and learn planning poker (or other methods to interactively estimate work) later. Looking back, we also had the advantage for students to apply well known methods that helps students to learn Scrum more gradually instead of all-in-one. The choice was a pragmatic one, but for now everything turns out to be fine.
8. Learning artefacts and the DoD
After a short introduction by the teacher the team has a two hour time box to perform learning activities. During this time box the students can choose if they need to:
- do exercises
- read (parts of) a book
- watch one or more PluralSight (PS) episodes
Regarding the Definition of Done (DoD), the teams were very creative with defining the DoD: when are we satisfied with the learning outcome? Most teams have a DoD that describes:
- summarizing theory from books
- prepare a short presentation about the new stuff
- create an outline of the PS-screencast together with start and end times of must-see fragments
- create small tests (questions checked by one or more team mates)
By attending the stand up meetings and following the flap, the teacher decides when, where and how to help.
Next week the teams end their first sprint with a sprint retrospective and a individual test (in my course a programming assignment about Maven, Unit Testing, Exceptions, Threading and Remoting). We learned a lot in just one week, so why not learn just as much in another week? Another week = another blog!