Master Mobbing
How Macquarie has leveraged mobbing to great effect.
By Dany Jabbour, Scrum Master at Macquarie Group.
We are one of the Scrum teams in Macquarie Bank’s Personal Banking division. We have 10 people in the team. Our goal is to deliver high-value products to the market. We adopted Agile two years ago and we are loving it. One of the main pillars of our success is experimenting.
For every experiment that we have been trying, there has been a need. For Mobbing, it was fast, high-quality product with very short feedback loops.
The way we applied Mobbing was no different to the definition: “ All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer ” (Zuill, Meadows, 2014)
In this article, I will be talking about our experiment with Mobbing, the different approaches that we tried, the failures and most importantly the learnings and continuous improvement.
The first experiment: The organised chaos
It started with the team working on a complex increment which required several people to be involved. We usually swarm, but this one needed another type of peer collaboration, Mobbing. One of our teammates recommended that the whole team sit together in an isolated space for a whole day. Four people would program, while others contributed. Given the need to have short feedback loops, we invited our stakeholders to drop by in three slots throughout the day, to review the progress and give us feedback.
One day prior to Mobbing day, the team got together and highlighted the areas that needed focus. We refined the stories and made them ready for the day. These were mainly UI changes with no dependencies on other teams.
On the day, the team was pumped. We had all our stories and tasks prepared on a Kanban board. The team split into 2 groups. Each of the groups had 2 members to switch piloting and 3 other team members to assist with the requirements and quality engineering. The stakeholders appeared for their first slot and they started asking for “quick wins”. Given the excitement, the team started making some of those changes. You might think “Why did they do that?”, we later thought the same and concluded that we were just too excited. By the time the stakeholders returned, some of these changes were completed, which had them smiling. Other planned changes however did not make it.
Another issue we faced was that one of the technology stack environments had limited deployments throughout the day which slowed us down a lot and blocked us from being able to go live with half of the day’s worth of “done” stories. So, we spent a lot of time stubbing the environment to show the stakeholders what we were building.
Overall by cutting down the iterative cycle of build, test and then demo from over the course of the sprint into the same day, we were able to fail and learn faster.
We succeeded on the engagement and quality sides but did not meet all the objectives.
Summary of learnings:
- Keep everyone focused on the objectives
- Maintain a parking lot for improvement ideas outside of the objectives
- Ensure that the team has all the tools required at hand to succeed
- We found an improvement in code quality by having more eyes reviewing and testing the code
The following experiments: The “Not sure if I like it” phase
Following the first experiment, we decided to try another session to integrate the UI changes to our back-end system. Based on the lessons from the previous session, we built a separate environment to help us go faster. We followed a similar approach, except this time, we committed to less stories. We also challenged the stakeholders to understand the why and keep them focused on the problem we were trying to solve.
Surprise, surprise! Another problem had surfaced. Some team members and stakeholders were not engaged or even required because a lot of the changes were not tangible.
Although we succeeded in meeting the objectives, we failed to utilize some people’s time efficiently and to get their full engagement.
Summary of learnings:
- Design mobbing sessions for maximum engagement by having the right people and by utilizing their time efficiently
- Stories were too technical for some members to elicit feedback within the Mobbing session
The latest: Different take on Mobbing
The last attempt was our most successful.
This attempt was more focused on having the right people. We had a clear objective which was to build a tutorial to upskill some team members. The session was interactive, and we met the objective.
We released a documented tutorial version and it felt great!
Summary of learnings:
- You can Mob for anything, a product increment, a tutorial or requirements
- Focus on the objectives and the right people and quality will happen organically
Conclusion
We continue to use and see the benefits of Mobbing. We experiment, fail, succeed, retrospect then learn and apply for next time. We now have a better idea of the best techniques and requirements for a successful Mobbing session and we continue to refine them.
It’s been a great learning experience and we cannot wait for our next challenge to start with 1 story and release it into production in the same day! Stay tuned!
References
Zuill, W. , Meadows K. (2014). Mob Programming, a whole team approach.
