Mark Needham

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.

One of the aspects of software development that I’ve thankfully seen relatively infrequently over the last few years is that of some people in teams working long hours on a consistent basis.

I have seen it happen on a few occasions and I think it can have a detrimental effect on a team rather than the good which is presumably intended.

The biggest disadvantage is that it makes other people in the team feel guilty that they aren’t working long hours and they may feel peer pressured into matching the hours of their colleagues.

In a conversation with Sumeet about work/life balance he pointed out that if you really enjoy what you do for work then you don’t necessarily see a clear distinction between the two and it wouldn’t be a big deal to work for 10+ hours a day.

While I understand this point of view I think in a team environment it’s very easy to start believing that you’re more important to a team because you put in more hours.

It’s then very easy to stop valuing the contributions of your colleagues or considering their opinions less important since they only worked a standard work day.

Someone isn’t necessarily not committed to something because they don’t spend their whole life doing it.

Another aspect to this which is easy to overlook is that the people working these long hours might not actually be working in a particularly effective way.

If I spend most of the day getting distracted/procrastinating and end up ‘working’ for 12 hours then I may actually end up being just as productive as someone who works only 8 hours but is much more focused during that time.

Even if we assume that someone is productive for 12 hours a day it still isn’t necessarily great because they’ll end up being the only one who knows the code that they write when everyone else has gone home.

When I was in Pune one of the other teams in the office had a mandated finish time of 6.30 and it actually seemed to help people remain focused during their time in the office because they knew they wouldn’t be able to work after that time.

I’m not necessarily a fan of setting rules of what people can/should be allowed to do but in that case it seemed to work reasonably well.

One of the things that Sumeet has been encouraging at ThoughtWorks University is the idea that the ‘trainers’ should be in a coaching role rather than a training one.

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

Randori

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.

Kake

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!

We ran a refactoring dojo a couple of days ago at ThoughtWorks University and in preparation I wrote some system level tests around the coding problem that we were going to use during the session.

It’s a command line application which is called through the main method of ‘Program’ and since there’s no dependency injection we need to be able to set System.in and System.out in order to do any testing.

My initial thinking was that it should be possible to fake System.in with the following code:

String input = "1\n9\n";
System.setIn(new ByteArrayInputStream(input.getBytes()));

This works fine when I just want to simulate one value being passed to System.in but it doesn’t work so well if I want to simulate passing more than one value because we had a BufferedReader being created each time we loop.

...
while(true) {
	...
	InputStreamReader inputStream = new InputStreamReader(System.in);
	BufferedReader reader = new BufferedReader(inputStream);
	...
}

This means that the second time System.in gets read it is empty.

Jim and I paired on the problem for a bit and came to the conclusion that we’d need to ‘stub’ the ‘read’ method of ‘InputStream’ if we wanted to be able to control exactly what was being returned by System.in.

We eventually ended up with the following StubbedInputStream:

class StubbedInputStream extends InputStream {
    private Queue<String> input;
 
    public StubbedInputStream(Queue<String> input) {
        this.input = input;
    }
 
    @Override
    public int read(byte[] bytes, int i, int i1) throws IOException {
        if(input.isEmpty()) {
            return -1;
        }
 
        int byteLocation = 0;
        for(byte b : input.remove().getBytes()) {
            bytes[byteLocation] = b;
            byteLocation++;
        }
        bytes[byteLocation] = "\n".getBytes()[0];
        return byteLocation + 1;
    }
 
	public static InputStreamBuilder stubInputStream() {
        return new InputStreamBuilder();
    }
	...
}

Which can be constructed using the following DSL:

System.setIn(stubInputStream().toReturn("1").then("9").atSomePoint());

The code we wrote is on github – I’m not sure that it covers every possible scenario that you might come up with but it does pass the tests that I’ve managed to come up with!

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:

1. Me always at the keyboard, people pairing with me and Frankie facilitating/controlling the whiteboard.
2. Two grads pairing and me facilitating the session
3. 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.

One of the approaches that I like the best in retrospectives is when the facilitator splits the team into smaller groups during the brainstorming part of the retrospective.

I decided to try this out in a retrospective we ran after one week of ThoughtWorks University, using The Retrospective Starfish to provide a framework in which people could frame their thoughts.

Usually what I’ve seen happen in these mini groups is that everyone will write down their own ideas on stickies and then discuss them as a group but still put up all the stickies even if the group didn’t agree with everything.

Frankie observed that in this retrospective that hadn’t really happened and the mini groups had been reaching a consensus on their ideas before one or two people went and put them up on the wall.

I think this partly came down to my failure to explain the intent of the exercise clearly i.e. it is a brainstorming exercise rather than an analytical one.

An interesting side effect was that when people came and looked at the wall to see what the other groups had come up with they noticed quite a few things that they agreed with but hadn’t come up with in their group.

I think next time I’ll try and explain the exercise a bit more clearly to help keep people in the mindset of coming up with ideas.

It’s difficult to say if any important points were missed by people analysing so early but there was certainly less duplication of ideas than normal!

I’ve mentioned confirmation bias in a few of my previous blog posts but I hadn’t realised quite how widespread it can be in organisations until quite recently.

Confirmation bias

[A] tendency for people to favor information that confirms their preconceptions or hypotheses regardless of whether the information is true.

As a result, people gather evidence and recall information from memory selectively, and interpret it in a biased way.

The biases appear in particular for emotionally significant issues and for established beliefs.

I’ve noticed that it is particularly prevalent in organisations when people feel that they are being told what to do i.e. people feel they don’t have autonomy.

Dan Pink talks about autonomy as being one of the 3 things that lead to better performance and personal satisfaction.

Autonomy

immunity from arbitrary exercise of authority

One example could be if an organisation were to force a certain way of working on their employees without getting their input on it beforehand.

It’s highly likely the employees will start looking for reasons why the new way of working is worse than what they have.

Even if the management can very logically explain why it’s better they’re unlikely to make much headway because people will only see information which confirms their view that the old way is better.

Zaynab pointed out that a useful technique to avoid confirmation bias is to look at what you were trying to achieve in old way and see how you would do that with the new way. That way you lose nothing!

I think this approach only really works once the emotions of the change have calmed down a bit though.

Equally the management may be prone to confirmation bias since they have bought into the fact that the new way is better and may dismiss potentially valid feedback because it doesn’t fit with their belief system of how things should be.

I feel like confirmation bias is quite a natural human reaction to a situation like this so it’s useful to be aware of it if you’re having something forced onto you but also if you’re in a position of instigating some sort of organisational change.