Mark Needham

My former colleague Alexandre Martins recently pointed me to a presentation given by Jeff Patton at Agile Roots titled ‘Noone wants your stupid process‘ and it’s one of the most interesting talks I’ve watched recently.

In the talk Jeff cites globo.com as a case study of a company which is using an agile approach to development of their website but are starting to doubt whether it’s the best way to go about things.

In this part of the talk Jeff describes a conversation with the CEO of globo.com where the CEO pointed out that before they started ‘doing agile’ developers used to care a lot about the product that they were building but now they seem to only care about acceptance criteria.

I’ve started to come to a similar conclusion recently and I actually find it way more fun to work on writing scripts that others in my team will use because there are no acceptance criteria and I can concentrate on making it easy for others to use.

An interesting idea which I’ve never heard before is that of pulling out features if they’re not being used.

Presumably the thinking behind this is to simplify the product and make it easier for the user to use.

Patton goes on to quote a model which Jared Spool came up with for describing process:

Tricks -> Techniques -> Process -> Methodology -> Dogma

Spool’s research suggests that if a process is written down and must be followed by people in an organisation i.e. a methodology then it’s very likely that the organisation will be failing.

On the other hand successful organisations used a lot of tricks and techniques and worked out what to do in the moment.

Patton also talks about owning the process rather than allowing it to own us i.e. we don’t want to become a slave to what the process says we should do.

My former colleague Toni Terreno has been talking about the stripped down XP/Agile process that he and his colleagues at Forward have been using which seems a pretty good example of owning the process to me.

Another idea that I quite liked is that of spending more time doing discovery rather than delivery i.e. learning about the world, imagining our solution, evaluating working solutions in the world.

Dan North talks about a similar topic in his ‘Simplicity – The Way of the Unusual Architect‘ talk about half way through.

He also talks about the importance of learning about our users’s in context i.e. we should go to where the users are and see the problems they have and how they are/could use our product.

The last take away for me is that we need to try and find a way to measure the outcome of the product we’re building rather than the output.

Right now we probably measure the velocity in which we’re completing stories but we don’t have a good way of measuring whether or not what we built was valuable to our users.

I really liked this talk, I’d recommend watching it.

My colleague Jason Yip recently tweeted the following…

Sometimes consulting reminds me of the movie Inception

…which reminded me of a conversation I was having with a colleague here who’s been working on consulting engagements here for the last few months.

I was describing some of the things that I wanted to change on my team and she pointed out that I always described each change as something that I wanted to change rather than something which I wanted to see change.

I think this is subconsciously the result of wanting to believe that we’ve influenced something and are actually adding some sort of value to the team we’re working on.

In reality though it’s rare that we can suggest a change and others will just agree with it straight away – I’ve failed with this approach a significant number of times.

In Inception the conspirators want to plant a thought into the victim’s mind but they don’t want him to know that they’ve done it – it should seem like it was his own thought.

My colleague pointed out that the same is true when we’re trying to influence change.

Suggesting a change is unlikely to work but dropping ideas to different people and then letting them run with them might eventually result in change happening even though it may be a slow process.

The problem is that it’s quite difficult to take your own ego out of the equation and let a positive change happen without the credit necessarily being given to you.

I’m still struggling to get past that stage but hopefully soon I shall get there…

A colleague and I ran into an interesting problem today which we wanted to use local port forwarding to solve.

In our environment.rb file we have a Solr instance url defined like so:

SOLR_CONFIG = {
  :service_url => "http://some.internal.address:9983/solr/sco_slave_1"        
}

It’s defined like that because our colleagues in Chicago have setup a Solr instance on a test environment and all the developers hit the same box.

In Pune everyone has Solr configured on their own box so we really wanted to configure that url to be ‘localhost’ on port ’8983′.

Several other colleagues have just changed their environment.rb file and then remember not to check that in.

I always forget about that type of thing though so I wanted to find a work around.

We started by putting the following in /etc/hosts:

127.0.0.1		some.internal.address

