Responding to Change over Following a Plan

There are two things any individual or organisation can do when anything changes: React or Respond.

The reaction is mainly considered an unthoughtful process, where the result completely depends on the change. The response on the other hand is a thoughtful process, where the change is just one part of the result.

This is also one of the most critical properties which separate humans from machines. On one hand, Machines can only respond in a specific set of ways to any event, on the other hand, Humans can respond in an unmeasurable number of ways. This ability to respond also becomes a critical skill for any organisation.

Most organisations manage the deliveries through projects. And all projects have a fixed set of committed deliverables and a fixed scope of work. Both of these are required for any project to be successful, as they give direction and an end goal to the project. At the same time, these fixed commitments can lead to an organisation being too rigid. And Rigidity never goes hand in hand with uncertainty. This is why the Agile Manifesto prioritises "Responding to Change" over "Following a Plan".

Let us take an example:

Assume an organisation is going to start research and development activities in a completely new technology (Let's say: the next generation of batteries). Since this is a completely new development activity, there have to be huge uncertainties. And to take these activities in a structured way, the organisation should start a project for this. The project should have a customer to guide the team on the final goal. This customer does not necessarily needs to be an external customer, rather the internal product owner can act as a customer. The team will need (at the least) a set of deliverables and a scope of work to complete the project, which must be defined by the customer.

Now, given the number of uncertainties, the project manager should understand that there will be deviations in the plan. In this case, whenever a deviation occurs, sticking to the plan will start causing hindrance. The team might start putting energy into keeping the project running as per the plan instead of focusing on the deliverables. There might be huge monetary and time expenses just to enable the team to stick to the plan. On top of this, the result might be a failure.

Following Agile might be a better way here. Whenever any deviation occurs, the team should discuss and respond to the deviation in the best possible way. The plan should be updated with every obstacle. Though the uncertainties will remain, this will enable the teams to put energy into what matters: the solution. In this case, too the end product might be a failure, but the learnings due to continual focus on the problem and its solution will generate a lot of value in the form of skill generation and learning.

One of the most recent examples of this was the introduction of ChatGPT in Bing. This latest development had put Google in an uncertain situation, and if Google had followed the plan, it might have faced the risk of losing its monopoly. What Google did instead was Respond to the Change. Google released its version of AI-integrated search. It should be noted that in the initial weeks, this didn't turn out to be good at all for Google, but Google is slowly covering all the tracks and making a product that makes sense. The result here is still uncertain, Google might or might not be able to keep its search monopoly, but its ability to respond quickly has given them a very good push. And following the plan might not have worked out for Google at all.

There are many examples like these, and everything boils down to this: For Agility to exist, changes have to be accepted; and for every change, the ability to respond is a must.