Kicking things off at the beginning with where Mob Programming (sometimes referred to as Whole Team Approach) came from. No one set out to create this style of working together, it was the result of continually asking How can we work better together? Much of the focus changing from having someone manage the team to letting them manage themselves. Starting with pair programming but over time evolved outward to working as an entire group focused on learning.
Learning to work well together
Getting better at code problems
Here’s the time-lapse of Mob Programming in action.
Why pay two people to do 1 person’s job? What’s the right number of people to have on a team? Both questions are opportunities to try and grow an Agile mindset. Both questions require you to understand what your goal is. With generalized specialists we have the right person guiding at the right time with the help of the rest of the team.
“When we think that we will get 5 separate parallel tracks getting completed were just getting 5 things worked on in the least effective way possible. Separate. That means were going to introduce queueing, inventory, and other kinds of waste”
Once again Don Reinertsen comes up. We’ve heard of him many times and really do recommend checking him out.
Most of the time we spend at work is solving problems. Not typing code or creating documents. Wouldn’t it make sense to include others when solving the problem? It is more likely the solution will be more robust and take less time to solve.
“Mob programming is like Continuous Integration of Ideas.”
Discussed establishing a protocol of how you work together. Define out norms and rules so everyone has a common understanding of expectations with each other. Consider something like a Working Agreement.
“It’s in the doing of the work that we discover the work that we must do”