by on

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.

by on

I have never seen anyone dead from crossing a deadline at work. In literal sense, deadlines are deadly; people die if they cross it yet we use it in our everyday work lives to indicate ETA. I see a persistent need for people to use war metaphors at work to install a sense of urgency. Some examples – Setting up a war room, which is nothing but a cosy meeting room where all stakeholders are present to take a quick decision. Info from the trenches, which is simply getting information from people doing the job. Fire our first salvo, which is releasing the MVP.

War is ugly, even when it has a winner many at times it is pyrrhic. I had interacted with people who had done duty in the military and refugees who have been displaced by war. One word to describe, it is – horrific.

  • War kills and maims people. The worst part is that a good portion of people die or are maimed because of someone else’ decisions. Collateral damage is inevitable
  • There are no rights/justice in a war zone, you get to lose everything and often get displaced if you survive
  • Even basic needs are not available, starvation and diseases are common

Long term ill effects of using these metaphors at work is getting primed to respond only to threats and urgencies not anything else. Many of the workplace issues are because of poor ways of working than poor intent to work from the people.

How to go about work then?

My favourite answer is embrace XP, which treats work as work and people as people. XP helps complex and big goals achievable in simple sustainable and repeatable ways. I also show people the Cynefin framework. It clearly marks how decision making works into 5 different domains. Starts with Clear and progresses to complicated -> complex -> chaotic -> confusion. Below is the image from wikipedia for reference.

War belongs to the chaotic domain, the priority is damage control. Focus is on act and then respond based on what happens, where we learn how to limit our damage. Majority of the work on the other hand either belongs complex or complicated domain. Complex domain is used when building user experience, where we learn what user wants. Complicated domain is used when building automations, where we know what user wants.

By thinking in chaotic terms and using those metaphors we are forced to think of limiting damage not be productive, so ditch the war metaphors at work and start using the terms and metaphors appropriate for the problem domain we are in.

by on

The recent news about overwork death in one of the organisations ,reminded me of some episodes overwork health issues in my work and my friends’. Given a choice everyone wants to get things done quickly, so that either they have a lot of time for leisure or can do a lot more in a short amount of time. When I transitioned to work from college, one major shock was the amount of time that I have to spend at the office even when I did not have much to do. Presenteeism was encouraged, people walking around visibly unwell, staying long hours, eating fast food at desk for lunch.

What people did was just hustle, when what they really wanted was to expedite work. This resulted in chronic overwork, under productivity and poor health (both mental and physical) which was impacting businesses far negatively. When I went to Europe for an assignment, I was so surprised when my client had working hours of just 10 to 5 including lunch and breaks yet that was one of my most productive stints ever.

As orgs grow, workplace dynamics become very complex. A nimble startup growing too fast will lose its nimbleness, it becomes an empire from a small tribe. What contributed to a startup’s success was expediency and fluency.

Expediency is the ability to find a quick way to address a solution which is simple, effective though not a complete one. Richard Gabriel talks about this in Worse is better, it is particularly very helpful in first mover advantage situations and product market fit cases. The simplicity of the solution will also make it easy to amend and extend based on the feedback. Communication and shared understanding across the entire group is the key to expediency and that is where a small team always excels at.

Fluency is the capability to do the right things fast. It is the ability of the people to do things repeatedly without getting fatigued or bored by a healthy blend of capabilities of people, process and engineering. If the team has a robust continuous delivery pipeline, they would not worry about making frequent changes to production. If the team members are highly skilled and disciplined you need less management oversight to make them to follow the right things. If the culture is established that visibility of work is a right and people have a good degree of control/autonomy over how work is done then we have a lot of motivated individuals to realise the goals.

A lot of leaders like expediency alone and it gives them results, they are not able to build on top of it because of poor investment in fluency. This results in a hustle culture with declining return on investments and creating fatigue. On the other hand, leaders focussing only on fluency will create a lots of bored and frustrated teams. Scrum though intended to bring teams to a productive sweet spot is misinterpreted and often ends up creating fatigued teams or indifferent ones. A good focus on the value and intent behind the agile practices like XP and constant questioning & improvement is the key to ensure that the teams are both fluent and expedient.