I tutor a fairly new Agile Project Management unit at the Queensland University of Technology (QUT), headed by a friend of mine, Chris Fortuin. INB123 ran for the first time last semester (Semester 2, 2014) for under-graduates, and it went fairly well. The students enjoyed the course overall, even though we might have made the final exam a little harder than we should have. In our defence, we also gave 40% of the grade from participating in workshops/tutorials, so I think it evened out okay.

The course material is primarily based on an Agile Project Management framework called DSDM Atern (also referred to as the Agile PM framework), with a smattering of Scrum and some other concepts.

In order to be allowed to tutor, I had to get an Agile PM Foundation certification, which involved studying a handbook and then answering a bunch of multiple choice questions online in a controlled environment. It was a fairly hard test, but I passed.

This semester we are running a similar Agile Project Management unit at QUT again, except for post-graduates, so we need to raise the bar somewhat.

In order to be allowed to tutor the post-graduate unit, I need to get another certification, the Practitioner one. Luckily this is an extension of the Foundation level, and I just have to complete another exam (multiple choice still). I assume it will focus more on application of the framework instead of just raw fact regurgitation.

I’ll post about how I actually go afterwards.

Unit of Work

Apart from the tiniest possible amount of private tutoring back in Uni, I’ve never really taught anyone anything in an official capacity before. Being that I was only a tutor, you can probably say that I still haven’t taught anyone anything, but that would be mean.

As part of the tutoring, we tried to teach by doing rather than just lecturing. showing the students Agile practices and principles used in a real situation. We tutored in pairs, students worked in groups, we did incremental assignments and ran our workshops like mini-scrums.

Pair tutoring was one of the things that the students liked the most. Obviously we stole the idea from pair programming and we got a lot of the same benefits, which was nice. It allowed the students to get the attention they needed (clarifying topics, asking questions, etc), while also allowing the workshop to continue running. It worked in our favour as tutors as well, as whenever one tutor got tired or ran out of things to say, the other was there to supplement. We’re doing pair tutoring again this semester.

Our attempt at doing an incremental assignment was a mixed bag. The university wouldn’t really let us mark incrementally, so we still required the students to submit once (at the end), which was disappointing, because that’s not really how it works in reality. Still, we encouraged the students to deliver something to us each week, both so that we could make sure that they were making progress and to allow them to get feedback to improve their final result. Not a lot of the students embraced the concept, which was a shame, but they were under-graduates, and I remember what that was like, so I can’t really hold it against them. I think if we had of been able to mark incrementally we would have seen some interesting side effects, like groups meeting their minimum viable product (i.e. marks) and then leaving their assignment there, while others would have chased that perfect mark. Ah well, maybe next time.

Mini-scrum workshops went really well. Each workshop started with a standup, we had a backlog of items in priority order and they all ended with a retrospective, where the students could give feedback, which in turn would make our next workshop better. Standard Scrum stuff. I particularly liked this approach, as it gave the students some exposure to what it was like being inside a working Scrum process, rather than what the process is supposed to be.

All told I greatly enjoyed tutoring the unit for the first time, and I’m eager to do it again. We’ve got some hard earned experience and some new ideas, and I’m eager to see how everything turns out this time.

Expect another post at some point in the future about how this upcoming semester goes.

Birds

I mentioned the DSDM Atern framework earlier, so I suppose I should talk about it for a few moments.

Its a strange framework.

It’s popular in Europe (apparently) but I had never heard of it before mid 2014, being far more familiar with the other frameworks like Scrum. That doesn’t really mean anything, as I’m certainly no Agile expert.

DSDM Atern attempts to bring some Agile into the process heavy project space, or maybe it attempts to being some heavy process into an Agile space? I’m not really sure. It feels like it fits in the intersection of those two worlds though, which I assume is it goal.

I have conflicting emotions about it, as it definitely has some great ideas, but it is also very prescriptive. While it is very careful to say that you should measure delivery of useful things over raw output, it does place a large amount of emphasis on what it calls “products”, but what most people would interpret as “documents”.

