Last Friday I had a pleasure to get in touch with “MobProgramming” – a kind of pair programming on steroids.
This great event was organized by the “Software Craftshmenship Zurich” – a meetup group I’ve recently joined. It was my first meeting and I have to say I had really enjoyed it.
First of all it was a mixture of different ppl from different backgrounds – so not only .NET but also a Java, JavaScript, Ruby, C++, Python.
Secondly, the event was good prepared – hosts seemed to be prepared and aware how the process should look like and the proper case-study was chosen – adequate for amount of the time we had.
And thirdly – the discussion afterwards was really awesome – lot of ppl wanted to contribute their thoughts and ideas about the process.
So… what is excatly a “MobProgramming“?
MobProgramming is a development practice where the whole team works on the same thing, at the same time, in the same space, and at the same computer.
So you have:
– a Product Owner,
– a driver (person who writes the code, is chosen from navigators circle),
– a navigators (persons who don’t write the code at the moment but analyse the problem ‘on the fly’ and help driver do his job),
– a mediator – the one who always has a “last word to say”.
Driver writes code only for some time, than switches his place with another navigator who also has to switch after some time…
This whole idea was presented by Roy “Woody” Zuill on Øredev Conference @ 6th Nov 2013. The whole video about the idea is available here:
We were around 17 ppl from which created two teams with 8 ppl each. I’ve joined the one writing in Java, we’ve chosen the moderator, project owner and started our 1,5 h workout.
The problem to solve wasn’t hard – some CodeKata about an article and its promotion – but somehow – for us it was quite difficult to begin.
Different people had different understanding about the problem and it took us some time, before we created two totally easy unit tests.
Once we got common point of understanding of the problem we started to rolling!
As according to the rules each navigator sooner or later must sit on a driver’s place, I also had to sit there. And I must say, years after graduating, it was quite funny experience to me to write in Java again, especially as I was writing whole my code just like in .NET 😀
Every time I started a method with an upper case – there was a scream from the audience that “we write it differently!” 🙂 Every time I did something slightly different – there was a scream from the audience. It was almost like a sapper on a minefield trying not to stand on the mine 🙂
Fortunately to me, my new java colleagues forgave me my sins very quickly 🙂
We ended our 1.5 h workout with almost ready solution… and started to make some conclusions about this approach (this part was quite difficult, because each conclusion generated a new interesting discussion and somehow we were jumping from one topic into another).
Anyway, here are some of the conclusions we gathered:
– it was quite hard to start and took us some time till we had all agreed to a common understanding of the problem
– strong product owner is necessary
– sometimes it was difficult to understand suggestions given by navigators to the driver (person who was actually sitting at front of the computer and writing the code)
– team-building is important
– not all persons from the team are required for all the time
– may be hard to negotiate a common solution when several “alpha persons” are on-board
– is more useful as a tool in context of special tasks (eg.: code re-factoring, difficult problems solving) than to use it each day
– for me it was also quite difficult to imagine it in a real life, when we are focusing not only on a current development but also on maintenance and stabilization of existing version (hard to imagine 7 ppl fixing the same bug)
I still can remind myself one conversation afterwards with one of the new colleagues. We were discussing about how productive this approach can be (Woody said in his presentation that he don’t know and encourages others to try), as for me it looked like waste of money to use many specialists for one task.
– What about “pair programming” with its knowledge exchange – do you think it is a “waste” as well? – my colleague asked.
– Hmm.. not really, after some thoughts I had in this area I think “pair programming” may have some advantages to the company/project, so I think I wouldn’t consider it as a “waste” – I answered.
– So what will happen when we will add an extra person to the team of two – will it change your mind?
– Hmm.. I’m not sure, but I think I can still imagine the situation where it may also bring some advantages to the company/project.
– You see, we can consider it also as a small “mob programming”. Equally we can add some more persons to this team and still think areas where it may be useful.
… and he made his point 🙂