Having done that we needed to forward anything coming in on port 9983 to 8983 to complete the forwarding.

I think there’s a proper way of doing this using iptables but we didn’t want to shave the yak and hence used this tcpforward perl script:

./tcpforward -k -l some.internal.address:9983 -c 127.0.0.1:8983

If anyone knows a better way or the proper way to do this I’d be interesting in hearing about that but for now this does the job!

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.

One of the trickiest things to do when working in bigger teams is ensuring that it is possible to parallelise the work we have across the number of pairs that we have available.

From my experience this problem happens much less frequently in smaller teams. Perhaps inevitably it’s much easier to find 2 or 3 things that can be worked on in parallel than it is to find 6 or 7 or more.

As a result we can sometimes end up with the situation where 2 stories are played in parallel with a slight dependency between them.

It may be possible to start those two stories at the same time but one may rely on an implementation of the other in order for it to be considered complete.

It’s not an ideal situation but it still seems doable if we ensure that the two pairs work closely together both metaphorically and in terms of their physical proximity.

I think a more useful strategy is to look at how many things can be worked on in parallel and then deciding the team size rather than choosing the team size and then trying to find a way to make the way the stories are written/played fit around this decision.

This is rarely what happens since budgets/need to get to market quickly often take precedence so we end up working in a sub optimal way.

While this is a trade off that the business may be happy to make I still think it’s useful to identify the risk we’re assuming by taking this approach as well as recognising that the amount of work we can flow through the system is limited by how much we can process in parallel.

I’ve been in India for around 4 months and in that time I think I’ve probably interviewed more people than I have in the last 4 years.

Over this time I’ve come to realise that the two main things I’m looking for in candidates are passion and ability to communicate effectively.

It’s relatively easy to pick up on whether someone is passionate about what they do in a conversation or while pairing with them but I find the communication aspect a bit more tricky.

I’m typically trying to see whether the candidate can explain things at various levels of abstraction, moving up and down the levels as appropriate to get their point across.

With some people it’s really easy for me because they’re able to do this flawlessly without much feedback from me about whether I understand what they’re talking about and if they need to reframe.

However, in the majority of interviews I end up in the situation where the candidate perhaps isn’t explaining something in a way that I can understand.

Either they’re giving way too much irrelevant technical detail or end up beating around the bush at a high level and not really answering the question.

If this situation happened on a team I was working on then I would certainly consider it my job to try and guide the conversation so that we could both get what we want out of it.

After all communication is very much a two way thing.

In the interview context I do the same thing but I would expect the candidate to pick up the hints that I’m not understanding them easily and adjust the way that they reply to future questions to take that into account.

If they don’t seem to take that feedback on board then it’s quite likely that I’ll make the judgement that they’re not able to communicate very clearly and we won’t proceed with the candidate.

I’d be intrigued to hear the approaches others take because it does feel a little bit like I’m doing it wrong in this respect.

In another script I’ve been working on lately I wanted to call ‘mysql’ but unfortunately on my machine it’s ‘mysql5′ rather than ‘mysql’.

I have an alias defined in ‘~/.bash_profile’ so I can call ‘mysql’ from the terminal whenever I want to.

alias mysql=mysql5

Unfortunately shell scripts don’t seem to have access to this alias and the only suggestion I’ve come across while googling this is to source ‘~/.bash_profile’ inside the script.

Since others are going to use the script and might have ‘~/.bashrc’ instead of ‘~/.bash_profile’ I didn’t really want to go down that route.

At this stage a colleague of mine came up with the idea of creating a soft link from mysql to mysql5 inside a folder which is already added to the path.

We located mysql5…

> which mysql5
/opt/local/bin/mysql5

…and then created a soft link like so:

cd /opt/local/bin/mysql5
ln -s mysql5 mysql

And it works!

Of course t’is pure hackery so I’d be interested if anyone knows a better way of getting around this.

I’ve been working on a Ruby script to allow us to automate part of our Solr data setup and part of the task was to check that some environment variables were set and throw an exception if not.

