In most industries a lot of concepts, buzzwords and acronyms are thrown about and IT is by no means an exception. But what happens when ideas appear to be in conflict? How do we work out what to do when? We do work where we're shifting left AND work when we're rightshifting - but which do we do when and why?
What We Mean When We Say Shift Left
The earlier you find a defect, the faster, easier and cheaper it is to fix it. If you can shift your defect resolution process to the left in your Software Development LifeCycle (and, even better, automate your testing from this point) you will see savings made in your overall testing costs and you will be able to put your new code, confidently, to market sooner. This is what we have traditionally meant when we've talking about shifting left. And test automation is one of our trio of automation tools to optimise DevOps.
However, in DevOps projects we often talk about shifting left in another context too: DevOps is about effective collaboration between the (typically siloed) IT organisations of Dev and Ops. A typical complaint that we hear from IT operations organisations is that they feel deployment demands are thrown at them in a rush and they have no visibility of them coming. Not only that, but they are super swamped with unplanned work. We recommend, that as part of a cultural change programme, operations staff are involved in development meetings as early as requirements gathering (this other example of shifting left) so that they have full visibility of the incoming software development pipeline and are fully engaged with the innovation process - and everyone feels harmoniously engaged with the business' goals.
What We Mean When We Say Rightshifting
Rightshifting at its core is about eliminating the waste of human potential in organisations and optimising organisational effectiveness. Working in more effective organisations is a more joyous experience - less frustrating, and a place where individuals have a greater sense of mastery and purpose which directly leads to high work satisfaction and productivity gains: job satisfaction is the number one predictor of organisational effectiveness - see the 2014 State of DevOps report).
When we look at the effectivness of organisations, we see a bell curve - where there are a few ineffective organisations on the left, the majority of organisations performing moderately in the middle and a few 'super-stars' on the right. A highly effective (high productivity, low waste) organisation will have focussed on developing their effectiveness, and the curve, over to the right (rightshifting).
Some organisations look at this bell-curve and view their people on the same chart - some underperformers, most averagely capable and, again, a smattering of superstars. Is this a healthy or ethical way to view your humans? We think not... although you might want to consider it a development curve where, if you get the skills evolution and sharing culture right you can rightshift your workforce in parallel with and with correlation to shifting your organisational position in the market to the right.
Effectiveness and Efficiency
It is important to make a distinction between these two nouns:
Effectiveness: The capability to achieve the chosen set of goals.
Efficiency: The extent to which resources are used in performance of a task.
So you can be effective, but not necessarily efficient. But you can't be efficient if you aren't effective, i.e. completing the tasks or goals set. By being BOTH effective and efficient you are optimising your performance.
Part of the cultural change DevOps drives is an environment where everyone feels mastery in their roles and is properly developed, supported and respected for the jobs that they do in their organisation. This means shifting the organisation, and everyone, over to the right. Drifting left is when an organisation is perishing and losing talent and momentum and the overall quality and performance of the resources is degrading.
Does Shifting Left Drive Rightshifting?
Paradoxically, perhaps, yes. But these concepts are not actually in conflict - one is focussed on moving the processes, or interactions, involved in a component of the Software Development LifeCycle to an earlier point resulting in an earlier completion of the tasks, the other about improving the skill and performance of teams. Shifting left in process DOES deliver an increase in personal and team performance shifting the curve to the right.