Reflections on a day of mob programming

Last week one of the teams I coach was given a day to build a proof of concept for a new business idea. I thought that #MobProgramming might be a good fit for the day’s activities, so here’s what happened.

There were five of us in the team for the day: three developers, one product owner and one coach/developer (me). The product owner had done some research into the topic we were to explore, but the rest of us were relative novices in the subject matter.

We grabbed a room with a large central table and two whiteboards for the day. We set up two laptops with a projector each, projecting onto the whiteboards. On one laptop we showed the software in the text editor, and on the other we showed the product we were building. To avoid spending too much time setting up fancy sharing schemes, we simply used a github repository to share code between the two laptops: every few minutes we would commit and push from the development laptop, and the product owner would pull and refresh on the product laptop to demonstrate and explore the current version of the product. This worked reasonably well, although occasionally we did launch the product on the development laptop too, for example when we wanted to check something in the Javascript console more quickly than the github cycle would allow.

We began by discussing the product owner’s explorations, and soon we agreed a goal for the day. Our intention was to develop a very simple but useful walking skeleton that would demonstrate a single use case in the problem domain. Throughout the day we regularly revisited our understanding of the goal and compared it to our progress thus far. By 3pm we had achieved our objective, so we spent a further hour or so refactoring and stabilizing our solution, with a view to ensuring that the code would be understandable if or when we came back to it in a week or so.

We developed outside in, in very thin increments. The product owner understood this approach quickly and intuitively, and was very good at guiding us to the next thin slice. The first slice was simply a static “Hello, world!” web page, but it proved our “delivery” pipeline between the two laptops. With each further slice all of us, including the product owner, learnt things that changed our minds about what to develop next.

Occasionally the team got a little carried away and began to write code that the product owner hadn’t asked for, or that was more general than he wanted for the current slice. But as the day wore on the team became better and better at turning his requirements around quickly by doing the (often surprisingly minimal) minimum. I heard myself saying “I don’t think we need to do that” and “Commit!” at frequent intervals throughout the day.

All five of us stayed extremely focussed for the whole exercise, which lasted 7 hours with a half-hour break for lunch. At the end, all of us agreed that we were spent, and that we had greatly enjoyed both mob programming and solving the problem we had set ourselves.

I do, however, have a couple of open questions:

  • Would this have worked with a larger group? Five people felt just about right, and we all remained engaged throughout. Would that have been true for a group of six or seven, or would some team members have found their attention drifting?
  • How did the subject matter contribute? We all remained engaged for the whole day, and I wonder how much that was a consequence of working on a difficult new greenfield problem. Would the same effect have occurred had we worked on the team’s usual legacy codebase?
  • One member of the team was off sick that day. I wonder how she will feel now that everyone else has a deep and shared understanding of the prototype’s design and implementation?
Advertisements

prediction for 2010

I predict that 2010 will be the year that eXtreme Programming returns to centre stage.

Why? Because I believe that XP is what happens when you combine a “single-piece flow” kanban-style agile process with a deep attention to quality and TDD. And because I think CxOs are likely to hear “kanban” more favourably than they hear “extreme”.

iteration zero podcast

A couple of weeks ago Clarke Ching interviewed me as part of his Everyday Agile initiative. The discussion describes what happened when one of my clients, Codeweavers, invited me to participate in kicking off a new project. You can download the MP3 directly from here.

Warning: The sound quality and levels are very poor, because my headset had packed up. So we’ll probably be re-recording it (or something similar) soon.

In the meantime I’m interested to hear from you if you’ve done the same kind of exercise, and how it turned out.

TOC and YAGNI

My apologies if this has been said or written a thousand times before: YAGNI is XP’s way of exploiting the constraint.

Which means that XP, and hence most agile methods, are set up on the assumption that the development team is – or soon will be – the bottleneck. And having identified that bottleneck, our first task is to EXPLOIT it – that is, we make sure that the bottleneck resource only works on stuff that contributes to overall throughput. YAGNI and test-driven development do that. Oh, and a relentless pursuit of quality, so that the bottleneck doesn’t have to spend time on rework. And effective communication, so we get to spend more time developing and less time writing documents and attending meetings. And tight feedback loops, so that we can identify which stuff is valuable and which isn’t.

Next we must SUBORDINATE the whole flow to the pace of the bottleneck. Fixed-length iterations help us to measure that pace, and the various forms of planning game and iteration commitment help to prevent work arriving too fast.

And only when all of that is working well is it safe to ELEVATE the constraint, perhaps by expanding the size of the team. I’m fairly sure I’ve never seen a real-life case in which this step was required. For most of my engagements, successfully exploiting the bottleneck caused the constraint to move elsewhere; and in the rest, the SUBORDINATE step revealed a deeper constraint elsewhere in the organisation.

entrenched positions

It seems to me that one of the principal reasons for the apparent rapid rise of agile methods in software development is the romanticized battle between programmers and managers. Spend any time reading any extreme programming discussion group, for example, and eventually the topic of adopting XP in the face of management resistance will crop up. Agile methods, and XP in particular, would appear to be the saviour of the oppressed programmer; finally the evil tyranny of the waterfall and the heavyweight methodology are crumbling in the face of guerilla resistance from programmers who knew they were right all along! Or that’s how it seems to them.

Does the extreme (sic) zealotry of the programmers represent years of pent-up frustration with the situation in which they found themselves? Do they blame management for controlling them, for keeping them strait-jacketed in heavyweight methods for so many years? If that’s the reason, why were such methods of control deemed necessary in the first place? Two words: manufacturing metaphor.
Continue reading