Skip to content

Change Management

Change in any organization is challenging and time consuming. The more significant the change the more challenging it becomes.

  • Evolution = Time
  • Revolution = Pain (biases, stress, redundancies, people leaving, etc)

Establishing "change in others" as a goal can contain much frustration and disappointment.

Consider change in others as a side-effect of your own work, especially when showing leadership and communicating effectively.

Discovering what really motivates people is an interesting challenge in itself but a useful tool to create a meaningful basis for communication.

Introducing Agile

The first rule of Agile: Dont talk about Agile

A focus on 'Agile' as a concept or product are often counter productive, especially when the understanding of what that means in not shared and valued equally.

Adopting agile practices requires a significant change to "ways of working". Such a large change can easily be derailed or be seen as a failure of agile if not managed well.

By discussion of a specific pain point and reaching agreement on the significant cause of the problem, then suitable practices can be applied.

Once a shared understanding of the problem is established, introduce a suitable practice from agile for a trial over the next month to assess if that alleviates the problem.

Feature development lengthy

Introduce a weekly demo to capture feedback on the engineering teams understanding of the feature with the stakeholders.

Stakeholder expectations now being managed or met

Introduce MoSCow rules (Must Have, Should Have, Could Have) to prioritise requirements at the start o the week and set expectation for the stakeholders.

Addressing each specific problem by introducing a practice keeps the focus on the problem and if one particular practice is helpful.

Focusing on specifics will minimise the risk of one issue tarnishing the view of Agile within the organisation.

Introducing a programming language

Imagine introducing Clojure into a company where it is not currently used.

The inital set is to identify what is painful or highly valuable to everyone who would need to make a change (e.g. software engineers, operations teams, managers).

Focus discussions on removing a pain point or non-contentious examples of adding extra value, without referring to Clojure.

I see a lot of people get excited about a technology for themselves, but they forget they have to help other people see how it benefits them if they want their adoption.