Mob Programming & the Power of Flow • Woody Zuill • GOTO 2019

This presentation was recorded at GOTO Berlin 2019. #GOTOcon #GOTOber

Woody Zuill - Senior Consultant, Agile Expertise and Coaching @woodyz53

ABSTRACT
"How can you possibly be productive with 5 people working at one computer?"
This is frequently the first question someone will ask when they first hear about Mob Programming. With Mob Programming 4 or 5 or more people work together at one computer to create software. It seems preposterous, but it's worked well for us, and for many teams. But how can this possibly work?!
Well… I don't propose that I know the answer, but I have a few ideas - and one of the most compelling to me is the idea of flow. There are several common uses of the word, and in software development we hear people talk about being "in the zone", where there is an intense focus that leads to a highly productive state where the sense of time disappears and we experience a sense of ecstasy and clarity.
But there is another use of the work "flow" in the world of Lean Manufacturing and Lean Product Development. In this context by flow we mean the direct completion of work from start to finish with as little wasted time and inventory as possible.
I'll attempt to show how these two seemingly unrelated types of flow come into play [...]

Read the full abstract here:

RECOMMENDED BOOKS

#MobProgramming #Flow #DeveloperProductivity

Looking for a unique learning experience?

SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.

[okezsoke]

Your pronunciation of Mihály Csíkszentmihályi was close to the right one. Any Hungarian could understand. ;)

[WarrenPostma]

It *IS* five people sitting around, mostly doing nothing, while two people, one with a keyboard and mouse, and one without, do something. But whatever. Admitting that it's exactly what it is, is critical to finding the up-side of it. We minimize Question Queue Time and other blockers by simply asking for and receiving help (on slack) whenever we need it.

The worst blocking problems in my org are when someone requests a feature because they did bad analysis and the bad analysis lead to a bad change request that breaks the product for all customers and all use cases, because of one privileged use case that matters a lot right now to management. We have found that being continuously responsive on SLACK and being ready to have audio/video "hangouts" at a moments notice, when these cases occur, reduces our time blocked from hours to minutes.

[hungeri]

Pretty good prounciation of "Mihály Csíkszentmihályi". 'Á' and 'í' are long vowels, 'hály' sounds like 'hi' in English.

[codebullsinc.]

Adopting this as way of working straight away!

[peterpodgorski]

Very good talk, very nice explanation why mob programming makes sense, despite being counter-intuitive to many orgs. The thing I found interesting is that "the circle" there is basically PDSA (just with some steps split into more detail). Fits well into the Lean bit of the talk :)

[yaghiyahbrenner]

Very good video. Clearly demonstrates when you mature past the point of looking at software development as just writing code. The most successful companies in the world uses/used this technique, ego driven co-workers and poor leadership disrupt and destroys flow. many companies has "small pockets" of flow.

[Johnlm]

Did you notice that the author of the brutal artwork is Andrea "Zuill"?

[VS-sart]

I do understand that he is trying to point out the benefits of mob programming, but his whole calculation is just garbage. Someone who gets every hour a blocking questions is just an idiot. Most of us would read the task when given, ask the blocking questions and maybe get another one somewhere 50% into the task, that all. If the initial questions can't be answered directly, you won't start working on the task, if the mid question can't be answered, you would not stop working or "building up inventory", you would write tests, docs. If you are using scrum/kanban you can just switch to other task with slightly lower priority, only in waterfall you may start building up inventory, but even here you can prioritise bugs instead of task, to increase benefits of you work.

Let get one thing out of the way, if you have product owner who needs longer than half an hour to answer your question, because he is "busy" (not because he needs to talk to the stakeholders on this), than your product owner is overworked, mob programming won't help here, in general question queue time can't be solved by mob programming, if someone needs two days to answer your question, than he is either very busy and won't have time to mob program anyway, or the question is so complicated, that he has to align with all his colleges and maybe even the vendor which will generate queue time and block five people instead of one. It is not a working style issue, it is a planning or/and priority issue.

[allanwind]

The echo on the recording makes this difficult to listen to.