Joining me for Episode #393 of the podcast is Woody Zuill, who does, per his website, “mob Programming workshops, talks and presentations on agile topics,” and he coaches and guides “folks interested in creating a wonderful workplace where people can excel in their work, and in their life.”
I had a chance to meet Woody last year when I saw him speak at an Agile conference and I really enjoyed his perspectives. Woody has also participated quite a bit in a “Lean Consultants Stuck at Home” group that I had organized earlier in the pandemic times.
Topics today include “flow” in software development, the difference between “mob programming” and “paired programming,” and the “no estimates movement” and why that is important. I hope you'll find this interesting even if you don't work in software.
You can listen to the audio or watch the video, below.
Streaming Audio Player:
Video of the Episode:
For a link to this episode, refer people to www.leanblog.org/393.
Questions, Topics, and More
- Introductions
- How did you get into programming?
- What is “flow” in software development?
- You saw pull systems in manufacturing…
- What is “mob programming”?
- Vs. “paired programming”
- Reminds Mark of “collaborative care”
- Dilbert boss would say it's less efficient?
- Efficient vs effective?
- Cynefin framework
- What is the “no estimates” movement and why is that important?
A thought of mine that Woody likes to share on Twitter:
Thanks for listening or watching!
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Thank you for this motivating and thought provoking conversation. I’m a self taught programmer, and for a long time I’ve been breaking my head against the estimates matter. Mr Zuill describes the problem in a grasping and comprehensive manner: estimates are something you cannot get better at… because you’re making product development, the work is rarely repeatable, you don’t have a yardstick of how long things usually take, or even how you’re going to accomplish them! Hearing that was a giant epiphany moment for me.
I think group programming is the way to go; besides mob programming, the experiences described by Menlo on pair programming come to mind from other episodes… But I’d be curious to know about the psychological impacts of adopting this group programming. Pardon me if I sound a bit cliché here, but the usual image you get of computer programmers is very introverted people, who prefer being left alone solving their problems, people who prefer to deal with computers rather than with other people. Changing to this model of group working looks like a tsunami-like culture change, and I’d be interested to know about the challenges encountered when making the leap; maybe material for some new podcast?
You also mention the plague of “institutionalized meetings”, when a meeting becomes “are you going to the 10 o’clock?”, as an entity on its own, a chore that must be fulfilled every day either if it’s necessary or not. I think I understand what you mean, we all have faced at some point that kind of monster in our respective jobs, but at the same time, I wonder: in the Lean circles you often hear of the “Morning meeting” , which is, in a way, also an “institutionalized” meeting, something you do every day at fixed point in time. I think it would be interesting to explore the conceptual difference between one and the other… and maybe how to avoid that one turns into the other :)
Thank you Mark as always for the work you do, Mark, this blog and your podcasts are like a powerhouse of inspiration and kaizen…