Mark Needham

Thoughts on Software Development

Archive for the ‘Communication’ Category

Communication when it’s not going your way

with one comment

I’ve been reading some of the articles written about the disruption caused by the snow across Europe and I found one quote in The Daily Telegraph by Phillip Hammond particularly interesting

“I think whilst people are obviously deeply upset about the inconvenience, particularly at this time of year, of having their travel plans disrupted, most of what I am hearing is a sense of outrage about the way they were then treated when they were stranded at Heathrow airport.

I was stuck in Brussels Airport for almost a day and the communication by just about everybody there was as non existent as it sounds like it’s been at Heathrow.

I think part of the reason for that was that the people in charge didn’t know what was happening and part of it was because they didn’t want to give people bad news.

I’ve noticed the same type of thing happen in organisations when there there’s something bad to be communicated or an unpopular decision has been made and needs to be explained.

Often in this situation there will be no further communication because it’s assumed that people won’t react well to that communication.

I don’t think that’s actually an accurate assumption and in addition not communicating is actually quite a dangerous thing to do because it then puts people in the position that they will now guess why certain things are being done.

More often than not those guesses will be more damning of people in leadership positions than they deserve.

Whenever I’ve seen someone in a leadership position explain what’s actually going on (and the thinking behind it) the response of the people receiving the message has always been much more reasonable than they expect it to be.

I think the people in charge of communicating what was going on in the airports would have had similar results if they’d only communicated something!

Written by Mark Needham

December 22nd, 2010 at 11:32 pm

Team Communication: Learning models

with one comment

One of the problems I’ve noticed in several of the ‘agile’ communication mechanisms (such as the standup or dev huddle) that we typically use on teams is that they focus almost entirely on verbal communication which only covers one of our learning styles – the auditory learning style.

The Learning Models

The VAK learning style model describes a simple model covering the different learning styles that people have:

  • Visual – seeing and reading.
    • Involves the use of seen or observed things, including pictures, diagrams, demonstrations.
  • Auditory – listening and speaking.
    • Involves the transfer of information through listening: to the spoken word, of self or others.
  • Kinesthetic – touching and doing.
    • Involves physical experience – touching, feeling, holding, doing, practical hands-on experiences.

My own learning style is predominantly visual so I tend to find that a well drawn diagram will help me understand something far more quickly than a colleague spending 10 minutes explaining something using only words.

If the latter happens then I either find myself totally zoning out or mentally trying to sketch out what the speaker is saying.

In a team environment this would translate into ensuring that we use the whiteboard when trying to explain problems.

Sometimes just going to the whiteboard isn’t enough and we need to cater to the kinesthetic learning model which in software development terms would involve walking through the code.

I’ve never been involved in a team session where we went through a part of the code base together but I’ve heard from colleagues that it can be very helpful in some situations.

I think it’s important that we know what our favoured learning style is so that we can guide any discussion in such a way that it plays to our strengths.

In terms of software development

Although people tend to have different learning models my general observation is that we can move through the models from auditory to visual and finally kinesthetic depending on the complexity of what’s being explained.

I think it also partly depends on the experience of team members. For example, I’m now able to understand many more discussions which are purely verbal where previously I’d have needed a diagram or someone to show me what they meant in the code.

I think it’s important to look at the implicit feedback we’re getting from colleagues when explaining something to see whether or not the model we’ve used has been effective.

If it hasn’t then at least we know we have some other approaches to try which might be more successful.

Written by Mark Needham

November 27th, 2010 at 10:50 am

Meetings: Guerilla Collaboration

with 3 comments

As I’ve mentioned on twitter a few times my current team has a lot of meetings and apart from using the passive aggressive approach that Toby Tripp’s meeting ticker provides I’ve also been flicking through Chapter 19, ‘Guerilla Collaboration’, of Jean Tabaka’s ‘Collaboration Explained: Facilitation skills for software project leaders‘ which gives other ideas.

I’ve also seen some useful ideas that my colleagues have used in meetings that I’ve been part of.

Agenda/Purpose of the meeting

Jean suggests that we ask the meeting organiser for an agenda in order to ensure that:

  • We aren’t wasting the time of some participants
  • We aren’t missing any important attendees
  • The meeting has a focus and people aren’t at a loss for what to do

I’ve noticed the 1st and 3rd of these happening more frequently and it’s typically because the topic of the meeting is very generic which means that anything goes!

Time Check

Calling for a time check is useful for helping ensure that the time in the meeting is being used effectively and that the meeting doesn’t over run the allocated time.

