What to shift left and what to shift right

Shift left was applied to testing and then the testing scope which was initially functional expanded to include performance, security and resilience. So far it is fine, the problem it brings is when the experience aspect is shifted to the extreme left. This ends up with product having endless loops of perfecting the wireframes and experience aspects to get a perfect shot at the finished product.

Imaging you are playing paintball, you have to shoot down very very fast erratically moving drones. You get two options, (1) a gun which can be reloaded as many times as you want and fire in quick succession but needs 2-3 hits to take down a drone, (2) a gun which can be reloaded only once in a few minutes and takes down a drone in 1 hit. If you are given 10 minutes and you win based on how many drones you take down which would you prefer. If you prefer second, then you have shifted everything to the left without the option to learn from your misfires.

Shift left should be for the delivery mechanism. Functionality, security, performance, resilience all should be tested and if at all they fail should fail very very early, closer to the time the code was committed. Along with this an experimental and dark release setup that can be used to learn user behaviour & adoption. This helps the product send umpteen changes to the end user and get the one that works to remain in production.

There is a lot of value in UX research, paper prototype, wireframes and illustrations but when shift left is applied to this, then each iteration and increment becomes very expensive and forces people to figure out as many variables as they want, which is not possible to discover until an end user uses the system.

Misfire is a given in product development, if we shift left everything we have less chances to learn from our misfires. We should also optimise to validate the hypothesis with a working software, so an idea should see reach the customer for validation as much as possible.

Leave a comment