Driving Collaborative Projects using an Agile Methodology

About 12 hours after arriving back from #elc14 and I’m about to walk into a class that I can honestly say I completely did NOT plan…not even think about it until I was stepping across that threshold. There, I’ve admitted it, I was winging it (again). Eighty minutes later I emerged having taught one of the best lessons ever on the most boring, dry, would-rather-stick-needles-in-my-eye topics, Project Management, a High Level topic in the IBDP Information Technology in a Global Society (ITGS).

Why? For me, one of the big takeaways from #elc14 was agile development. It was mentioned in at least two workshops – Ewan McIntosh and in a Shanghai American School presentation. We have to study agile development in IBDP ITGS so I decided to apply the principles to move along a rather stagnant project.

Essentially Agile development is a methodology that is used by lean start ups and software developers, especially gaming. It relies heavily on client input and is developed in stages, known as sprints, with defined outcomes (or deliverables) for each sprint that generally can provide an income for the company. The key is the rich in-the-moment client and customer feedback that is essential to determine the next set of deliverables that will be schedule for the next sprint. This agile development method mitigates risk as there is constantly a feedback loop allowing projects to pivot or proceed.

Also appealing to student (and adults), is the fabulous terminology.  In today’s class, we appointed a scrum master – the leader of the project. The project is divided into sprints where each sprint is allocated a set number of days and the scope of the sprint is defined by what the team can accomplish and deliver to the client what is known as the sprint burndown (the number of days of each sprint). Unlike a more traditional, waterfall style project, where the requirements specifications are defined and more or less fixed close to the start of the project, in this method, the requirements are developed throughout the project in terms of user feedback and client requirements. These are knows as user stories, which capture the essential element of any client experience, empathy. Agile development lends itself to projects where the end goals are not clear as the direction is dictated by the client and customer feedback and documented as user stories – hence lean start-ups where it’s essential for the business to be creating revenue from almost day 1.  If you recall the development process for amazon.com:

  • For the first sprint, the deliverable was a website that sold limited range of books using an online catalog and shopping cart.
  • Sprint two may have been based on the customers desire to have an interactive experience, by posting reviews and comments about the books.
  • Sprint three may have been the introduction of alternative payment methods, such as PayPal in addition to another deliverable, such as client wish lists and diversifying into electrical goods and so on.

With a clear reflective process after each sprint, the user stories are generated and developed to help the team and the client decide where to go next. A truly market-driven endeavour.

When the team is in the midst of a sprint, at the beginning of each day, there is the daily scrum, a 20 minute stand up meeting where each team member answers the following three questions:

  1. What did you do yesterday?
  2. What will you do today?
  3. What obstacles are in the way?

These are recorded and the scrum master’s role is help deal with the obstacles and records the progress on the sprint burndown chart.  At the end of the sprint, there should be the completed tasks, the deliverables, ready to present to the client. Once implemented, there is a reflective stage where feedback is collected and user stories are developed.  Then it’s time for the next sprint where he team along with the client is ready to select the next user stories and off they go again.

So basically, agile development is a short iterative process of sprints where there is success (deliverables) at each stage with market-driven goals.

So what could Agile development look like in the classroom?

In my Grade 12 classroom, my students are in the early stages of a rather dry case study on Big Data. We really haven’t stayed on target due to so many interruptions and the perceived blandness of the topic. We are not excited about it as yet and we really need to be. Firstly we have to make sense of the technical terminology and get our heads around the scope of the topic. For years @achurches and I have been pooling our resources by having our classes work collaboratively and have set up this year’s wikispace – an online learning space that our students work in by adding the content and discussing their learning. However, there is not set format of how to teach or explore the case study and perhaps a perfect project to develop using the Agile principles. So I decided to mix things up by introducing my students to the Agile philosophy.
To get the students tuned in, we watched the YouTube viral sensation, Building Planes in the Air –  the ultimate agile development project!

 

Then we also looked at some of the details of agile with CA marketing video here: An Introduction to Agile.

Then we appointed a scrum master – lucky Antonin – and collaboratively we decided what the deliverable(s) would be by the end of this sprint.  We decided that it would be to collectively research a set of terms as background to this year’s case study on Big Data. The goal was to have 12 definitions (2 per student), posted on our collaborative wikispace and peer-reviewed. These included terms such as Business intelligence software, Clustering/pattern analysis, Data analysis/data analytics.

We then had our scrum run by scrum master (AKA Antonin) who asked the following three questions:

What did you do (yesterday)?

What are you going to today?
What obstacles are in your way?

Each student was in a different stage of their definitions but clearly knew the parameters and the expectations. Interestingly the obstacles were limited access to the wikispace, time and some students not sure what definitions they had chosen. Yes, we were in a poor state!  Then over to our student appointed scrum manager who problem- solved with the team to overcome these issues and also documented where we were in and finally set the sprint burndown date (we have to get a move on – it’s next week!).

So how might this process positively impact the learning process?

  1. Imagine being appointed as a scrum master? That’s student empowerment as they get to run the meeting and record progress as well as trouble shoot any issues of the day.
  2. What’s even more powerful is that everyone on the team gets a turn to speak in the meeting and contribute to the overall success of each sprint.
  3. A huge project is now chunked down into smaller projects so that it’s not nearly as overwhelming – especially when a project is so open-ended.
  4. Students learn about feedback and empathy and soon realise that there was no point in proceeding with some ideas if that’s not what the client wants or market needs.
  5. As with design thinking, there is that exciting element of being in a constant rapid prototyping mode in order to garner essential feedback and effect good change.
  6. This is a truly transferable model for problem-solving and large-scale project management. Students can use this in their community service projects and beyond.
  7. As leaders in schools, we can use this to facilitate new innovations.

Next class we will start with the three questions and our scrum master will once again ensure that any new obstacles are worked out and off we go again until the sprint is over. Then we will review our work with our peers in New Zealand (@achurches) which in turn will determine our new direction and set of deliverables for the next sprint. We can keep this up until May 2015, then they will sit their exam. I’m looking forward to seeing what we will achieve.

Of course our students totally recognize this agile model – gaming companies put out pre-release versions of games with limited features which are based on the user feedback. It’s a great marketing ploy – not everyone gets a pre-beta copy to play with so it’s made exclusive: ‘Here’s your limited release version, we value your feedback and you’ll get the next version….’ Why not use your clients as your beta-testers? After all, if you are creating a product for the market, use your market to help you do that.

 

More links to explore:

The J-School Scrum: Bringing Agile Development Into the Classroom

Managed Chaos: How I use Agile and Scrum in the classroom

 

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *