The answer is “Pairing”​; What was the question?

  1. The UX/UI/Designer comes up with a wireframe/design/concept.
  2. The devs build it; complaining all the time that the design isn’t “complete” — there’s a missing px width on a button, and some of the colurs aren’t in HEX, etc., etc.
  3. It goes on to a test environment, and the PO has a look. He doesn’t like it (particularly that shade of blue on the button, and the wording’s wrong on the form…).
  4. Go back to step 1
  1. Avoiding silos and single points of failure. Work doesn’t need to stop if no-one is available in a particular role, and if someone falls ill, or leaves the team/company, everything can continue as normal. Also, documentation is often out of date as soon as you’ve written it, so relying on it can be risky. In a team where everyone knows everything, there is less need for documentation as there’s always someone who has the requisite knowledge.
  2. Making better decisions. Increased knowledge leads to better decision making. As an example, if a dev has worked on the front end code that consumes an API, he can make better decisions when updating the API code as he knows the intent of the data being consumed. Both front and back end code can be co-created to be the most efficient.
  3. Increasing consistency. If everyone pairs on all parts of the codebase, all automation scripts, all test definitions, all designs, etc. things end up consistent. This makes them more understandable and mantainable, without the need for highly prescriptive coding standards.
  4. Moving it left. Pairing avoids the problems inherent in a “build then review” development paradigm. Instead of presenting someone with a fait accompli and asking them to review it, just pair with them at the start and agree how best to accomplish the task. This is far better than building something, then having someone review it — and sign it off! — when they know nothing about how or why it was built like it was.
  5. Having the same vision/mission. The more far-reaching the pairing, the more the knowledge is spread, and the more likely it is that everyone understands the overall mission or vision of what is being built.
  6. Nothing falls through the cracks. And, finally, if anybody in a team can do anything, nothing gets missed. If you only have front-end and back-end devs, who’s going to pick tasks around security? SEO? Who’s going to go down to Maplin’s to buy a cable? Who’s going to build that monitor to show the logs? In a proper pairing environment, stuff just always gets done…

--

--

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
Steve Wells

Steve Wells

19 Followers

Building online versions of agile workshops such as the No Estimates game, to see how close we can get to the face-to-face experience for remote or hybrid teams