How to teach agile to students in a school context

« I’m suppose to teach students available 4 hours a week. Does that mean we’re stuck ? ». Caroline Damour and I looked at each other. Our 1 time workshop has started by explaining to these uni teacher and her students that agile team dynamic requires co-location, high collaboration, week-long iterations of work, and people devoted full time.

This workshop was really going off track. Time to break the agenda.
We had joined IUT Agile 2013 conference for a classic workshop animation, to find an attendance of teachers and first year students (IUT is a kind of university in France). Most of them were beginners on software development, with no practical or even theoretical experience of software project management.
This was totally unexpected. We already twisted the workshop agenda to make it a training, but now that they get the point, this uncommon attendance was raising challenging questions.

Teachers and students decided to dig into the valuable problem of training students in a collective discussion. I’d like to share the output for other teacher to use it, so we may see in a few years a bunch of out-of-school developers already experienced in agile.

Here’s what came out.

Problem : how to create a regular and cyclic work context ?

Student programmers use to work on their project on nights and week-ends, not mentioning all-nighters, showing up on class for report on their progress. The idea here would be to have them work together, same time, same day of the week, same physical environment, same team. Then and only then can they experience the repetitive experience where continuous improvement can thrive. Defining rituals, organising processes, tuning them over time, building trust, learning collective decision making, etc.
To get to that, a few rules has to be set

No work outside work hours

otherwise the rule can’t stand. Of course, the project can’t be the point of an ambitious crazy hackers future-startup project. Nope, it’s a small project with a regular progression made for learning.

Short retrospectives

Given the short time slice, only a minimalist agenda can fit. I would say collecting good things/bad things/mysteries/ideas/kudos during an open discussion is enough. The facilitator could turn each time to shake a bit the learning experience.

Small teams : no more than 4 people

If we want to promote discussions in circles within a small time frame, only a small team can fit. Also, the bigger the team the exponentially longer time it takes to trust each other, listen, and take collective decisions while using every intelligence and personalities.
More on this later, from my personal observation of Dungeon&Dragons player teams over the years.

Now, pushing further :

Problem : how to simulate day-to-day work ?

30 minutes days

Divided on 25-minutes day + 5 minutes stand up meeting
That’s a tempo we use in agile simulation during training, and it works well. (25 minutes : please refer to the Pomodoro productivity technique for further details on this time slice)
The stand up meeting is a daily collective assessment on achievements and problems among the team. With these 5 minutes, your students will learn what a good agile developer masters

  • stating his own progress in clear words
  • asking for help
  • taking an overlook on a task that shift and rethinking his solving strategy

So, for now, a basic course session looks like
14H00 : beginning of the iteration. Review process, past decisions, features that are on development, and the ones coming
14H25 : stand up meeting
14H30 : day 2

17H10 : demonstration. Show what’s finished, update progress accounting
17H30 : retrospective. Write down decisions, update processes if needed. Iteration finished

But another detail showed up.
« Well, you see, I already gave the students a big project that have been splitter among teams ». Ok, so they’re making multi-team agile. They’re scaling up. Now we’re going hardcore.

Problem : How to train multiple teams to effective agile collaboration

Split the story map among the team

The story map is an eagle view of all features mapped on a wall. Cut that into meaningful sets and each team is in charge of one set.

Use one dedicated room, full of information, for all the teams to work in

As day-to-day school life may be too distracting for students, a highly enforcing context environment is required : one room, dedicated to the project, were every informations are shown on the walls. The story maps, architecture drawings, progress reports, decisions, processes, everything. Being in that room is like being in the project mind.
Have them work there.
This is called an Obeya Room.

If too many team, save extra scheduled time for inter-team rituals

The usual multi-team stuff should work :

  • 1 inter-team standup meeting (aka Scrum of Scrum) per iteration, to which each team send one ambassador
  • 1 product owner meeting per iteration to synchronize each team agenda of upcoming functionalities if dependencies exists
  • Let ad-hoc gathering happen for any kind of inter-team problem solving or coordination or decision

If you have many teams, say more than 5, these extra rituals like Scrum of Scrum may not fit into an already filled half-day schedule. You may need to save extra-time for the students. Bring food, this will help gather them.

As you see, many of these may not be limited to students project, but to any part-time project. I tried it on non-profit organization and it worked well (didn’t try the multi-team stuff, however). And by the way, I think you should forget Scrum. On small time-scale iterations it fits poorly, too heavy rituals, too much planning. Go Kanban oriented development (aka Lean Software) and split the work to itsy-bitsy user stories, as to develop 10 of them per iteration at least.

Well, that’s all, folks.

If anyone tries that, I would love to hear from it.

One Response

Leave a Reply

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

seventeen + 7 =