Mob Programming: not as crazy as it sounds

Thanks to Agile Singapore I saw Woody Zuill speak about mob programming yesterday.

I'd been sceptical about mob programming at first, probably because I'd only heard the term and a one-line description of it rather than hearing from the main proponent of it himself.

The "mob" is not quite the whole team, the "mob" is all the right people being in the right place, at the right time, and working on the same problem on the same computer.  As it happens, that is also what a whole team should be: all the right people.  So, you do not need extra programmers, but you do need the people who know the requirements, understand the system, know how to test it, and sufficient to program it.

What's perhaps more interesting is that mob programming just evolved naturally out of the environment that Woody had cultivated - it was the right thing that needed to be done at that time and it was the right team.

What seeds had been planted to cultivate this environment?

For a start the team was used to working together on problems.  There were weekly study sessions, weekly coding dojo practice sessions.

The team was focused on getting better by effectively using retrospectives so that they could produce better results.

The team - the team of professionals - was also trusted to be able to decide for itself how best to work on something.

Mob programming then began when the team got together to re-familiarise itself with a project and its horrible code base.  Then they just started working on it together.  Then they just carried on, working together on one problem at a time.

Like pair programming, mob programming has a driver-navigator relationship, but in mob programming there is one driver and many navigators.  The programmer as the driver in a pair (or mob) is a "smart input device".  (This is unlike my first experience of pair programming when everything wrong was done, resulting in me acting as a typist for my partner without any thinking going on in my head.)


Mob programming also makes various problems just disappear.

Communication is not a problem when you have all the right people together in the same place at the same time.  The same goes for decision making and meetings.  Thrashing is also eliminated as one problem is completed at a time.

Having the whole team with the same attitude to quality acts as a barrier to the introduction of technical debt, so too does having the whole team understanding the system and working on one problem at the same time rather than producing dissimilar solutions to similar problems.

So mob programming is not as crazy as it sounds, but for it to work you need to have cultivated the right environment, which is not a bad thing to do anyway.

Innovation for Transformation at Agile Vietnam Conference 2017

Yesterday I spoke at Agile Vietnam Conference 2017 giving an updated presentation on TRIZ.  I'd taken the feedback from my previous presentation on TRIZ at Global Scrum Gathering Singapore 2017 and produced something with a bit more focus.  Rather than spending so much time on Genrich Altshuller's story and on the 40 inventive principles I instead focused more on the various tools for inventive thinking.

The end result certainly held together better.  This time I could go into more depth with the tools for inventive thinking and start to apply them to software development scenarios rather than spending half the time introducing the background then spending the rest of the time dancing around the subject and expressing my amazement at the marvellous discoveries.

Then next step is probably to develop some workshops to apply the tools in a group setting.

Here are my slides:
 https://www.slideshare.net/DuncanCampbell5/innovation-for-transformation-agile-vietnam-conference-2017 

Some other highlights from the conference:

• Guillaume Duquesnay talked about Extreme Estimation - a key take-away was to remember that people are much better at comparing things than putting a number to something, which makes relative estimation faster and more accurate (or less inaccurate)
• Silvana Wasitova talked about High Performing Teams with reference to the McCarthys' 12 Core Protocols - I'm still not sure about the Check In with a statement of one's feelings...
• Kiro Harada gave his continually evolving Kaizen talk and introduced the Manifesto for Lazy Product Development; his mention of Muri (overload), Mura (uneven) and Muda (waste) struck a chord, particularly dealing with Muri before one can then deal with Mura and then Muda.