Every software team wants to ship features that work beautifully. But the path from idea to production is rarely a straight line. Too much process, and you drown in bureaucracy. Too little, and quality slips through the cracks. The GPS Model — standing for Group, Pair, and Solo work — offers a refreshingly simple framework that balances collaboration with individual focus, helping teams deliver software with genuine quality and care.
Originally articulated by Simon Tomes at Ministry of Testing during a major overhaul of the MoTaverse profile page, the GPS Model emerged from real-world practice rather than abstract theory. It’s not a heavyweight methodology — it’s a lens through which to view the different modes of work that quality software demands.
What Is the GPS Model?
The GPS Model identifies three essential modes of work that every software delivery process should weave together:
- G — Group work: Whole-team sessions, stakeholder reviews, community and beta tester feedback loops. This is where diverse perspectives surface blind spots and align expectations.
- P — Pair work: Pair design sessions, pair programming, pair debriefs after testing. Two people working closely together bring focus, shared understanding, and faster decision-making than either solo or full-group settings.
- S — Solo work: Individual deep work — exploratory testing, async development, documentation, and reflection. This is where the concentrated effort happens that no meeting can replace.
The magic isn’t in any single mode — it’s in deliberately cycling through all three. A feature that only sees group work risks design-by-committee. One built entirely solo misses critical outside perspectives. And pair work alone, while powerful, lacks the breadth of group input and the depth of solo concentration.
Group Work: Harnessing Collective Intelligence
Group work creates alignment before a single line of code is written. In the MoTaverse profile overhaul, the process began with a whole-team Miro session where everyone — developers, product leads, community managers — explored what the profile page should accomplish. No requirements document was handed down; instead, the team built shared understanding together.
Group work also shone in the later stages. Ambassadors and beta testers were invited to explore the feature and share honest feedback. Some suggestions made it in; others didn’t. As Tomes notes, “community leadership isn’t finding out what the community wants and giving it to them. Community leadership is working out what the community needs and persuading them it’s what they want.” Group feedback informs decisions — it doesn’t make them for you.
Pair Work: The Sweet Spot of Collaboration
Pair work sits at the heart of the GPS Model. It’s fast, focused, and surprisingly efficient. During the profile page project, pair design sessions between the product lead and a designer produced a full mockup in a single call. Pair debriefs after exploratory testing sessions turned raw observations into actionable changes without the overhead of formal bug reports.
What makes pair work special is the immediate feedback loop. When one person spots an issue, the other can instantly confirm, discuss, and sketch a solution. There’s no waiting for replies, no scheduling the next meeting. The turnaround from discovery to decision shrinks dramatically. Tools like Gemini took notes during debriefs, but the real value came from two people thinking together in real time.
Solo Work: The Foundation of Deep Quality
Solo work is where the quiet, concentrated effort happens. Exploratory testing sessions — timeboxed with clear charters — allowed the tester to probe the feature deeply without interruption. Async development changes were made by a single developer, checked against an informal list of agreed items, and then flagged for review. No ticketing system, no elaborate handoffs. Just focused work with lightweight tracking.
Importantly, solo work in the GPS Model doesn’t mean working in isolation. It means working with clear goals that emerged from group and pair sessions, then bringing the results back for further collaboration. The cycle continues: solo exploration feeds pair debriefs, which feed group reviews, which spark more solo work. Each mode amplifies the others.
Putting the GPS Model into Practice
You don’t need to overhaul your entire development process to benefit from the GPS mindset. Start by asking your team a simple question: which mode are we underusing? If every decision goes through a group meeting, try more pair work. If developers work in silos, introduce pair debriefs after testing. If you never test alone and deeply, schedule a timeboxed exploratory testing charter.
The GPS Model reminds us that quality isn’t a gate at the end — it’s something you build through the rhythm of how you work. Group, pair, solo. Repeat. The result is software that works, built by teams that understand each other.
Source: “How we overhauled the MoTaverse profile page” by Simon Tomes, Ministry of Testing
Photo: Mikhail Nilov / Pexels
Leave a Reply