Uncovering better ways of developing software

Over the years I have helped numerous teams in uncovering new ways of developing software and challenging them in their day-to-day collaboration patterns. One of best setups I have used is called mob-programming.

Mob-programming is pair-programming on steroids:

  • traditional pair-programming involves two developers; one writing code and one reviewing it.
  • mob-programming invovles a whole group of team members; one driving the keyboard and mouse while the rest navigates the input

The basic idea of mob-programming is that ideas must go from your head through someone else’s hands before getting into the computer.

Rasmus Kaae, agile coach

Mob-programming consists of two roles:

  • Driver: The person sitting in front of the keyboard. He types whatever input that the navigators ask of him.
  • Navigator: The group of people standing behind the driver. They discuss ideas and give input to the driver informing him which way to go and what to write.

The roles swap in round-robin style after a period of 10-15 minutes. When everyone has been in the driver role the team conduct a small retrospective to improve the proces for the next round.

A generic agenda for a day of mob-programming could be:

  • Welcome and introduction to mob-programming
  • Specify hypothesis for the day
  • Self-organize into cross-functional groups (1 or more)
  • Mob-programming rounds of 15 minutes (periodical retrospective)
  • Demo the output of the work
  • Agree on what next steps for the work
  • Discuss lessons learned from mob-programming

I use a hypothesis driven development approach to setting up the event. The hypothesis is defined in the beginnig of the day, revisited in retrospectives and evaluated at the end. As such it’s important to be realistically ambitious when defining the outcome and success measure.

To define the hypothesis I use this template:

  • We believe that <this capability>
  • Will result in <this outcome>
  • We will know we have succeeded when <we see a measureable signal>

An example hypothesis could be:

  • We believe that time registration on smartphone / tablet
  • Will result in improved data quality of registrations and less time spent on administration
  • We will know we have succeeded when we see employees spending less than one hour on administration per week and

Some of the take aways from running the mob-programming are:

  • You get to know your colleagues better
  • You get to work out-side your own domain of expertise
  • You get to work in a different setting than normal
  • You help your team “not being stuck”
  • You take shared responsibility of the produced work

Be the first to comment on "Uncovering better ways of developing software"

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.