I got a bit stuck initially trying to work out how to return a message showing only the missing environment variables but it turned out to be pretty simple when I came back to it a couple of hours later.

So for my future reference than anything else, this is what I ended up with:

1
2
3
4
5

  variables = %w{VARIABLE_1 VARIABLE_2}
  missing = variables.find_all { |v| ENV[v] == nil }
  unless missing.empty?
    raise "The following variables are missing and are needed to run this script: #{missing.join(', ')}."
  end

I recently came across ‘%w’ which creates a string array out of the values that we specify.

In this case we therefore end up with…

> %w{VARIABLE_1 VARIABLE_2}
["VARIABLE_1", "VARIABLE_2"]

…which I think is pretty neat!

The other neat method is ‘join’ on line 4 which concatenates all the elements of an array while putting the provided separator in between each element.

In this case if we had neither of the variables specified we’d end up with the following:

> ["VARIABLE_1", "VARIABLE_2"].join(', ')
"VARIABLE_1, VARIABLE2"

Something which I’ve become fairly convinced about recently is that the environment that someone works in has far more impact on their perceived performance than their own individual skills.

Given that belief I’ve often got stuck answering why some people are better able to handle a difficult environment than others – in terms of accepting the situation and finding a way of being productive regardless.

Does this mean that they’re better than people who can’t work in that environment as effectively?

That’s certainly a judgement that I’ve made previously but after discussing this with Danilo Sato over instant messenger and Pat Kua & Esther Derby over twitter I can now see that I’m more than likely wrong.

Danilo pointed out that it doesn’t actually means that they’re better, it just means that they’re better at coping.

If we work on improving the system then perhaps we can allow everyone to work more productively.

Esther has a similar view:

@markhneedham Sure. ppl have different ways of coping. Why not improve the system so everyone can do better?

And Pat adds the following:

@markhneedham different strengths and interest at play. Emergent behaviour based on individual and environment

@markhneedham also people have different coping mechanisms and thresholds for tolerance/intolerance

Prior to this conversation I somehow hadn’t considered the benefits we can get from putting people in environments which allow them to play to their strengths.

I think we do this reasonably well when interviewing where one of the key criteria is to consider whether the candidate would enjoy working in the organisation’s environment.

Beyond that perhaps not so well because it’s implicitly assumed that whoever is hired should be able to operate effectively regardless of the environment.

Pat also pointed out that while it is good to work out how to get people into their optimal environment we shouldn’t forget that, as difficult as it may be, improving the system we’re currently working in can also be effective:

Me to Pat:

@patkua ok so it sounds like what you’re saying is we should look to try and place people in environments which are best suited to them

Pat’s reply:

@markhneedham I’m saying that’s one possibility. Changing the system is another. We should be pursuing both strategies.

Just over a year ago I wrote a post about learning one thing each day and since I’ve been struggling to do this lately I thought I’d come back to this topic again.

My general thinking at the time I wrote that post was that sometimes it would be really difficult to find a way to learn anything on the project I was working on and the only way to learn would be to play around with something outside work.

While I still think it’s useful to learn new things I’m moving towards the opinion that we have more chance of making things interesting for ourselves and therefore create opportunities to learn than we might imagine.

The underlying idea is that if it’s boring and repetitive then find a way to make it interesting.

For example, I’ve been working on some cucumber regression tests today and I know that I can easily write the scenarios out manually but it’s incredibly boring and unchallenging for me to do that.

I therefore decided to see if I could construct a cucumber table of the fields to be filled in by using jQuery to find all the field names on the page and then printing them out to the console with the appropriate values before pasting it into the cucumber scenario.

The next step is to see whether it’s possible to record a scenario with Selenium IDE and convert that into a Cucumber scenario, assuming that’s not already been done!

It’s certainly not as productive initially as just writing out the test manually but it’s much more interesting and potentially saves time in the future.

I think it’s much better to take this type of trade off than to just mundanely go through what we’re doing with minimal motivation.