One of the things that we’ve struggled with at ThoughtWorks University is giving the attendees the opportunity to run the project that we’ve been working on.

The first few weeks were the most frustrating both for the trainers and for the attendees because we spent a lot of time telling the attendees that it was their project but then didn’t display behaviour consistent with that message.

From my observations this happened because the role of the trainers was defined as 'senior team member' which meant that if a trainer saw something going wrong they’d try and fix it since that’s what they’d do in a normal team.

This was most evident initially with the Iteration Manager which started off being one of the trainers.

After realising that this meant that person solved pretty much every problem we had to change that approach and let one of the attendees take the role.

By doing this I think the group as a whole have learnt more about what it takes to drive stories across the wall, facilitate a showcase, prepare a release and so on.

More recently we’ve stepped back a bit in the other roles and although I’m still acting as the tech lead we’re allowing others to cover some of the tasks that someone in that role might usually take care of.

The main learning for me is that our initial metaphor of being a 'senior team member' rather than a 'trainer' actually hindered the learning of the group despite creating a more realistic project environment.

It’s difficult to say whether we should have gone with our current approach straight from the start or not.

Part of me thinks it may have been useful to get an idea of what a normal project would look like but the other part thinks maybe we wasted learning time.