Having a start and end time for the meeting is also useful because otherwise a meeting can drift on for hours without any conclusion.

Creating a constraint – of time in this case – helps to keep things a bit more focused and in theory could lead to move creativity.

Keeping the discussion on track

This is typically easier for the meeting facilitator to do but it’s certainly possible for an attendee to ask whether a certain discussion is relevant or if it can be taken offline.

I find that discussions can often drift into implementation detail i.e. the wrong logging level and totally isolate the majority of the meeting’s participants.

It’s certainly important to be careful when doing this because you might be wrong about what ‘on track’ means and people can quickly stop contributing if you consistently shut them down.

Parking lot

This would typically just be a section of the whiteboard used to ‘park’ discussions about topics which we can get to later but aren’t part of the purpose of the meeting.

I haven’t seen this used that often but it seems like a useful technique because it still acknowledges that someone has a valid point, just that it’s not for discussion at the moment.

Written by Mark Needham

October 31st, 2010 at 2:53 pm

Posted in Communication

Tagged with

Communication: Logging levels

without comments

I think one of the most important skills to perfect when communicating with other people is to understand the level of detail that we need to be speaking at, something my colleague Ashwin Raghav refers to as our logging level.

We log various things in our code at varying logging levels ranging from ‘error’ through ‘debug’ to ‘warn’, and each of these is useful for understanding what our code is doing.

However, we might typically only report problems at the ‘error’ level unless something goes wrong and we want to try and understand in greater details what’s going on.

The same thing applies at a conversational level and I’ve noticed that the tendency is to zoom into the detail very quickly rather than staying at a high level.

In a group situation

While speaking at a detailed level is appropriate in some situations it can easily isolate people in a group situation if only one or two people are able to take part in the conversation at this logging level.

Given that it is possible to end up at the wrong logging level by mistake it then becomes important to watch the body language and reaction of other people in the group.

If they seem to be zoning out, losing interest or if the conversation excludes them then it’s fairly likely the logging level is too verbose and it would make more sense to take that conversation offline.

In a one on one situation

A similar thing applies in a one on one conversation but the way it rears its head is slightly different

When talking about code the tendency can be to talk at the syntax level in order to explain something.

For example if we’re talking about the merits of mocking or stubbing out methods on the system under test then the conversation has been set at a conceptual level and it wouldn’t make sense to start talking about the way that RSpec actually makes it possible to do this.

It’s also useful to work out the other person’s level of understanding so that we know what logging level our explanations need to be at.

We’ll typically get rapid feedback from the other person if we’re not doing this.

For example when I first started working with Ashwin my explanations were too detailed and he quickly pointed that out. That allowed me to jump straight to a higher level from then on.

The logging level that we’ll need to use will be different for each person and it does take a little bit of time to work out where exactly it needs to be.

I quite like Ashwin’s metaphor and I’ve been keeping it in mind when watching conversations and when communicating myself to try and ensure that the right logging level is being kept to for various conversations.

It is surprisingly easy to drift away from the optimal logging level though!


As a side note it seems much less frequent that the people I work with speak at a level of detail which isn’t verbose enough and I can’t really explain why that is!

Written by Mark Needham

October 25th, 2010 at 6:49 pm

Posted in Communication

Tagged with

Builders hanging off class vs Builders in same namespace

with 4 comments

I wrote a couple of months ago about an approach we’re using to help people find test data builders in our code base by hanging those builders off a class called ‘GetBuilderFor’ and I think it’s worked reasonably well.

However, a couple of weeks ago my colleague Lu Ning suggested another way to achieve our goal of allowing people to find the builders easily.

The approach he suggested is to put all of the builders in the same namespace, for example ‘Builders’, so that if someone wants to find out if a builder already exists they can just type ‘Builders.’ into the editor and then it will come up with a list of all the builders that exist.

The benefit of this approach is that it means we can make use of the object initializer to setup test data – perhaps one of the few occasions when it seems to be reasonably useful.

Lu Ning explains in more detail on his blog but the idea is that instead of:

new FooBuilder().Bar("hello").Build();

We could do this:

new FooBuilder { Bar = "hello" }.Build();

The second approach requires less code since we can just create all public fields and setup a default value for each of them in the class definition and then override the values later if we want to as shown above.

We can’t do this with the ‘GetBuilderFor’ approach since you can only make use of object initializer when you are initialising an object (as the name might suggest!).