To be honest, I would view it as a transitory step, one you use in order to migrate a crazy waterfall organisation slowly towards Agile nirvana. Agile is really just a matter of trust, so I can see using DSDM Atern as a way of building trust by focusing on delivery. When you have accumulated some trust, you don’t need a heavy process, just a general goal and people who get out of your way.

Still, the unit was for Agile Project Management, and the framework is quite literally Agile PM so there’s a nice piece of alignment there.

Conclusion

At some point in the future I will likely revisit this topic, and talk more about tutoring at QUT. We’ve got some great new ideas for this upcoming semester, including some shamelessly stolen from EduScrum (flipbooks! student engagement!) and a different way to present assessment (as a backlog, value decided by us, prioritization decided by the students), and I’m very interested to see how they work in practice.

Its good to see that QUT is incorporating more Agile into their curriculum. Teaching new entrants to the workforce how Agile works and why is only going to improve the software development community as a whole, helping us to move away the traditional, heavily controlled processes into something much more enjoyable and effective.

One of the most common ways to communicate the principles of the various Agile software development methodologies is games. I like to think that this is because the Agile software development methodologies are more like games than the others, focused more on the team, the overall goal and responding to change, rather than following some meticulously planned process that “guarantees” success. Jeff Patton presented a nice talk that incorporated those elements at his Yow! 2013 talk (which is well worth watching).

I’m sure there are a lot of games that people use to teach the principles of Agile development methodologies, I’m aware of (and have run) two, Scrum City and the Lean Manufacturing Game (which might actually be called the Lego Lean Production Game). I ran both of these games in the workshops for the new Agile Project Management course at QUT (Semester 2 2014, INB123, replacing the Prince 2 Project Management course), and they proved to be quite effective in communicating critically important elements of Agile to the students. It helped that they were also fun and very physical, which helps engagement.

A fellow tutor for the Agile Project Management course (Andrew McIntyre, the great and powerful) came up with the idea for another game, teaching elements of Scrum using Sudoku puzzles. The other tutors and I helped him flesh it out a bit, and we then used our poor students as test subjects to see how it worked out in reality.

It was awesome! Also hilarious.

And thus Scrumdoku! (don’t forget the exclamation point) was born. At a high level, the game is focused around teaching planning and the optimisation thereof, where teams have to maximise the value of delivered Sudoku puzzles over some number of iterations.

Materials

50+ individual Sudoku puzzles.

Standard 9x9 is easiest. I found the generator available at http://www.opensky.ca/~jdhildeb/software/sudokugen/ to be perfect for this. You’ll want about 60% Easy, 20% Medium, 15% Hard and 5% Very Hard. I needed 4 copies of each puzzle, as my workshop had 4 teams of approx. 8 people each. Make sure you get solutions.

Pens/pencils, depending on how confident the teams are. One for each person.

Erasers (highly recommended). Again, one for each person.

Willing Participants (obviously).

Rules

3 Iterations. I used 7 minutes planning/retrospective, 20 minutes work. Make sure you timebox aggressively.

Make sure you leave enough time to actually complete a Sudoku puzzle. 20 minutes felt a little long, so maybe try 15? Experiment and see what feels best for you.

During planning each team will commit to some set of puzzles, of their choosing.

Completed and correct puzzles are worth an amount of points relative to difficulty.

The generator I linked has Easy, Medium, Hard, Very Hard. I used 2, 5, 8 and 13 for value.

Incomplete or incorrect puzzles are worth nothing, and are lost forever.

Participants may choose to mark a puzzle as “Must Have”, in which case it will be worth double points if completed. However, if not completed or incorrect it will be worth double negativepoints.

No electronic solvers.

There’s some amazing Sudoku solvers available on phones/tablets now. Just snap a picture and the solver will tell you what numbers go where. Speaking of Sudoku solvers, Peter Norvig has a fantastic article on writing a Sudoku solver. Go read it, its great.

