Archive for the ‘ThoughtWorks University’ Category
As a result of this suggestion one of the things we’ve done is to change the style of the second week so that it wasn’t full of sessions/workshops but instead involved working on code as a group.
Jim came up with the idea of the ‘exploded story’ whereby we spent the whole of last week as a group working on one story for Sukrupa while spending quite a bit of time exploring the different activities that playing a story end to end would involve.
We did this by making use of two types of coding dojos:
- Randori – two people at the keyboard and the rest of the group watching and contributing ideas about what could be done next.
- Kake – one computer per pair but everyone is working on the same problem
We began last week with a Randori dojo where initially two of the trainers paired while implementing a story to add improved search functionality to the sukrupa admin application.
We rotated one of the pair every 5 minutes, initially making sure that there was always a trainer at the keyboard but we quickly changed that so that it was mostly the grads driving the implementation.
The cool thing about using the randori dojo like this was that we were able to code as a group and people were able to get a rough feel for the strengths of their colleagues and see any areas they might be able to improve on.
We were also easily able to see where people were struggling so that we could break out and do a quick session on a topic if necessary.
One disadvantage of this style is that it does put people under a bit of pressure because everyone is seeing the code they’re writing so I’m not sure that it necessarily provides the best learning environment.
We did the randori dojo for a few mornings while doing a kake dojo in the afternoon before deciding as a group that it would be more beneficial to do a kake dojo for the whole day.
We initially ran the kake dojo with 10 minute iterations after which we would discuss how everyone was doing and whether there were any learnings to share.
We pair rotated every other iteration and eventually increased the iteration time to 30 minutes so that we’d have more time to solve some of the more difficult problems.
It was getting really irritating being interrupted every 10 minutes at times!
A few times a day we went around the room to each machine and the pair was able to describe the code they’d written and the approach they’d taken.
We’d then choose as a group which code we wanted to push to the github repository as a baseline and then continue working from there.
I quite enjoyed working in this style and it worked fairly well until we got towards the end of the story and the code that each pair was writing was pretty much identical.
At that stage we switched back to a 30 minute randori dojo before the week was complete!
One of the things that I’m learning while working at ThoughtWorks University is to bite my tongue a bit to allow people to learn in their own way.
I noticed this particularly yesterday in a refactoring session we were doing.
For about 10-15 minutes in the middle of the session we’d managed to get the code into a state where it didn’t compile and we couldn’t run the tests.
The ‘natural’ inclination in that situation for me would be to step in and impart some ‘wisdom’ about the importance of taking small steps while refactoring.
Instead we kept on going for another 10 minutes or so until one of the guys pointed out that the code hadn’t compiled and nor had our system test been run for quite a while.
With some prodding from Frankie the pair at the keyboard made some temporary changes to the application so that it’d compile and then completed the rest of the refactoring in a more incremental fashion.
Of course the other side of the coin is to ensure that I do actually give some input when it’s useful.
The key here seems to be to ensure only to give enough input for the situation.
I’ve learnt quite a lot about some topics and with the amount of stories I’ve picked up and the analogies/metaphors I’ve picked up it can easily become a brain dump if you’re not careful.
From my own experience this style of receiving information isn’t particularly easy to digest, especially if you don’t have any context to link the stories to.
The other danger with telling stories is that one story can often trigger another trainer to tell their own story and before you know it 30 minutes has gone by and the original point has long been lost!
I facilitated a refactoring session today at ThoughtWorks University where we spent the morning refactoring our way through one of the problems the grads had to work on as part of the pre coursework.
The previous version of this session has been more structured, whereby one of the trainers worked solo at the keyboard and took suggestions from the group about which refactoring to cover next.
There are a certain number of refactorings that the session aims to introduce and the trainer would have practiced beforehand so they could make these fairly flawlessly.
I’m not really a fan of that style of session so we refactored code which the grads were quite familiar with and I was unfamiliar with.
We ended up doing 3×45 minute stints in the style of a randori coding dojo and we had one person keeping a list of the potential refactorings on the whiteboard.
The 3 stints went like this:
- Me always at the keyboard, people pairing with me and Frankie facilitating/controlling the whiteboard.
- Two grads pairing and me facilitating the session
- Two grads pairing and one grad facilitating the session.
We’re slowly trying to encourage the idea of the grads owning the way they learn so this was a step on the way to that.
These were some of the learnings from covering a topic in this way:
- Frankie noticed that I was dominating the keyboard in round 1 so we decided that the grads could pair with each other for the remainder. We’d already gone through a lot of the main refactorings in that 1st round so it made sense to make this change.
- We switched the order of people before the 3rd round after some feedback so that people would have the opportunity to pair with different people than they had in the 2nd round.
- In the first round I was a bit too focused on teaching keyboard shortcuts to the people I was pairing with. Frankie pointed out that it’s more useful to learn the refactoring first and then once you have that concept then teach the shortcuts. By the 3rd round the grads were teaching each other the shortcuts which I thought was pretty cool.
- We didn’t get to cover as many different refactorings as we would have in a more structured session but we’ll get to those in the next few weeks when we’re coding on the project so I don’t think it’ll be too much of a problem.
- Since this was a problem everyone had worked on previously several of the people had already done some of the refactorings in their own solution. Therefore parts of the session weren’t a big learning experience for those people. That’s been a bit of a theme so far – working out how to cater for all skill/experience levels seems a difficult problem to solve!
Overall I was quite impressed with how much we managed to refactor the code in the amount of time we coded for.
The only thing I’m a bit unsure about with the randori style is that it leaves a lot of people observing for big chunks of time.
The Kake/UberDojo format is one that might be more suitable but that would mean splitting up the group which wasn’t something we’d considered.
Over the last year or so I’ve had some opportunities to pair with a few different people on sessions/presentations that we’ve been giving.
I much prefer doing this than presenting something by myself mainly because it’s much more fun and seems to encourage more participation than when I do something alone.
I feel that it’s probably easier to pair present if you both have similar opinions on the subject matter and are comfortable with a similar style of delivery.
For example Frankie and I have run a couple of sessions at ThoughtWorks University and beforehand we’ve created a rough outline of how we expect the session to play out.
Once we’ve started though both of us are quite comfortable with changing it while we’re going if that will make the session better whereas others might prefer more to the pre planned structure.
Having another person there can allow you to approach a topic in a way that is quite difficult to do alone.
He played the guy who’s predominantly in favour of OO programming but is interested in learning about functional programming while I played the guy who loves functional programming and wants to use it everywhere.
It seemed to work reasonably well.
A variation on this which Sumeet and I tried is to have one person leading the session and the other recording any questions that need to be answered later on or create a mindmap of what’s being covered in the session.
One of the dangers of pair presenting is that you can end up just having a conversation with the other person rather than talking to the audience but I think this is something that can be overcome with practice.
Preparation also becomes more difficult because you need to do at least some of it together so you both know what’s going to happen in the session.
I think that’s outweighed by the other benefits I see from pairing though.
A fishbowl conversation is a form of dialog that can be used when discussing topics within large groups.
Four to five chairs are arranged in an inner circle. This is the fishbowl. The remaining chairs are arranged outside the fishbowl. A few participants are selected to fill the fishbowl, while the rest of the group sit on the chairs outside the fishbowl. One chair is left empty
Any member of the audience can, at any time, occupy the empty chair and join the fishbowl. When this happens, an existing member of the fishbowl must voluntarily leave the fishbowl and free a chair. The discussion continues with participants frequently entering and leaving the fishbowl.
A photo from a Lisa Crispin led fishbowl
We tried a slight variation on this in that we had the people not currently in the fishbowl stand around the outside of fishbowl rather than sitting down in an attempt to encourage participation.
The overall feedback that we got from the session was that it was enjoyable to take part in although it was clear that people weren’t rotating into and out from the fishbowl as frequently as I’ve seen before.
The tone of the discussion was also relatively agreeable and there weren’t any big disagreements between people where they got really fired up in defending their view.
Sumeet pointed out afterwards that the fishbowl is often more effective in facilitating discussion around a topic which people are really passionate about and have strong opinions on.
Since we had only introduced the ThoughtWorks values about 20 minutes earlier this wouldn’t fit into that category.
Interestingly although the trainers had strong opinions on certain topics it was difficult to create a discussion because the grads mostly didn’t have examples to disagree with those points so the discussion became more theoretical/hypothetical.
I do like this format though so we’ll have to try it again with some other topics or perhaps the same one in a few weeks time to see how it works out.
I’ve spent a fair percentage of the last couple of weeks preparing sessions for ThoughtWorks University and one thing Frankie has been trying to encourage is only preparing one at a time i.e. limited work in progress
Normally I’d be completely in favour of that approach but it doesn’t seem to work at all for me with this type of work.
There seem to be a few parts to creating a session, including:
- Plan out how you want the structure of the session to be
- Write up any presentation aspects of it
The first can pretty much be stream lined so that you’re doing one of them at a time but I find the latter to be a much more creative process and I don’t do that work in a linear way at all.
I’ve noticed over the last couple of years that I prepare presentations in a very stop/start way. I really struggle to create them in one go. I’ll create a rough outline and then add to it randomly after that.
It seems to work reasonably well and I’ll come up with ideas that improve the presentation at random different times when I’m not even working on the presentation.
Presumably this is because I’m thinking about the presentation subconsciously which is one way of being creative (to a degree).
I’m curious as to whether I could get a similar effect by stimulating creativity by using time as a constraint.
Something to try out at least…
We’ve been spending our time recently preparing the sessions for the next ThoughtWorks University batch and one thing Sumeet has encouraged us to do is ensure that we have a measurable goal for each session.
In our case that means that we need to design our sessions with the intention of the grads being able to do something rather than understand something after the session.
It’s very difficult to measure whether someone understands something and from what I’ve noticed having a goal of someone understanding something can encourage you to put in more than is strictly necessary.
Sumeet pointed us to Cathy Moore’s action mapping which talks about the need to create some sort of action from the learning opportunity that we’re providing.
She also talks about the need to avoid brain dumping and I’ve noticed that I have a tendency to do this if my goal is for someone to ‘understand topic x’.
I’ve found it quite difficult to work out how much information and context we should be providing but our current thinking is that providing just enough to allow the grads to work on their project while encouraging them to seek out more information when they need it will be the most effective approach.
On a somewhat related note, after a recommendation by my colleague Jim Barritt I’ve been reading through Gerald Weinburg’s ‘Becoming a Technical Leader‘ and I quite like Weinburg’s advice around this:
When I write a book or an essay or a novel, or give a workshop, I measure my success by one simple test:
When I’m finished with them, do they care less about the subject?
If the answer if yes, I’ve failed.
I’m not sure how measurable this one is but it certainly encourages you not to make the session boring!
6 months after my first attempt to train one of the ThoughtWorks University batches was cut short I’m back in Bangalore again and spent the first few days of this week pairing with the grads.
It’s been interesting for me trying to balance how much I help and suggest ideas while still allowing them to learn at the same time.
At the moment I think I’m leaning too far towards helping and not realising until later on that my colleague hadn’t quite understood why I’d suggested what I did and therefore hadn’t learnt anything from my suggestion.
In one case we came across a similar problem later on in the day and I realised my colleague hadn’t understood exactly what I meant before.
This time I let them run with it for a bit until they came to the realisation that their approach probably wasn’t going to work.
They were then able to come to the solution that I’d been thinking about originally by themselves which I think is much more valuable than me telling them it up front.
A couple of times I’ve made the mistake of saying ‘yeh I know’ when they’ve pointed out that their approach isn’t going to work but hopefully I’m getting better at being less smug and keeping my mouth shut!
The other interesting thing about letting them run with it for a bit even when I think I know better is that there have been occasions where I was wrong and we ended up with a better solution through their exploration.
We’ve got a few weeks until the next ThoughtWorks University starts but hopefully then I’ll get even more chances to find the right balance between these two things.
One thing I noticed while pairing with some of the ThoughtWorks University guys a few weeks ago is that I had an almost overwhelming urge to show them all sorts of coding techniques that I’ve learned, probably to the point where it’d be more confusing than helpful.
You’re probably itching to get started, but where do you get started? There’s no right place. The simplest approach is to pick one thing and jump in.
For example one story I joined involved adding a new feature which touched all layers of the application from the view through the service layer and to the database.
My favoured approach is to start from the UI and work out what we actually need to develop by starting from what the user will actually see i.e. outside in development.
The approach that had been taken on the story meant that the API of one of the services was being driven out straight from a service test rather than coming for a need for that method from the controller.
The reason I prefer to drive out a story from the outside in is that we don’t have to try and imagine the way someone might want to use an object – we already know because we’ve written the consumer code for that method already.
While learning how to drive from the outside in is a useful skill, in this case the main skill that we were trying to encourage was test driven development and getting the grads used to the red – green – refactor cycle and so on.
Although it would have made our lives easier to stop and go and write the code for the controller which needed the service first, I think it would have been quite confusing to leave the service in a half completed state and move off to work on something else.
We therefore kept on working on the service code while trying to imagine exactly how it would be used by the controller.
While this wasn’t the optimal way to develop this piece of code and perhaps took longer overall I think it was a more useful approach to take in this situation and is one I’d take again given similar circumstances.
Sumeet recently blogged about the new style ThoughtWorks University that he and the other trainers have introduced and although I only got to see it in action for a few days it seemed clear to me that it was an improvement on the original version.
The questions being asked, discussions being had and situations that were coming up were pretty much the same as I’ve seen on any software project that I’ve worked on.
One particularly interesting thing which came up a few times was that there was a ‘them vs us’ feeling between the analysts and developers.
This is certainly an example of a situation which didn’t come up on the project when I participated in ThoughtWorks University 4 years ago where we only had a one week simulation.
It is however a situation that does come up and on the projects I’ve worked on it certainly can feel like you’re fighting the analysts. They’re trying to balance the wishes of the client as well as those of the developers and to developers it can often seem that the analyst is just being difficult for the sake of it.
The cool thing was that the grads then came up with different potential solutions to this problem and they were pretty much the same solutions that we’ve used on projects I’ve worked on.
While discussing a different topic with Dave Cameron he pointed me to the Wikipedia entry for ‘situated cognition‘ which “posits that knowing is inseparable from doing by arguing that all knowledge is situated in activity bound to social, cultural and physical contexts“.
The following quotes seem to explain why, in my experience at least, I learn way more effectively when working with colleagues on projects than I could ever do on an out of context training course:
Knowing emerges as individuals develop intentions through goal-directed activities within cultural contexts which may in turn have larger goals and claims of truth.
Knowing is expressed in the agent’s ability to act as an increasingly competent participant in a community of practice.
Learning must involve more than the transmission of knowledge but must instead encourage the expression of effectivities and the development of attention and intention that reflect real life learning processes
I think this new style TWU gives grads an even better start to their ThoughtWorks lives and I hope to take part as a trainer for one of the terms later in the year.