WWT Software Development Podcast: Recent Episodes
WWT
Product Owners and Agile Business Analysts with Liz Gattra, Director and Practice Lead for the Product Owners and Agile Business Analysts
Software Consulting Services with Dave Blatt, Senior Director and Lead for Software Consulting Services
Application Services with Nate McKie, Vice President and General Manager for Application Services
Mob Programming with Chris S. Chris Spoehr, Performance Manager and Mob Programming Expert
Mob Programming Maxims The team I'm currently on has been trying mob programming for about 4 months now. Recently, I was privileged to attend the first Mob Programming Conference. At the conference, both Woody Zuill and Llewellyn Falco gave compelling keynotes. When I returned to work, my team and I wanted to get the most out of my insights and we quickly began talking about how to level up our mobbing.
We came up with an idea to introduce a third designated, rotating role to our mob when it was large enough. (Our mob flexes in size from 3-6 people.) After driving, a mobster would take on the role of 'facilitator' to observe _how_ the mob was working, and coach the mob when needed. In order to define just what these collaborative ideals are, I compiled these Mob Programming Maxims from my conference notes and slides Woody and Llewellyn have posted online. There is some affinity grouping, but no importance in the ordering. The commentary under each maxim is my interpretation of the meaning and relevance of the maxim.
- For an idea to go from someone’s head into the computer it must go through someone else’s hands. - Llewellyn Falco
This critical mindset behind mob programming comes from Llwellyn's "Strong Style Pair Programming". Working this way forces us to communicate clearly and completely with our teammates. When we're doing this well, this communication is at an abstraction layer. It helps build a shared mental model of the code amongst everyone on the team.
- Turn up the good – Woody Zuill
This concept has such depth that it deserves blog posts of its own. The core idea is one of positivity: instead of potentially applying the wrong fix to the right problem or the right fix to the wrong problem, we take something we're doing well and focus on doing it even better. As we do this, a common side effect is removing base conditions that created an issue in the first place, and those issues 'fall away.'
- Just try it. It’s in the doing that we learn. – Woody Zuill & Llewellyn Falco
One of the strengths of the mob comes from the breadth of ideas that comes from having "all the brilliant people working on the same problem at the same time." Often we will need to discuss how to solve the next issue in front of us. When we do, we discuss it only long enough so everyone understands the different approaches we can take. We bias ourselves toward action. We stop short of debating the merits of each approach. Just code it. We see how each approach looks in code. Then, we decide on which approach to keep, or we may discover a third, better approach has emerged.
- Ask for Trust – Llewellyn Falco
We ask of each person in the mob that they trust we will try everyone's ideas in turn. This is especially vital in a newly formed mob where this trust hasn't been built through experience. Without this trust in place, thrashing can occur. This kind of trust is reinforced by following the "just try it" maxim.
- Respect Each Other
This is another way of saying we should treat each other with "kindness, consideration, and respect", as Woody and the team at Hunter agreed to do. We take the Retrospective Prime Directive to heart and assume our teammates are contributing their best. And we're also all people. Many of us developers might not consider ourselves great at soft-skills, but it doesn't take much to not be an asshole.
- Respect The Code
If we're working on existing code, we should apply the Retrospective Prime Directive to the code itself. It was the best code that could be written by those who wrote at the time they coded it. Even though we may know so much better now, belittling the code (and those who wrote it) doesn't move us forward. However, this doesn't mean not refactoring or rewriting the code. We do need to respect it enough to understand its intention.
- Be prepared to contribute the right thing, at the right time, in the right way – Woody Zuill
When we are in the mob, we should all be prepared to contribute. This may manifest through navigating or driving. It may also manifest through doing research as a navigator to look up the API documentation the mob needs. We are mobbing because we are all valuable to the work being done. We should commit our focus to that work.
A key aspect of this maxim is to resist over-contributing. We must practice the art of not talking to allow space for others to contribute. Using the single-navigator style of mobbing, where only one team member at a time acts to navigate the driver, while the rest silently observe until their turn, helps to reinforce this skill.
- Communicate so the driver understands
- Intent
- Location
- Instruction
As navigators, we want to communicate with our driver at the highest possible level of abstraction. We want to start by communicating the intent of what should be done next, "we need to call the backend to get a list of possible widgets." Only if the driver needs further explanation do we drop down to location, "On line 123 we have a service object that we can call." Lastly, we may sometimes need to give specific instructions to a particular driver, "On line 123, type: var widgets = service.getWidgets();." This may be needed for a new dev or even just new to the tech stack.
- Once the driver understands intent, navigator(s) may move on.
We trust that once our driver understands our intention, we as navigators can start talking about what's next. Getting good at working this way allows us to see the full benefits of the group's collective knowledge and collaboration.
- Rotate as often as is beneficial
We want to rotate often enough to keep everyone engaged in the work we're doing. We prefer shorter rotation times. In fact, the quicker the rotation time the better the mob has to be at switching. Short rotation times also encourage turning up the good on the other mob programming maxims.
There is no one-size-fits-all rotation time. Through experimentation and talking to others at the Mob Programming Conference, our team has discovered that "everyone drives at least once per hour" is a fair heuristic. Our team even added to it to prefer 10 minutes or shorter rotations.
- Take Breaks
When mobbing its easy to not take breaks. We can get into a groove and lose track of time. Or we might think about taking a break but no one else seems to need one so we don't speak up. Part of keeping our workspace comfortable is making sure we take time to physically stretch and rest our minds. Don't be afraid to call for bio breaks.
I hope having these Mob Programming Maxims consolidated in one place helps your mobbing. I look forward to continuing this conversation as we discover more about this new way of working.
Agile Initiatives with John S. Karl Mueller and Myles Bogner interview Director of Agile Initiatives, John Sextro
Sales Engineering with Myles B. Vice President of Research and Development and Sales Engineering Practice Lead, Myles Bogner
Mom Guilt with Angie P. and Kassy M. Director and Regional Manager for Central, Angie Phillips and Contracts Manager, Kassy McMichael
Performance Management with Anna Z, Helena C, Geoff A, and Mackenzie B Performance Managers, Anna Zaslavskaya, Helena Converse, Geoff Armstrong, and Mackenzie Britton
Greed Accelerated Development with Mark B. Dr. Mark Balbes, VP of Architecture
Mark's article on Greed Accelerated Development at ADTMag
Serious Play Game based on “The Advantage” with Jason T. Jason Tice, Business Innovation Consulting Practice Lead
Building Safety With "The Advantage" - Play Test - Agile Games 2018, https://www.youtube.com/watch?v=BuGvo4wJNG4
The Role of Infrastructure Engineer with Elliott S. Elliott Schuhardt, Infrastructure Engineer
Elixir and Woppex with Benjamin L. Benjamin Lee, Software Engineer
Woppex project on GitHub
Swimming in Elixir presentation on GitHub
Google Cloud Platform with Chase C. Chase Clettenberg, Developer and Product Owner Delegate
Agile Thoughts with John Y. John Yorke, Agile Coach
Feedback with Jena M. Jena Moore, Professional Development
Mindfulness with Joy V. Joy Vance, Director of Executive Initiatives
Spotlight with Nate M. Nate McKie, CTO and Co-Founder of WWT Asynchrony Labs
Career of the Week with Tim M. and Sandi S. Tim McManemy sits down with Sandi St. John to discuss a recently opened developer position
Agile Thought with Wayde S. Wayde Stallman