Optional Rules

These rules can add a hilarious…I mean “educational” element of stress to the game. Use as you see fit.

• Incorrect puzzles previously delivered can be reintroduced later as “bugs”, which must be fixed before any other work, and are worth nothing.
• Reserve some of the puzzles for “expedite” challenges. During the middle of an iteration throw one of these puzzles at the team, and tell them that it must be completed before the end of the iteration or their score for the iteration will be zero.
  • This can have some interesting side effects, as if the team has over-committed with a large number of “Must Haves” they can choose to intentionally fail the expedite challenge and zero out their scope, saving them from a large negative score. One of my teams actually did this, and I totally didn’t see it coming.
    
    

Instructions

Make sure to setup one area for each team involved in the game. Separate the planning area from the working area, like in the following (terrible) diagram.

Note that where I have said “puzzles”, that’s the planning area.

Start by introducing the teams to the rules (not the optional rules though, they shouldn’t see them coming, for maximum effect). Give them maybe 5 minutes to discuss and ask you questions. Don’t spell everything out, let them be responsible for getting to the detail by encouraging good questions.

At that point, show a nice visible timer (http://www.online-stopwatch.com/ isn’t bad) with 7 minutes on it, and tell them their planning time has started. No puzzles can be started until the planning time has finished. Note down what each team has committed to, and which puzzles (if any) are marked as “Must Have”. I found it most helpful to mark the puzzles themselves, much easier to keep track of later when marking, but make sure you also note down their commitments in some public place, like a whiteboard. I used a simple table on a white board, and a simple notation of:

[Puzzle Number] [Difficulty] [Optional: Must Have] [Correct]

27 M ! [Tick] would indicate that puzzle 27, which was a Medium, was marked as a Must Have and was correct.

Once planning has completed, start the timer for execution (20 minutes is pretty good) and let them get started.

Once that timer expires, collect all of the puzzles (regardless of state) and start the timer for 7 minutes for planning and retrospective. While the teams are planning, mark the puzzles, and note down the cumulative score for each team in some publically visible place. The quicker you do this, the quicker the teams can have feedback on how they are doing. Ideally, it should be before their planning finishes, although even without marking the teams will have some idea about how they went.

Planning/retrospective time up, iteration time start.

Rinse and repeat until done.

Have a prize for the team with the best score. Its always a fun note to end the activity on.

Observations

As with everything in life, people are bad at estimating, even when the estimating is implicit. Teams will almost certainly massively over-commit in their first iteration and then commit to a more reasonable amount in the second, quickly establishing what they are able to accomplish in the time provided. The interesting point here is that Sudoku puzzles are basically the same, even though they vary in difficulty. After the first 2 iterations, the teams will probably still not be all that great at estimating, but they will improve. Software, unfortunately, rarely conforms to the same sort of pattern as the Sudoku puzzles, which means that you may never see software development teams be able to make accurate estimates. I’ve been trying to estimate software for years now, and while I’m definitely better than I used to be, the most important element to delivering on time, is to have flexibility in what you deliver, not in getting the estimates perfectly accurate.

Other observations:

• You may see a participant assume a command and control role, deciding what will be done and assigning out work in the first iteration, which may or may not work.
• Some teams will establish themselves a mini-backlog and work through that in priority order (those teams are awesome).
• People may try to cheat, by saving partially completed puzzles in one iteration so they can continue to work on them in the next (that’s why you note down the committed puzzles publically).

Summary

Like most of the various Agile training games, the game allows for two main outcomes.

One, it teaches Agile principles to the participants (which you should reinforce at the end with a summary). The participants don’t even need to know the principles beforehand, the activity itself can be a great way to introduce them.

Two, it allows you to watch participant behaviour. Watching the way people react to situations can tell you a lot about them, which you can then leverage later on. If you play this game after introducing Agile concepts, you will easily be able to see those who took them to heart (in comparison to the people who just fall back to their old ways).

Also its fun to watch people squirm.