Published in


How we’ve adapted Mob Programming

The process that helps us achieve amazing results

To get more context on Mob Programming and to understand all the benefits of it, watch this keynote (below).

In case if you are wondering, “should I follow the suggestions?”, I must say that we didn’t follow the rules or guides mentioned in this or any other video. The comparison to the Mob Programming was brought up to my attention by one of our teammates after my explanation of the execution steps we took.

The goal of introducing different workflow than typical agile/scrum/specs/tickets type of mashup was to make things better and fully honour the spirit of innovation. Being that this is a newer idea and framework not everyone may be on board, so be prepared for “constructive criticism”.

I wonder where did we lose the spirit behind the wisdom of agile and the business goal in the game of methodologies?

You must know this page

Did you see this one?

What happened to the motivation for:

  • delivery of business goals?
  • face-to-face conversations?
  • ongoing change?
  • pursuit of simplicity?

Together with Darío, we’ve run a similar mode to Mob Programming for years. We never called it anything, and we never got a chance to apply it to a large team fully.

Over the last month, we’ve run this process successfully in Greyfinch in few small and big projects. It works way better than a typical agile development, that’s for sure. It enabled the company to deliver on time and budget even though the team wasn’t ready for it.

Our new workflow is also fully compliant with emerging design concept flashed out in one of my previous posts 👇 :

Mob Programming

The basics of Mob Programming are different for every team but here’s the round-up for those who didn’t bother watching the keynote:

  • everyone works on the same thing
  • everyone works at the same time
  • everyone works in the same space
  • stand-ups and other agile methodology meetings are replaced with one continuous meeting
  • anyone can join the main meeting
  • anyone can leave the main meeting and work alone
  • there is one computer and the role of a “driver”, or an operator, other present team members watch and share their ideas

Everybody is smarter than anybody — Woody Zuill

Our Workflow

The points below are derived from the most recent project and describe the rules of future workflow. I’ve learned a lot over the last month of experimentation, and that insight is already applied below.

There are few significant differences between what I think we should do as we go forward and what Mob Programming is about in its core. Here how I see us working on the next project:

  • teams are small, made of 2–3 people max
  • every team meets before the day starts to discuss in detail what’s ahead, every team member makes their tasks in close collaboration with other teammates
  • every team works on a well defined, one feature at the time
  • there is no division between front-end and back-end, the team delivers full-feature using the help of schema or JS specialists when needed
  • everyone can join and leave the group working sessions when they feel like to take a break or start working alone on a dedicated task
  • pair-programming or work on individual computers depends on the day and the team decision, there is no need to define the “driver” at all times
  • there are no group stand-ups
  • we don’t make comprehensive specifications ahead of implementation; we implement during the discovery phase; we work and communicate with Product Owners as we write code
  • there is no time defined idea of the sprint, sprint goals, estimations; instead, we start with deadlines, and we work backwards to figure out what resources we might need to deliver on time (that is a continuous effort, not the once off type of decision)
  • we use Objectives and Key Results (OKR’s) framework to define long time goals for each team and the company
  • we don’t write documentation as part of the maintenance process, every time a teammate learns something new they create a PR in a shared knowledge repository with documented code snippets and short comments how did they go about a fix or a solution
  • we act in the most resourceful way we possibly can; when we don’t know what to do we ask each other; when there is no one to ask or the answer is not coming back we address issues we can see without anyone specifically telling us what to do; when we don’t know how to address broken things we research and learn
  • we contribute to automation as we progress with the feature’s implementation because our overall goal is to reduce the amount of manual work, so we can work less and have more thinking time

In short:

Work alone, together, during the discovery phase

It’s important to say that our workflow is not perfected yet. Over the next couple of months, we will be growing our team rapidly, and remotely! That will give us an excellent opportunity to observe and learn new patterns.

Let me repeat; this process is not final. All ideas and improvements should be applied according to team needs.




Creating software for clinics and patients

Recommended from Medium

Activate Parallels Desktop 13 For Mac

How to become a self-taught developer in 2021

How your data is stored on disk and memory?

What is Application Performance Management?

I have one month to make an MMO: Day 2

The more I learn, the more I realize how much I don’t know.

i’m a big fan of miro.

Update: StablePay app for L2 🌐

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Tom Parandyk

Tom Parandyk

Product designer, eager engineer, strategist, wild innovator, proud dad, creative leader, aspiring musician.

More from Medium

What’s Wrong with Project Management — Part 1

3.1 Principles for better Code Reviews

bulletproof code review principles —

The slaves of code

Why Agile Software Development with Scrum is so Awesome?