Jasmin Smith starts out this talk with a disclaimer. If you think that having a non-technical background will keep you outside of the mob programming phenomenon, she wants to set the record straight. NOT TRUE!!!
Mob Programming is the idea that multiple people can program a system, make changes and update the same thing at the same time in the same space on the same system. It basically means that multiple heads are better than one. It also means that it takes driver and navigator to a crazy new level (as in everyone in the car/plane drives and navigates).
Imagine now that you have little or no coding experience. You may be thinking “OK, I really don’t have anything to add here”. That’s a common misconception and one that I can totally understand. I’m the first to admit that if I’m put in front of a blank screen and asked to program something, I’m likely to be lost or at least take a long time to get something going. However, if I see something already in place or being built, I can offer suggestions of where to go.
WARNING: Becker/Fagan Effect about to be invoked here! Yes, Becker/Fagan is a thing. I’m going to make it a thing!
Some people are starters, and some people are finishers or fall somewhere in between. Walter Becker and Donald Fagan were the dynamic duo behind Steely Dan. A quote from Donald was, “Walter can’t start a song and I can’t finish a song. Together, we make a great team.” In this comparison, I’m absolutely a Fagan. I struggle to get things started but I excel at helping look for new avenues to take things.
The Becker/Fagan effect absolutely comes into play with Mob Programming and to my fellow Beckers out there, this is a great place to be. Looking at code and typing out code may not be your thing, but by talking out what’s going into the code, we can still help make decisions and help encourage the development of the system.
Jasmin also answers a real situation that testers face in Mob Programming. We feel we’re not technically competent to be there. It’s understandable but it’s wrong. We bring a lot of things to the table and to the system that everyday programmers don’t necessarily do on a day to day basis (disclaimer: I am not saying that developers can’t/don’t know how to test. That’s nonsense. What they don’t necessarily do is look at the system the way that we do, or more specifically, another programmer will not look at the system the same way that I do. Yes, we may have lesser programming skills but we also have the ability to ask questions, guide inquiry and focus on areas the programmers may not consider. Programming skills can be developed. Inquiry skills can be developed. The great benefit to Mobbing is that we all help level each other up. Programmers become more adept at testing. Testers become more adept at programming. Everyone develops empathy and understanding. More to the point, everyone gets a deeper understanding of the skill set of everyone involved. Over time, each individual’s strength will become more prevalent and the team will know when to call on that. Additionally, the level of skills we develop can grow and expand.
I’m with Jasmine in that this need not be a terrifying experience. If it is terrifying, it probably means the team as a whole needs some help with Mobbing effectively. To borrow from Elisabeth’s talk in the last session, don’t be afraid of having that conversation. Heck, volunteer to facilitate the sessions and if you see deficiencies or areas not being addressed, pull them in and ask them what they would do. The team that benefits most may well be your own :).