For the last week I’ve been running a bit of an experiment in my classroom. Not in a scientific way (I think human subjects are generally frowned upon anyway), but in a take a risk in the classroom type way.
So, year 12 have been coding now for 5 weeks. The majority of them have never coded before and have been on one of the steepest learning curves they’ve ever known. It’s amazing to watch (and on occasions heartbreaking when you remember that awful feeling of ‘what was I thinking signing up for this?’), but they’ve moved on so far.
Part of the course is not just to teach them to code, but also introduce them to standard development models. The standard model that is used in academia is the Waterfall Method. This lends itself to an academic project so well as each stage is visited in a clearly defined block. For students, this also brings the benefits of being able to write the style of documentation that is required by the exam board. There are a number of reasons why it is wholly forgiveable for schools and colleges to teach this method as an introduction to the SDLC (I stand by this having instilled this in my year 13s who are creating a massive project under huge time restrictions!).
However, year 12s need to understand a variety of different methods and have a need to practice what they have learnt so far – mainly because at the end of this year they have a practical exam where they are expected to be able to produce working and tested code to a set algorithm within 2 hours, under pressure. So why not try Agile rather than just read about it in the book?
Monday: Sprint Development Meeting
I introduced the concept of Agile to both classes and asked them to self-organise themselves into groups of six or seven people. Within the teams, they would need to allocate a Scrum Master. I would be acting as the Product Owner and as such would have no influence over their decision of team or Scrum Master (in fact, I would be watching from a distance and evaluating how they organised themselves & silently telling myself not to interfere!).
As a Product Owner, I gave the teams the following goals (for a week… this was aiming high!)
- Create a game similar to the 1980s Simon Game
- The game should show a random pattern of 4 colours
- The colours should show on the screen for 0.5 seconds
- The screen should clear between colours
- The game starts with a pattern length of 1 & increases by 1 colour each round
- The user should be able to enter in the pattern they saw using the keys R,G,Y & B
- The game should repeat only if the user input is correct
After this, I gave them some stretch goals (because if I was going to be a client, I wanted the world on a stick):
- The game could output to the user how long it took them to respond
- The game could allocate a score based upon time
- The game could write the high score to a text or CSV file (5 weeks… they’ve been programming for 5 weeks.)
- The game gets faster after each round
- The code is made efficient with procedures
The world on a stick. And they had a week.
Every day for the past week, each team has met either in a classroom or via Skype (or Xbox Live!) for a 15 minute Scrum Meeting where they worked out how their team was doing and what they needed to do to achieve their goals. This wasn’t organised by me, but by the teams themselves. I was suitably impressed.
During the course of the week, I was asked for help by a number of the teams, either from individuals or from groups. In the most part, this was to help them move above their current understanding and to help them implement something that they had found online (one example of this was to help them create two parallel dynamic arrays – impressive stuff for a class who I haven’t actually taught arrays to yet!).
Monday (7 days later): Sprint Review Meeting
So today was our first Sprint Review Meeting. Each of the four teams did a live demo of their code so far and I was blown away, The effort they had put into this was astounding – they OWNED their code. (one team even linked theirs to a Makey Makey to give it extra playability!).
After each of the Sprint Review Meetings, we had a reflective session where every member of the team used an A4 piece of lined paper for a five minute silent write. In this, they could vent their feelings about how they worked as a team member, what went well, what they would improve and anything else that they felt that they needed to say in confidence. I then took these in with the promise that I wouldn’t share them with anyone (not even the internet – don’t ask!). What was most interesting was that those who felt that they could have improved had the clearest picture about how their team functioned as a whole.
So Agile for students has had a few unexpected benefits so far: The group dynamic has improved in both classrooms with students actively wanting to help others and share their knowledge in most cases (and where this didn’t happen, students have identified how to move forward), and more unexpectedly, almost every student without exception has worked autonomously to progress their knowledge without me guiding their understanding. They have shown Grit, they have shown resilience (of course they have, coding never goes right the first time!). I am prouder than a parent at a Nativity play right now.
So that was Sprint #1 – It may be a fluke. Even so, I can’t wait to see the product of Sprint #2.
Could this be the start of something new? Agile Dev meets Teaching : Agile Teaching?