Answering a few questions

Answering QuestionsA week ago I did a Coding Dojo demonstration with Llewellyn Falco at a conference, and showed the Mob Programming video.  One of the audience members sent me an email to ask a few questions about what we’ve been doing, and I responded with my answers.  It seems that others might be wondering about the same things, so here they are:

Question: Thinking in a group setting doesn’t seem productive or even possible.  I assume that when you are stuck on a design some people may go to their cubicles to ponder it. Is this correct?

Answer:  We pretty much work and think all day, every day, in a group setting.  However, every team member is free work alone, take a walk… whatever it takes.

We are interested in effectiveness so we are open to “Whatever works”.  If someone feels they need to take a walk, be alone, or try some things on their own they are free to do so.  However, we  work and “think out loud” as a team most of the time, and use practices that expand and enhance the effectiveness of problem-solving as a group.

As we work together we’ve become better and better at communicating and thinking as a team.  Initially, before we began Mob Programming, we practiced programming together as a group using the Coding Dojos and Katas or other exercises.  Although this was more about learning TDD, Clean Code, and Pair Programming skills, it also worked nicely to help us learn how to work together in a group.

An interesting thing about pair programming using the specific Navigator/Driver pattern we use is that it allows for thinking while the driver is keying in our previous ideas.  We also talk in “English” rathen than “Code” when we are discussing, designing, etc.  Thinking and talking in code tends to limit how we think about our problems and solutions.

In addition to the team approach there are other practices we follow that change the way we think and write code.  For example TDD, “English” First, Code by Intention, and so on all provide improvements on the thinking process.

Question:  What is your team size?

Answer: Our team is 6 people.

We usually work with 5 in the rotation, and I don’t join in as I am generally working on the blocking issues, company stuff like paperwork, and big picture stuff.

Question: What do you think is an optimal size?

Answer: It is working well for us with 5-6.

If we were to start adding team members I would be watching to see if everyone is able to stay engaged and feel that they are contributing or learning.  I would suspect that 5 or 6 is probably a maximum size.  It is important to try to have all the needed skills on the team.  That is a big part of what team is all about – we move quickly through our work partly because we are never waiting for help or someone who is not available.

Building a well running team is a critical factor.  While the exact size of the team is not critical, they must work well as a team.  It must be adjusted for the specific team, organization, and nature of work.

Question:  When scaling the organization it probably makes sense to grow the number of teams, not the number of people in the team. What do you think?

Answer: I would suspect you are right.

A team is a team if they can work well together with everyone bringing value. At some point adding people to a team will likely slow down the work, add no value, or somehow disrupt the team.  When that happens, I would explore putting together another team – or probably the team will have noticed before I do and start reforming into two teams.  I guess we’ll have to see what happens when that happens.

Question: Also, I’d like to learn how you measured your productivity and if there is any data, then how it changed as the team learned to work together (e.g. the timeframe) and (if applicable) as it grew.

Answer:  I have no data that would be useful to you or anyone considering using Mob Programming.

There are a number of variables at play which I hope to write about sometime when I have the time.  However, to speak generally, the team became aware of serious improvements in their ability to deliver working software almost immediately, and it was on the order of 10 times what we were able to achieve before we started teaming.  There are many reasons for this, and my observation is that it is the same sort of synergy that Kent Beck wrote about in the Extreme Programming Explained book.  I think that keeping on track with eliminating waste and working towards effective development are accelerated when working as a true team.

It was while we were learning what “Agile” is and how to put it into use for us that we “invented” or “discovered” or “fell into” Mob Programming.  Our foundation is still the Agile Manifesto and Principles, and the Extreme Programming practices and mindset. In a very real sense, for us Mob Programming is an evolutionary improvement on Pair Programming.

Question: Also, it looks like the first step in your direction would be to first introduce pair programming (starting with myself, as you have suggested). Our teams have never done that and I expect there will be a lot of friction just moving there.

Answer: I don’t feel I can helpfully advise you on this.

I am pretty certain that each organization must find its own path.  As I learn more and get more experience with other teams, perhaps I’ll start forming some ideas about this.

Our path happened the way it did with us not knowing that the idea of “Mob Programming” was where we were going.  It just happened, and once we discovered it we found it was very beneficial and wanted to keep doing it.  Others will perhaps see what we have done and leap-frog to a team approach where we had to just crawl into it.

My friend Llewellyn Falco is using the Mob Programming practice to teach teams how to start working together while learning other programming practices.

If I was to start again somewhere else with a team that does not yet have experience with Pair Programming, I would probably start doing Coding Dojos and be working to build communication skills (with the various team practices and methods typically used in Retrospectives).  Like you say – I’d also find a way for myself to be doing coding, and always asking for a partner for doing the work.  If you live it, others will join in.  Hopefully.  Maybe.  Well, probably not – as it hasn’t worked all that well for me in some situations.  Still, sometimes you just have to do what you think might work and be ready to reflect, tune, and adjust best you can.

If you have questions, please ask.  I’ll do my best to answer them.

2 Comments

  1. After watching your video, I can’t help but to be reminded of the classic scene driving by a street maintenance site.

    There is usually one guy digging or doing some other form of work with 5 or more other guys standing around holding tools watching the one guy doing actual work. It doesn’t seem very productive and it looks like exactly what is going on in your video. How is mob programming any different than that?

    Wodo Spad

    • Oddly, they stole the idea from us.

      Actually, what we do is more like a Rock Band than what you have witnessed with the street maintenance example you give. It is the synergy and interplay of the people involved that makes it possible for us to get better results than we were getting as individuals. I’m not saying this would work for everyone or in every kind of work. But if you are starting a band, or if you are doing software development, you might find it is worth trying to work as a team. Probably would work nicely for street maintenance as well.

Leave a Reply

Your email address will not be published.