Archive for the ‘ThoughtWorks University’ Category
I recently came across Joseph Pelrine’s blog post where he describes the way that you might go about organising a great party.
He describes a party that a friend of his hosted and all the things which contributed to it being great, such as the people you invite, the music that is played, the food and drink that are served and the conversations that are had.
If you then wanted to replicate a ‘great party’ you might think that you could just replay his friend’s party, with the same guests, same music, a script of the conversations had and so on.
Pelrine points out this sounds ridiculous and suggests retrospective coherence can help us understand why:
One thing that makes complex systems complex is their causality…in a complex system, though, the causality emerges as the system emerges. As the party goes on, the reasons for its success become established. After it’s over, you can say that a party was a success, and that these people were there, this music was played, and this much beer was downed – but you cannot say that the party was a success because these people were there, this music was played, and this much beer was downed!
…at the end, you can say how you got to where you are, but you can’t guarantee that by doing exactly the same things, you’ll get to the same place again – and you probably won’t. In complex systems, we say the causality is retrospectively coherent.
We’ve been having a similar problem in trying to understand what makes a ThoughtWorks University term run successfully and trying to summarise what we learnt for the trainers of the next term.
In our case it’s more clear that just copying what we did probably isn’t going to work because some key factors are going to be different.
To start with, the trainers for ThoughtWorks University 22 are going to be completely different from the ones for ThoughtWorks University 21 since none of the trainers are staying on.
This automatically makes a difference because the people leading the training are going to be completely different, will have different strengths, different ideas about how to teach and so on.
The number of people attending will also be significantly different – there are planned to be two groups of 25 attendees whereas in the last TWU there were only 13 attendees.
This means that doing coding dojos the way that we did probably isn’t going to work as well because the group is much bigger and there’s more chance for people to get bored.
When we were doing a trainer retrospective a couple of weeks ago we found it quite difficult to know exactly what we should be documenting for the next group.
We eventually came to the conclusion that it wouldn’t be enough just to outline what we did but that we should also explain why we did that and also include the feedback that we got from the attendees.
Jim suggested that it was probably necessary to train 2 or 3 universities before you would be able to see a common theme across them and have some idea of what seems to work each time.
The learning for me is that although it’s been much more obvious that copying an approach won’t work for ThoughtWorks University, I’d be more likely to advocate copying an approach I’d seen work before on a delivery project!
While discussing this with Frankie he pointed out that it’s still useful to start out with a set of ‘rules’ that we think will work but then be prepared to change our approach based on the feedback that we get.
Since we finished the most recent ThoughtWorks University session last week a few people have been asking me how the experience was and I’ve found myself comparing this experience to my own as an attendee in August 2006.
Back then ThoughtWorks University was much different. We had 5 weeks of workshop style sessions and then spent the last week working on an internal application.
This time we spent 1 week doing the workshop style sessions, 1 week working together on a story and then 4 weeks working on the application.
Knowing what you don’t know
My general feeling is that although TWU v2.0 is better designed for helping people to learn, an advantage of the previous approach was that there was more opportunity to see the gaps in your skill-set.
From what I remember there was much more trainer input and at times it was amazing to see how good someone could be at programming once they’d got years of practice behind them.
Although this still happened, albeit less frequently, there was often feedback that people didn’t know what they didn’t know and were therefore unsure what they needed to learn.
They will still be able learn about those gaps on the projects they work on but I didn’t feel this group had the sense of how much there still is to learn as I did 4 1/2 years ago.
The ‘trainer’ role
The role of the ThoughtWorks University trainers has changed from being an actual trainer to being more of an enablement coach whose primary goal is to facilitate people learning.
I think this makes the ‘trainer’ a more passive participant as your job is no longer to ‘teach’ people things but rather to let them learn themselves.
At times this meant sitting back to allow people to explore and learn from their mistakes and although I think this is a valuable approach it can get quite boring!
Realism vs Creating Learning Opportunities
One of the nice things about the new style is that the challenges and problems that people encountered were actually real and not contrived.
On the other hand this meant that we couldn’t specifically target things that we wanted people to learn in such a structured way.
For example, I remember doing several sessions on object design and design patterns and although we weren’t experts in either of those by the end of TWU it helped us to see some areas that we could go and read/learn more about.
I think people probably came across similar types of situations in this TWU but in their pairs rather than as a group so it was more difficult to point out the learning area.
After six weeks ThoughtWorks University #21 finished on Thursday so I thought it’d be interesting to summarise some of the things that people seemed to find difficult over the course of TWU.
The stack trace
We were using Java for the duration of TWU and as a result there were plenty of stack traces for people to debug.
These were most frequently related to incorrect wiring of Spring components but there were other reasons too.
People seemed to find these stack traces quite difficult to understand, particularly when one stack trace was nested inside another, and often just started guessing why the code wasn’t working.
I think it takes a while for that lesson to sink in but it makes life much easier once it does.
Programming by wishful thinking
One of the programming techniques which we tried to encourage is the idea of programming by wishful thinking i.e. you write the code that you wish existed and then you go and implement it.
Some of the group seemed to find this approach quite difficult to understand and preferred to go and create the class/methods of the object rather than just pretending that they existed for the time being.
I think the intuitiveness of this technique might be linked to how easy people find the TDD approach to writing code and since many hadn’t done this before that may explain why it didn’t come naturally.
I wrote a couple of months ago about some observations I’d had while pairing with people during a university recruitment event and one of them was that people struggled to find the answers to their questions on Google.
A lot of the time the most useful thing I could do for people when they asked for help was to show them how I’d search for the answer on Google.
More often than not this was enough for them to figure out the answer themselves.
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.
I’m currently reading the final chapter of William Noonan’s Discussing the Undiscussable titled ‘Helping Those Who Teach, Learn’ and a couple of the ideas that he describes seem quite applicable to what we’re doing at ThoughtWorks University.
Modelling the skills
When teaching the Mutual Learning Model Noonan suggests that the practitioner needs to be able to produce actions consistent with the model in real time situations rather than just being able to do convincing presentations on the subject.
I think this is the same with teaching/facilitating the learning of ThoughtWorks University and it seems to centre around the espoused theory and theory in action.
The espoused theory describes our theory of what we think we do in a situation whereas the theory in action describes what we actually do.
I was a bit worried about doing a presentation/session on a topic where I would present my espoused theory about a topic and then more than likely not meet that theory in practice.
Over the course of the last month or so it’s become more clear to me that it’s not a big problem to make mistakes, even when you’re supposed to be the one who knows what they’re doing, as long as you’re open about your mistakes
Noonan talks about the use of leading questions when opening a topic to the group, something which I think is quite prevalent in sessions and workshops:
There are potential downsides to the approach of using questions to get to the predetermined correct answer. If the class doesn’t answer correctly, the teacher keeps asking questions like, “No, that is not it exactly. What other things can you think of?”
The students or participants hit a point of frustration where there is finally a collective call to “just tell us the answer.”
The intention is to try and make the session interactive but I’m not convinced that it helps learning and it often seems that if someone does actually get to the ‘correct answer’ that it’s because of guessing rather than real understanding.
Frankie and I unfortunately ended up using an approach similar to this when facilitating a session on the ThoughtWorks delivery model.
We wanted the group to come up with the different components of a software delivery project rather than have us do a presentation on it which would have been immensely boring.
They got 90% of these without the need for any intervention but we did end up asking leading questions to draw out the last 10%.
Rather than doing this, Noonan suggests the following approach:
The remedy is for the leader to follow the basic rule of thumb that if you have a view, state it and balance it with inquiry to see if people agree or have different views.
In this case that would have meant that we would have kept the facilitated discussion but then helped fill in the missing components before discussing those with the group.
I’ve been acting as the tech lead on the project that we’re working on at ThoughtWorks University and as a result I sometimes find myself being dragged away from my pair to help someone else.
An interesting thing which I’ve noticed on more than one occasion is that when I’ve come back from helping – maybe 15 or 20 minutes later – my pair has actually got much further than I expected them to.
I think there are probably more than one factors that lead to this but one which I think is quite applicable is that having me there is stopping the grads from exploring the problem.
In general if I see someone moving around the editor or browser without there seeming to be any logical path I’ll start asking questions to try and ‘guide’ them to where I believe we need to go.
On other projects that I’ve worked on this has worked reasonably well because we both have a similar understanding of the problem, the tools and so on.
In this case I think that shared understanding is much less and my approach is much more harmful.
I’ve been reading John Medina’s Brain Rules over the last couple of days and Rule #12 seems to agree with what I’ve observed:
Rule #12: We are powerful and natural explorers
We are natural explorers, even if the habit sometimes stings us. The tendency is so strong, it is capable of turning us into lifelong learners.
I particularly liked the following section…
[Humans] Make a sensory observation, form a hypothesis about what is going on, design an experiment capable of testing the hypothesis, and then draw conclusions from the findings.
..which seems to describe the process that I’m sometimes restricting by asking ‘guiding’ questions.
Jim suggested that one way to get around this problem could be to split up as a pair when we’re in this explorative mode but what I’ve been trying at the moment is keeping more silent and trying to understand what discovery is going on.
I’m still getting it wrong sometimes but I’m starting to pick up more where they’re really stuck and need some help and where I should just keep quiet and allow them to work out what to do themselves.
As I mentioned in an earlier post Sumeet has been encouraging us to act more as coaches rather than trainers during ThoughtWorks University but it’s not quite as easy as it seems.
I’ve noticed that there are a few things that contribute to this difficulty.
The biggest obstacle is that by the end of TWU the trainers are required to send a review about each of the grads to the respective Resource Managers describing each person’s current level of skill in various categories.
Although we’re trying hard to be helpful when conveying this message it’s difficult for the grads to get beyond the feeling that they’re being tested which to some extent is true.
I find the idea of assessing people while I’m working with them quite difficult so for me it’s more a point of working out the best way to help each person improve their skills.
On the other hand the advantage of being in a mode where you’re explicitly looking for ways for them to improve is that you are able to give much more detailed feedback than you might be able to if you were on a ‘normal team’.
One of the things that a couple of the trainers were doing was acting as a proxy customer as well as playing their normal role.
This is an approach that has been used on previous TWU’s and the intention was to give the grads an idea of the different types of customers that they might encounter.
The feedback from the grads was that it can be quite confusing because you’re never quite sure which role the trainer is going to be playing when you go to speak to them.
As a result we’ve decided to drop this idea and let the Sukrupa guys completely play the role of customer while the trainers just play their normal role.
Drifting outside the group
A more subtle thing which can signify a difference between trainers/grads is the tendency for trainers to drift outside of group situations physically.
For example in the wrap up that we do at the end of the day if the trainers don’t participate in that then it signifies a difference between them and the grads i.e. they’re not really part of the group.
I think we’ve got better at this as time has gone on and it’s actually much more fun to take part in everything than to just be an observer.
It’s very difficult to completely get rid of the role of being a trainer but at least having an awareness of the situations where we make it more difficult for ourselves can help us get closer to achieving that.
When I attended ThoughtWorks University in August 2006 we spent quite a bit of time playing games which had been designed to help us to achieve various learning objectives.
At the time I didn’t think much about it but now being on the other side as a trainer I’ve started to doubt whether these types of sessions are as useful as I originally thought.
I recently came across a blog post Sumeet wrote last year where he talks about effective e-learning environments and I think his point still applies here:
The really effective elearning is where people actually practice real-world tasks, but we have little time for that post our fascination with card games and flashy animations.
The Agile Lego Game
I was pondering this a couple of weeks ago when we ran the agile lego game.
Interestingly the feedback that we got from the participants of this session was that they really enjoyed the games part of the sessions.
My current thinking is that the feedback may have been more indicative of the fun that people had rather than the learning gained.
The problem I see is that people do know it’s a somewhat contrived situation and may therefore have difficulty relating it to a real life problem that they face later on.
For example in the agile lego game I acted as a customer with the instructions to be very picky/particular about what I actually wanted so that the team would communicate with me more frequently.
The idea was to try and simulate a real life customer and to allow the participants to see the value of collaborating with the customer frequently.
I found this part of the role really difficult as I knew how much I would hate to be on the other side facing someone acting like that.
On the other hand we did encounter the same types of problems that can happen on real projects:
- Making assumptions about what the customer wanted
- Not speaking to the customer and just building something
- Miscalculating how long it would take to build something and spending ages doing it
- ‘Committing’ to way more points than could ever be done
Despite seeing people learn those lessons and not committing the same mistakes in the next iteration I have noticed these same mistakes happening now that people are working on a real project.
From what I’ve seen it’s not until they make these mistakes in a real environment that the learning really sinks in.
Having said that I wouldn’t completely write off the use of games in learning environments.
They certainly provide a really good way to get people to interact as a group as well as proving them a good opportunity to know each other better.
The real learning happens when you’re in a real environment though!
One of the most interesting things that I’ve been reading about recently is the idea of single and double loop learning which were defined by Chris Argyris and Donald Schon in their book ‘Organizational Learning: A theory of action perspective‘ in 1978.
I quite like the definitions that Mark Smith gives for these types of learning in his article about Chris Argyris:
Single Loop Learning
Single-loop learning seems to be present when goals, values, frameworks and, to a significant extent, strategies are taken for granted. The emphasis is on ‘techniques and making techniques more efficient’ (Usher and Bryant: 1989: 87)
Any reflection is directed toward making the strategy more effective.
Double Loop Learning
Double-loop learning, in contrast, ‘involves questioning the role of the framing and learning systems which underlie actual goals and strategies
I’ve found in a lot of ‘agile’ teams that I’ve worked on we do single loop learning pretty well but often struggle when it comes to double loop learning.
For example while working in Pune I would often hear people justify the use of an “agile practice” with the phrase “we do it because it’s agile” without necessarily reflecting on the benefit the practice was supposed to be providing.
I was therefore quite pleased to see my colleague Claire employing some double loop learning while questioning the value of the wrap up that we do at the end of each day of ThoughtWorks University.
The wrap up is a 15 minute stand up where people share what they’re learned during the day that might be useful for other people to know as well.
Claire raised the point that it doesn’t necessarily work well as a learning device because it’s quite difficult to switch so quickly from working on the project to having to reflect on what you’ve learned.
When we discussed the usefulness of the session as a group a couple of people pointed out that it works quite nicely as an end of day activity and helped create some closure on what they’d been working on.
Jim also encouraged the group to stick with it for a bit longer as his experience from the previous university was that the wrap up sessions tended to get better as people got more used to the format.
We decided to stick with it for the moment and it’s been interesting to notice that the quality of the discussion does seem to have improved as the days have gone by.
Despite that I thought it was really good that the group took the chance to reflect on whether something which had been pushed on them was actually useful rather than just going with it for 6 weeks and not getting much out of it.
I recently wrote about the coding dojo style week that we ran at ThoughtWorks University last week and I briefly mentioned that we used break out sessions to cover topics (‘the pearls’) that people didn’t totally understand.
To describe that in more detail what we did to start with was write the name of each of the 90/180 minute sessions on a card and put it on the wall under a ‘To Do’ heading:
There were about 10 of those topics and our goal was to cut each of those topics down to a 20 minute introduction that one of the trainers could give when it seemed like a good time.
For example we did a brief introduction to ‘Build and Deployment’ when we first talked about continuous integration and we went through the application architecture just before we started coding our first story.
Our goal with this approach was to encourage a pull based approach to learning over a push based one where we just presented on different topics without giving the grads a chance to properly see if they understood the topic.
The reason that we did such short presentations is that we didn’t feel you can learn that much from a presenation so we wanted to give just enough information that the grads would be able to go and explore the topic more on their own.
To push this further we asked the grads to add any other topics they wanted us to talk about to the board so that we could cover those when we got the chance.
While we were doing these introductory presentations Frankie and Jim came up with the idea of asking the grads to rate themselves 1-5 on their current understanding of the topic and to also give a time limit for the presentation.
We repeated the rating afterwards to see if the introduction had actually been useful and then spent time discussing the topic further if necessary.
This approach worked pretty well for helping avoid the brain dumping that I wrote about last week and the rating system has helped give us an idea of which topics are considered more difficult by the group.
Hopefully within the next few weeks we’ll start to see the grads running their own sessions which will take their learning even further.