Another advantage of this approach is that we don’t have to write the boiler plate code to add each builder onto the ‘GetBuilderFor’ class so that others can find it.

The disadvantage is that once we type ‘Builders.’ to find the list of builders we then need to delete that text and type in ‘new FooBuilder()…’ which means the flow of creating test data isn’t as smooth as with the ‘GetBuilderFor’ approach.

I don’t feel like there is a really big difference between these approaches and as long as people can find code that’s the main thing.

There would probably be less typing required with the namespace approach although I’ve never really felt that typing is the bottleneck in software development projects so it would be interesting to see if this would give us a gain or not.

We are still using the ‘GetBuilderFor’ approach on our project since there probably wouldn’t be a massive gain by switching to the other approach at this stage.

It does seem like an interesting alternative to solving the same problem though.

Written by Mark Needham

August 15th, 2009 at 10:53 am

Posted in Coding,Communication

Tagged with ,

Coding: Putting code where people can find it

with 10 comments

I’ve previously written about the builder pattern which I think is a very useful pattern for helping to setup data.

It allows us to setup custom data when we care about a specific piece of data in a test or just use default values if we’re not bothered about a piece of data but need it to be present for our test to execute successfully.

One problem that I noticed was that despite the fact we had builders for quite a number of the classes we were using in our tests, when new tests were being added test data was still being setup by directly using the classes instead of making use of the builders which had already done the hard work for you.

A colleague and I were pairing last week and I pointed out one of these areas and he suggested that we should try and introduce the builder pattern to try and solve it!

We actually didn’t have a builder for that particular piece of data yet but I pointed out several other builders we did have which he wasn’t aware actually existed.

Clearly I hadn’t done a very good job of communicating the existence of the builders but when discussing this we realised that the turn around time for checking whether or not a builder existed was actually not very quick at all.

  • Start writing test and realise that test data setup was a bit complicated
  • At best search for ‘ClassNameBuilder’ if you knew that was the naming convention for these builders
  • Create test data for the test by typing ‘new ClassNameBuilder()…’

We therefore came up with the idea of anchoring the builders to a common class which we called ‘GetBuilderFor’.

It is now possible to create test data by writing code like this:

var car = GetBuilderFor.Car().Year("2009").Make("Audi").Build();

The nice thing about this is that we now only have to type in ‘GetBuilderFor’ and then a ‘.’ and ReSharper will show us all the builders that are available to us. If there isn’t one then we can create it.

Communication wise we’ve both been mentioning this approach in our stand ups and to other people when we pair with them and hopefully this approach will stop the duplication of test data creation.

For those in the Java world Jay Fields wrote a cool post a few months ago where he describes a way to do a similar thing in Java. I think this is one place where having static imports makes the code read really fluently.

Written by Mark Needham

June 2nd, 2009 at 11:35 pm

Posted in Coding,Communication

Tagged with ,

Adding humour to Tester/Developer collaboration

without comments

Pat Kua has a recent post where he talks about the language used between testers and developers when talking about defects that testers come across when testing some functionality and while I would agree with him that the language used is important, I’ve always found that injecting some humour into the situation takes the edge off.

As Dahlia points out I think this is probably only possible if there is good rapport between the developers and testers on the team so perhaps this has been the case for the teams I’ve worked on.

I would find it quite disappointing if my first attempt at a story cleared all the way through to business sign off without a tester in the team at least coming up with some cases where it doesn’t work properly – I try to think of the scenarios that someone with a testing hat on would come up with but they are way better at that role than I am so there’s bound to be something that I’ve missed.

Now this doesn’t mean that I should keep recreating the same types of defects/bugs over and over again – that would be the waste of re-learning and doesn’t add a whole lot of value.

In all the teams I’ve worked on there has definitely been a bit of banter between the testers and the developers whereby the testers tell us off ‘tongue in cheek’ for putting so many bugs into the code and we respond by asking them not to keep on breaking the application.

I’ve always felt that this approach worked reasonably well although it should probably be pointed out that I only do that with my ThoughtWorks colleagues where we pretty much have an implicit understanding that we are not criticising each other when talking in such a (supposedly) blunt manner.

If there’s any underlying lesson from this approach then I would suggest it’s that developers would be better of assuming that a tester is probably going to find a bug in their code and that they shouldn’t assume something is finished just because it is development complete.

Testers on the other hand maybe can be less confrontational (as Pat suggests) when they find bugs – the developers didn’t put them in there deliberately! You guys just happen to be way better at using the application in a way that finds its’ flaws than we are.

