I both do, and have been doing, mob programming for some time now. I think it's a great way of working in some situations and contexts. Basically we have used it as follows: instead of having one or two people working on a thing and then demonstrating how it was done with a code review, we all work on it together. This is usually common when there's something more "difficult" that needs to be done or when there's something that everyone needs to have a good insight into. These sessions usually last between half a day and a day, or perhaps a couple of days (though I have never been part of that) and have involved around 3-8 people. And with these situations in mind, mob programming isn't really something new. It's the setup (how to arrange a mob programming session) that I think is something to look at. I'm not going to go into details about this setup in this post, you can find resources online. Or drop a comment and I'll try to explain.
But how would it be like to always work in a team as a "mob"? I have some questions in mind. Questions I think one should ask even when considering mob programming sessions for shorter periods of time.
1. Productivity/Cost?
To my mind, mob programming feels expensive. I have never performed any experiments to measure if/how/in what way productivity is affected. But looking at what has been accomplished during these mob programming sessions I can't say that the productivity has increased significantly. For us, this hasn't been the main purpose for doing it either. There are other benefits for shorter periods of time.But one can just look at it purely mathematically (statistically).
If 8 people finish a task in 1 hour, that task will have cost 8 hours of work.
If 8 people finish one task each in 1 hour they will have finished 8 tasks, and each task would've cost 1 hour each.
Thus, a mob of 8 people needs to increase their productivity by 800%. OK. I hear you. Nothing is never completely parallelizable and probably 8 people might be able to get things done a bit faster. But still: 800%. Things aren't done that much faster, if any faster at all.
Software developers are expensive already. I don't think those paying us would like it to be even more expensive than it already is. So, this is really something to consider before starting; what are the other benefits of working in this setup?
Those benefits usually revolves around less or no meetings (daily standups, code reviews etc.) and also an increased knowledge sharing and overall code quality, no code merging issues, no nonprogressive items (e.g. when someone is absent). But I think there are things to consider here as well. What about training? Do we send the entire mob? Or just one or two? If so, who? Or is the mob responsible for their own training? How is that arranged? And on another (related) topic; what if the mob works on something and everyone "gets it" except one person who doesn't? Is that person comfortable with asking? Because again: productivity. Suddenly there are 7 people explaining something to 1 person. With 8 people at a halt. It might actually go faster explaining something having 7 people explaining it (more inputs/aspects), but it might just as well go even slower having 7 people talking at once. It leads me to the next question.
2. How to deal with Groupthink? (Or the opposite?)
If you haven't heard about groupthink before, you can read more at wikipedia: Groupthink. Specifically; does the mob foster too much agreement rather than surface disagreement? I have no answer to this kind of question. I haven't done mob programming long enough to have noticed any problems with this, but I would be concerned about this if working in a mob situation for longer periods of time.My experience so far is actually the opposite. I don't know if there's a word for it (similar to "groupthink"), but I've worked in groups containing people with "strong opinions". And that is really good in a way, because it carves out great results (again: in my experience). Thus, you can say that my experience is that we actually are surfacing disagreement. But the flip side of this is that things takes even longer time to complete (see question 1) - reminder: in my experience. We haven't had a need to really deal with this, because carving out great results (and not as in quantitative results) have been the focus and purpose.
3. Rules for opting out?
What would we do if someone in the team doesn't want to mob? How do we make sure that we don't "force" this upon someone? (I guess these are relevant questions for pair programming as well). Does the whole thing collapse? Can someone be allowed to go off into a corner on his/her own? Is that OK? How will the other team members feel about this?I have no answers to these questions. I've only been in groups where everyone really wanted to do it. Except one time. It was a team with only three members, so I don't know if it counts. But anyway, one team member didn't want to do it and we "solved" it by not doing it. We reverted back to one pair and the other developer working on things on his own.
Still, valid questions to consider before starting a mob.
4. What are people's skills and interests?
This is related to the previous question. There might be some people in the group that aren't interested in some areas of development and/or have no intention in deepening a skill in it. Perhaps some people in the group have no interest in SQL or HTML/CSS or graphic design or interaction design or the backend code or anything else. Should we force these tasks upon them? Should we split the mob into smaller mobs? Is it even still a mob then? Have we kind of lost the benefits of the mob then?Again, this has never really been an issue for us. We have worked on very specific things for shorter periods of time. Thus, it has always been interesting for everyone to see and be part of what's done. But is it true for everything and/or in the long run?
5. What are the means for hiring more people?
If we have a mob, why would we hire new/more people? What's the purpose? And a different, but related, question: how big should the mob be? If everyone is working on the same thing anyway, why not reduce to e.g. 5 people or 4 or 3?One reason might be that the mob is missing some kind of competence/skill. But after that? Do we have to form a complete new mob? How big should that mob be? Or should some people (with certain competence/skill) switch between two (or more) mobs? If so, is it still called a mob? Are we limiting ourselves with whom we can hire (see question 3)? Or is it better to just keep increasing the size of the mob to get increased productivity when starting/investigating/experimenting with new initiatives? Or is it better to let the existing mob switch between initiatives? But then... have we lost the ability to hire more people? What will that lead to?
Pair programming
Some of the questions actually apply to pair programming as well. Especially the first question. But with a pair you only have to increase productivity by 200%. And one could argue that the quality level increases by the same amount making the extra cost worth it in a longer perspective. Though in my experience, this is far from always true. In many projects (when I think of it, I guess it's all of them) I've been part of, the cost tends to drift away, forcing us to stop working in pairs after a while or asking for more money/time. That might be bad move in the long run (or not?). And sometimes a single developer might spend way too long time on a task not asking for help as well. And when working as a pair, we always produce more elegant solutions and it always feels very satisfying (and what's that worth?). But still, I think it's a relevant question when pairing as well: is the additional cost actually worth it? Is the quality and knowledge sharing etc. increased by the same amount? Anyway, two people is at least "only" double the cost.Would you hire a painter where one paints while the other is standing behind giving advice? I know, it's not comparable with knowledge work. But from a cost perspective it's still relevant. Would you hire 8 painters with the same setup?
Perhaps there are more questions to ask. Feel free to add those as comments and I might add them.
No comments:
Post a Comment