Author: Per Jansson

A Note From Woody: This is a guest article provided by Per Jansson.  It was posted on his blog and he has graciously allowed us to reproduce it here.

Here is a link to his blog: http://pichdude.wordpress.com/2013/09/15/get-a-good-start-with-mob-programming/

Thanks Per!!!

This is the story about how we in our development team used mob programming as a way to develop software.

Introduction to mob programming

I’m going to start by quoting Marcus Hammarberg, an excellent colleague of mine at Aptitud, since he describes the core of mob programming in a good way:

”The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course). It’s just like doing full-team pair programming.”

Read more about mob programming in his blog post or watch this YouTube video of a real mob programming day compressed into a couple minutes.

Why we tried it

When asked to implement a rather big task, like an epic, you’re often in a state where you have a pretty good picture of what needs to be done on high level, but on a lower level it can be very fluffy and unclear. Fluffy enough to stand in the way of being able to ”slice the cake” in nice, independent, deliverable user stories. Fluffy enough to give us problems if our aim is to have a structured, ordinary sprint backlog prepared, and to burn that backlog down continuously by developing small software increments for a couple of weeks. You know you’re in that fluffy state when:

• Someone asks where a good place to start this epic is and all possible ways you can think of are either intertwined and far from independent steps or just one big mega user story
• You get a urge to just start coding, hack away for a while and see where you end up
• You may even wish that you, for a while at least, could forget everything related to user stories, epics, backlogs and burn downs and just do some Programming, Motherf****r

So why don’t you? Why don’t you just start coding? Maybe the rest of the team feels the same way? Why don’t you all sit down together and start building the solution instead of spending time, maybe even getting stuck, talking about the solution? People with different skills or roles, developers, testers, PO and business analysts can join and help out.

That’s what we did. We were struggling with how to start implementing a new epic. An epic that had a lot of uncertainty and unclarity, both the business requirements and on the technical side.

How we tried it

We had tried creating user stories but didn’t really know where to start or how to break it down into manageable pieces. Pieces that we could divide among us developers or among pairs of developers. One developer had started with some design and code on his own but we weren’t really sure if it was the right way to go.

I had recently heard about mob programming and my stomach was telling me a ”mob” could be just what we needed right now. Since I like to go with gut feeling I briefly explained the concept of mob programming to the team, how it would work and saying it was sort of ”the new kid on the block” of good development practices. Since I’m fortunate to be surrounded by people in my development team that all share a similar view on software development: that it’s better to focus on work items getting done rather than all of us being 100% utilized at all the time, we decided to give it a try. We had nothing to lose and the worst thing that could happen was that we didn’t like it, and that wouldn’t be the end of the world.

The next day we booked a meeting room for the whole day. The room was in another part of the office where we usually aren’t spending any time. We did this because we felt it could be nice to change ”context” when trying mob programming, and also we wanted to avoid interruption as much as possible during this day. We were seven people in total: four java developers, two database developers and one business analyst. All of us had very different levels of experience working with the system, we had worked different amount of time but also with different parts of it. None of us knew everything, but together we knew enough to get started.

As a side note I can mention that the department manager popped in for a while spending time with us and discussing our design and decisions. Afterwards he said he liked the way we worked because it simultaneously solved the problem and also shared knowledge.

We worked on only one computer, one keyboard and one (big) screen for the whole day. Everyone sat by the computer at least once and we switched roughly every thirty minutes. Without going into too much detail the epic was a bit of a ”heart surgery” on the system. Instead of doing all calculations run-time when a user accessed the system we were to introduce a mechanism for calculating and persisting those values in advance, so that they could just be read from the database later when the user accessed the system. This would speed things up a lot and more advanced stuff could be done in the system. During the day we were able to create a first version of a new ”heart”. We coded both in the java layer and the database layer and in the afternoon we did a first successful test run, from start to finish, in the system. The solution was of course rough, dirty, a bit low on test coverage and had a bunch of TODO:s. We wanted to tackle the big problems instead of spending too much time on tiny (but still necessary of course) details.

Benefits of trying it

• It gave everyone in the team, both newbies and experienced, a feeling we knew what this epic was about and how to continue the journey of solving it in a good way
• We were able to organize the work, i.e structure the epic in independent user stories, in a way that would satisfy most managers, scrum masters or product owners in an agile project
• We could continue working in pairs, promiscuous pairs of course, finishing this epic if we didn’t want to do 100% mob programming
• We were able to find many unknowns and uncertainties early. We knew they were out there and that they could only be found once we got our hands dirty in code
• It gave collective ownership of both the problem and the solution
• It spread knowledge. I, as a java developer with a predilection to frontend, learned a lot about triggers in a database. The people working with databases learned a lot about software design, refactoring and so on. And the business analyst learned a lot about how we as developers tackle a problem and why we are so keen on understanding the who and why and not only what of an epic
• It gave a boost in team spirit since we had a lot of fun when doing mob programming

Why it worked well for us

• All necessary skills were present together in the same room, no waiting time and ton of focus
• Some initial work, design and code, was done prior to the mob programming session which gave it a kick start
• We as a development team had a lot of freedom and trust from management to develop software in the way we thought was best
• Everyone had an open mind to this concept and wanted to make it work

So, what are you waiting for? Start a mob!