Keeping it light hearted is also way more fun!

Written by Mark Needham

May 4th, 2009 at 11:43 pm

Team Productivity vs Individual Productivity

with 4 comments

I’ve been reading Neal Ford’s The Productive Programmer (my review) which is a book all about improving your productivity as an individual developer.

It got me thinking that there are also ways that we can make teams more productive so that they are actually teams and not just a group of individuals who happen to work with each other.

I’ve had the opportunity of working under some great Tech Leads who have helped create an environment where teams can perform to their maximum. I’ve noticed some recurring themes in both those teams.

In his book Neal talks about getting into a state called ‘Flow‘ when programming. This is a state where you are totally focused on what you’re working on and are able to be extremely productive.

When looking at Team Productivity one of the key factors behind how well the team performs is how well the team communicates. There are several ways that we can ensure that this is done effectively.

Team Proximity

It seems obvious but teams operate optimally when they are all working in the same physical space. Whether this be having an area of the office just for the team or using a conference room, communication is at its best when it’s easy to do.

In particular if the desk layout is such that it is easy for people to pair with each other on a problem or ask questions without having to move very far then we have a good setup.

Team Size

We need to keep the size of the team appropriate to the size of the work and the time in which it needs to be completed.

The smaller the team and therefore the smaller the number of lines of communication the more effective a team can be. Of course we need to ensure that we have enough people on the team to complete the work required.

At an extreme we learn from Brook’s Law that adding people to a team probably won’t make it go faster. This is also true when working out the initial size of the team – if the team is too big then the number of lines of communication becomes increasingly big and effective communication becomes difficult.

Safe Environment

Even if you have the other two it won’t matter unless a safe environment can be generated for people in the team to interact.

This means that people can feel free to ask questions to others in the team without being made to feel inferior.

People not communicating properly with each other is one of the biggest reason time is wasted on projects – reinventing solutions to problems that another team member has solved is a complete waste of time.

To given an example – on one project i wanted to work out how to unit test a Windows web service that we had written. I searched Google a bit but couldn’t work it out. Luckily I was able to ask one of my more senior colleagues how to do it and he pointed me towards the Gateway pattern which allowed me to solve the problem straight away.

He didn’t make me feel like I was stupid for not knowing how to solve the problem, but explained some options for how he would solve it and pointed me towards a book where I could read more about the solution.

How do we get the balance?

Individual productivity is defined as reaching the state of Flow in The Productive Programmer. In this state by definition you are working alone and not communicating with other team members. Team productivity on the other hand requires constant communication to make it work.

My colleague Jon Pither describes some of the issues he has noticed with pair programming with regards to this.

Psychologists refer to zone as ‘flow’. Daniel Coleman – author of Emotional Intelligence – describes flow as being “emotional intelligence at its best… the ultimate in harnessing the emotions in the service of performance and learning”.

Pair programming is a not stress free activity…Being in a “pair” you are constantly required to explain your intricate thought processes to another person.

We need to appreciate that developers are humans, and sadly are not perfect coding punching-out machines. Pair-programming introduces an emotional burden on the developer.

While I agree with Jon that pair programming is a completely different proposition to working alone, I’m not as qualified as him to comment as I’ve spent most of my professional life pair programming.

Certainly within an agile team there will be tasks which can be done individually and maybe these are the times individuals can use to achieve the fulfillment that being in a state of flow provides.

In terms of pure productivity I wonder whether there is such a thing as Pair Flow or Team Flow which would describe the state where a pair or team is working in an optimal state.

There needs to be a balance between a pair actually getting things done but also providing help to other pairs when the need arises.

I have noticed that one way this works fairly successfully is that if another pair needs help then only one person in the pair goes to help while the other can continue working. Although you lose the benefit of having both people at the keyboard since it’s only for a short period of time I think it’s acceptable.

For me personally I find it more enjoyable to work with others all the time even though I may not get into the state of flow although I appreciate that others may have different opinions on this matter.

Written by Mark Needham

September 16th, 2008 at 4:41 pm

Posted in Communication

Tagged with , ,

The Wisdom of Crowds and groupthink in Agile Software Development

with 4 comments

Gojko Adzic posted a summary of a talk James Surowiecki gave at Agile 2008 and it got me thinking how we use the Wisdom of Crowds in Agile projects.

One of the most interesting things I learnt from the book is that when you bring together a diverse group of people, their output will probably be better than any one expert. Gojko points out this example that was used at Agile 2008:

