Mob programming isn’t for the programmers, it’s for the team.
Mob programming is not just for a programmer’s benefit. I love mob programming and I hope after this blog your interest will be peaked enough to try it with your development team.
Firstly, what is mob programming? It is when the whole development team, product owner and stakeholders all work on the same thing, at the same time, in the same place and on the same computer. We had one driver on the keyboard at a time and rotated this role every seven minutes, everybody was apart of this rotation. That includes myself (Business Analyst) and even our team’s Accessibility Analyst. If you were on the keyboard you were being navigated by everyone else.
I know this concept of working can sound inefficient, so many resources working on a single 3 point story, seven developers, one tester and a business analyst (we had one developer, one tester and our PO absent that day) spending a whole day all working on a single story. However, where inefficiencies are made, they are counter-balanced by efficiencies elsewhere, story kick-off, walk through and code review were all done as we went. Time is saved from scheduling all these steps into the process. We just jumped right in and started the story, I dealt with any questions or concerns in real-time while all the developers collaborated to come up with how we actually meet the stories requirements. As UX, accessibility and myself were present during the stories development the walk-through didn’t need to happen either, the relevant parties had seen it come to fruition already and I was there to make sure our acceptance criteria was met.
We also updated our test cases as a team, our tester was navigating the driver and running us through what he will be testing for, the value this brings alone is priceless. With developers consciously aware of what will be tested made sure they developed and checked their work as they went. This will be a tangible benefit when it comes to testing, we will see minimal to no defects come out of this story. Minimal defects equals minimal unexpected work.
Putting all our developers together to collaborate throughout the stories life-cycle really helped bring out the best outcome. Not just in code quality but in functionality, we got to utilise everybody’s strengths while being able to manage and compensate for everybody’s weaknesses. The knowledge sharing ensures we all learn off each other and grow our skill sets as a team. I learned so much in a single session of mob programming, how styling through code works and what details developers need to style particular things. I can now take what I have learnt and implement it into my stories and elaboration sessions. These changes I make will bring further efficiencies in the long-term as I will have answered questions required by the developers before they will even need to go and ask.
Summary
In summary, collaboration between a team builds stronger a team. What comes when a strong team bonds, is a more efficient team that delivers higher quality software. Mob programming provides these benefits in the long-term, they are noticeable to our scrum from a single session, we will only get better and faster at mob programming from here. In the long-term our scrum could deliver better quality results in shorter time frames.
Agile principles encourages trying new things and trying new ways of working. If mob programming fails to work for your team, so what? You have failed fast and learnt from it. A lesson will be learned about how your team functions and a lesson learnt is never a waste of your time. Just try it.
If you would like to learn more head on over to momenton and hit us up for a chat.
