About this Case Study
I have been running a mob programming team at JPMorgan since the end of 2016. This was the first full-time mob in the firm and this is the story of how we made it happen in the first place, the lessons we've learned on that journey, and some of the observations we've made about how our team now functions. This should be of interest to anyone thinking of trying out mob programming, or those who actively do it and want to improve/address some specific mob problems.
This will be an extended and enriched version of a talk I've given internally at JPM more than once - which triggered waves of people trying out mob programming.
I will cover:
- seeking permission or asking forgiveness to mob - getting started
- physical and material difficulties
- which activities worked well with a mob, and which did not
- dev/engineering practices that make it work
- how to manage occasionally remote team members
- team optimised for resiliency
- team optimised for consistency
- mobbing rules that we developed
- being mindful of introverts in the mob
- maximising the good, minimising the bad
- the team mind
- handling ad-hoc demand (support, queries)
- feedback and the "micro-retrospective"
- in a corporate setting, how to differentiate mob members for EOY/compensation purposes
- mobbing can be hard work and mentally taxing - how do we achieve sustainable pace?
- fighting groupthink and other mob dysfunctions
- communication inside the team, communications outside the team
- recruiting into the mob
- successor planning and roles
About the Speaker
Gordon McMahon is an agile software engineer, agile coach and team leader based in Glasgow, Scotland. He has been practicing XP & TDD since around 2002, and is an active member of the local agile/lean software development community. Most recently he has been enjoying teaching TDD, running mob programming teams and trying to construct some Wardley Maps to help combat/confirm his fear that everything he's working on is just local optimisations in a much larger system.