I’m back from AgileSverige, the premier agile conference in Sweden (IMHO), and this year was no exception. Or rather, it was—exceptionally great from where I sat.
One of the talks that really got me thinking was about mob programming by Tobbe Andeberg and Ville Svärd. Not the technique itself but rather the implications of such a team.
Mob programming is easy to do: put your entire team in a room, give them a single keyboard, and work together to solve the problem at hand. Then take the next problem. And so on. It’s like pair programming but for an entire team.
I’m not sure a team would benefit from mob programming all the time, but the concept got me thinking, thanks to the great presentation by Tobbe and Ville. What if… In this post, I’ll share some ideas and thoughts that sprung from that presentation.
No, I didn’t say “work this way” (neither walk this way, btw). I said: What if… we worked this way? What would happen?
How would our work flow?
What would happen with the flow of our work if everyone in the team worked together? Firstly, how many items would “be on the board”? Yes, one single item would be worked on at the same time.
That means there’s no way that work could flow faster over the board. Everyone would be ready to answer a question the second we need them to. As soon as we need code written, specs reviewed, testing performed, or database scripts updated—we would have the right people there.
This, of course, means we need all the competencies to get the job done in the same room, but hey—we’re doing what-if analysis here. We can dream.
Please note that there will be a lot of slack for many people. Slack as in not everyone will be typing at the same time. Some people might do things that help us move faster or understand things better later. The important thing is that when we need them—they are there. Waiting for our questions.
The fire department has a lot of slack. They are not putting out fires all the time. They’re just sitting around waiting… no, wait a minute. They’re not doing that; they train, maintain their equipment, and keep fit. But they stop doing that the moment there’s a fire. We pay them for not producing “value” (as in putting out fires) and just sitting around waiting to do work. This is because we don’t want to risk them being busy when we need them.
What would happen with roles?
If everyone was working in a mob… there would still be specialists, of course. I’m the one that’s best at doing database work, I have tested stuff like this before, I have coded in JavaScript before. Even I’m the customer. But since we’re sitting in a group that works towards a common goal, those roles will not be that important. In fact, we probably want to smooth the roles out. Why, indeed, are you the only one that knows how to test this? Isn’t that a risk?
If only two people of the mob come in one day, and they are both developers, will they not work with testing? Will they not decide how a feature should work? Would they just give up if database work needs to be done? No—since the work (the one thing they are working on) needs to move forward. They would do the work that is needed.
Care deeply about this. Now
“Why?” you ask. Well, because they care about the product. Or at least they should care about the product. That’s why they show up to the mob each day, right? Building this awesome thing that eventually will change the world.
The only downside is that you cannot tell someone to care. “Now you listen to me; care about this timesheet software. Do it. Now!” It simply doesn’t work that way.
Interestingly enough, it’s much easier to say: “Make sure that the database is up to date”, “You’re in charge of quality for this product”, “When something enters this area of the table you shall move it over there. As fast as possible”.
And that’s what roles are about, when you think about it. In a team that works together towards a common goal, roles are unnecessary. People who care do the tasks needed to make the work flow.
A long-time colleague and friend of mine, Daniel Bruntesson, said this effectively:
Nothing beats giving a crap.
More on roles
Some roles we commonly use are there to “bridge the communication gap” between other parties. Business analysts often describe themselves this way (they OF COURSE do a lot of other useful things too).
If everyone needed to move the work forward is in the same room… that need to take information back and forth between people pretty much goes away.
“But developers and customers cannot understand each other!!! They speak differently.”
So, they would have to do something about that then, right? Otherwise, they will build crappy stuff. In a product that they care about. I think they’ll manage. I trust in the mob and people in it. It’s great people!
What is the name of the process we’re running?
Is the mob doing Scrum? Or XP? Which milestone are they passing right now?
You know what—that’s not important for the mob nor should it be for you. The mob is making work come out the door in the best and fastest way they can come up with for this work.
They might even gasp change the way they work during a workday. Yes, you read that correctly. Mid-iteration. Hey, come to think about it, iteration or not—that’s not important.
“But they’re doing retrospectives and standups right?”
They might. If it’s useful. A retrospective is a great way to step aside and talk about the way you work with a little distance.
Standups… I really don’t know. They are working on one thing. There’s really not much to talk about.
They could have a board to visualize what’s going on, for stuff coming up next, for example, or things that are completed.
This can be a way for the mob to report outwards to other parties what’s going on and what the next things coming up are.
If you want to see a project where this was done in practice (and you speak Swedish), check out Anders Löwenborg’s talk at Agila Sverige. That project had no process. Just people that were very engaged in making a great product. And a product owner that gave them permission and support to do what they (the team) thought was best to make things happen.
Interestingly enough, the same company tried to run another project in the same manner. “Let’s do it like they did.” But that doesn’t work, now does it? It’s not HOW you run it—it’s WHY you run it that makes a difference. Thanks, Anders, for the story and that last point.
Who is the hero in a mob?
A team succeeds and fails as a team. No single person has made this happen, but the parts have worked together to create a better whole, greater than the parts.
The team is the hero, or everyone in the team is the hero if you prefer.
This doesn’t mean we cannot allow greatness within the team. We need great people—the better we are, the better we can help each other to reach our common goal.
Never has this been better put than after a great evening for Swedish football. Sweden played England and won 4-2. Zlatan Ibrahimovic scored all the goals for Sweden. The last one was the most stunning goal seen in a Swedish arena in ages. Maybe forever.
Right after the game, a TV reporter rushed to the Swedish coach and asked: “How about that Zlatan?” The coach grew angry at the reporter:
It’s a team out there. You think he could win against England by himself? I’m proud of the team.
Conclusion
I’m still struggling to see a team ONLY doing mob programming. And this was not a blog post advocating for mob programming. I merely saw mob programming as an extreme form of teamwork and that got me thinking about the implications of that.
Thanks to a bunch of people that I have discussed this with during the week (Calle, Anders, Andy, etc.) and big thanks to Ville and Tobbe who got me thinking about this with their interesting presentation at Agila Sverige.
I hope this got you thinking too. I’d love to hear your thoughts below.