I’m back from AgileSverige - the premier agile conference in Sweden (IMHO) and this year was no exception. Or rather it was - it was exceptionally great from where I sat.
One of the talks that really got me thinking was about Mobprogramming by Tobbe Andeberg and Ville Svärd. Not the technique itself but rather the implications of such a team…
Mobprogramming is easy to do; put your entire team in a room. Give them a single keyboard. Work together to solve the problem at hand. Then take the next. Then the next. And so on. It’s like pair programming but for an entire team.
I’m not sure that a team would benefit by doing mobprogramming 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 that 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 too. 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 that we need all the competences to get the job done in the same room, but hey - we’re doing what-if-analysis here. We can dream.
Please note that it will be a lot of slack for a lot of people. Slack as in not everyone will be typing at the same time. Some people might do stuff 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 have 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 are keeping 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 will still be specialists of course. I’m the one that’s best on 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 work against 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 comes 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 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 is about, when you think about it. In a team that works together towards a common goal doesn’t need roles. People that cares do the tasks that’s needed to make the work flow.
A long-time colleague and friend of mine, Daniel Bruntesson, said this in an effective way:
Nothing beats give a crap
More on roles
Some roles we commonly use is there to “bridge the communication gap” between other parties. Business Analysts often describes themselves in 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 passning 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 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 is completed.
This can be away 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öwenborgs talk at Agila Sverige. That project had no process. Just people that was 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.
Interesting enough the same company tried to run another 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 has worked together to a better whole, greater than the parts.
The team is the heros or everyone in the team is the hero if you want.
This doesn’t mean that 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. Won 4 - 2. Zlatan Ibrahimovic scored all of the goals for Sweden. The last one was the most stunning goal seen on a Swedish arena in ages. Maybe forever.
Right after the game a TV-reporter rushed to the Swedish coached and asked: “How about that Zlatan?” The coach grew angry on the reporter:
It’s a team out there. You think he could win against England by himself? I’m proud over the team.
Conclusion
I’m still struggling seeing a team ONLY doing mob programming. And this was not a blog post that was propagating for mob programming. I merely saw mob programming as an extreme form of team-work and that started to get me thinking about the implications of that.
Thanks to bunch of people that I have discussed this with during the week (Calle, Anders, Andy etc) and big thanks to Ville and Tobbe that got me thinking about this with their interesting presentation at Agila Sverige.
I hope this got you thinking too. Love to hear your thoughts below.