The organisers of Agile 2008 conducted a similar experiment, asking conference attendees to estimate the number of lines of code in Visual Studio. The average value of all guesses was 47 million and the actual number is 43.3 million of code. The interesting thing as well is that only two people guessed better than the group average.

There are a couple of areas of agile where I have seen how The Wisdom of Crowds can become groupthink if we’re not careful:

Agile Estimation Sessions

Agile estimation sessions are where the estimates for how long pieces of work will take are calculated.

The way these are typically conducted is the Business Analyst will explain the story to the team of Developers who will then all independently come up with their estimate of how long they think it will take to implement the story. They then ‘throw down’ their estimate in a rock-paper-scissors style approach.

The idea is then to take the most popular score suggested. If there is a difference in estimates then a discussion will ensue. It is often the case that the understanding of what is required to complete a story is different or different assumptions have been made as to the difficulty.

The value of having a group of people having input into a decision is most obvious when they are coming from different points of view i.e. they have diverse points of view.

Therefore the input of a new team member in these estimation sessions should in fact be vital for coming up with a better estimate. Often I see new members of teams choosing not to take part in these sessions which I think is a shame as their input could be very valuable as they will provide an angle on things that others may not have considered.

Speaking generally, a lot of developers think in a very similar way to each other so you actually end up with them giving similar estimates most of the time.


Retrospectives are where the team gets together to discuss the project, how things are going, and areas where improvements can be made.

The first part of these sessions involves team members putting up on a white board things that have gone well, not gone well, and things that are confusing them to describe one particular retrospective technique.

As long as the safety of the group is fairly high then we can have a reasonable level of confidence that all issues are going to be brought up at some stage.

It is possible even with a perceived good safety level that team members can feel intimidated by others and they don’t want to cause conflict by bringing up issues which will do so.

The voting system used to decide which topics should be discussed after the initial issues have been identified favours a team consensus. There might be an issue which should be discussed for the benefit of the team but if the majority decide it’s not an issue then it may be left out.

The problem of having a lot of people who think in the same way on a team is again raised.

So what can we do instead?

In both agile estimation sessions and retrospectives the most value is gained from these sessions when the opinion of the group is better than any one individual. As I’ve suggested, however, there may be times when this is not the case.

Gojko suggests an interesting way to overcome this:

An immediate thing that comes to mind is to build teams out of people with different opinions. Have people on the team that think differently, use different tools and approach the problems from a different angle. This will help the team spot blind spots easier and avoid the echo effect, increasing the team collective intelligence.

While this is a good idea I think it is very difficult to implement in reality. It does suggest a very different model around team creation than is currently considered good practice.

When we form teams the emphasis is often on creating teams with the greatest skill around working with a particular language for example. Gojko’s suggestion would involve creating a mixed team of Developers with different language specialisations for example. It would be obvious to see how someone coming from a Ruby background could bring a whole different perspective onto a Java project for example.

Assuming that we can’t actually design our teams in this way we can still stay aware of groupthink and how we can avoid it.

In retrospectives we should do whatever is necessary to ensure there is an environment where everyone in the group can express their opinions. One easy way this can be done is to have an outsider facilitate the retrospective – this removes the possibility of an influential team member guiding a retrospective to fit their agenda.

In terms of estimation sessions we should always look to get assumptions out on the table for story cards and never dismiss the estimates of any one person. Using ideas such as pair programming to spread knowledge of a system more quickly is also useful for quickly helping provide team members with more context when making their estimates. There is much more on other techniques of agile estimation on Jay Field’s article here.

I’m sure there are other ideas around these areas for making better use of The Wisdom of Crowds so it would be interesting to hear what you think.

Written by Mark Needham

September 3rd, 2008 at 3:17 pm

The Information Wall

with one comment

Sometimes the simplest things can provide the greatest value to project teams. We often look for a technical solution to problems where something simpler would achieve the same aim.

The Information Wall is as its name may suggest a place where you can put information that people in the team need to know but which they have not (yet) committed to memory.

Examples of things that you could put on an information wall could be:

  • Wiki url
  • SVN repository url
  • Remote machine names & credentials
  • Build server url
  • Useful phone numbers
  • Anything else that’s needed!

Although it may seem to add very little value I think it’s a really good tool for making information accessible to people. It also means you avoid the valueless conversations where team members keep interrupting each other to ask for these details.

Having the wall as close to the development team area as possible is ideal.

Written by Mark Needham

August 20th, 2008 at 12:22 am

Posted in Communication

Tagged with , ,