Why is DevOps Change Management difficult
This blog on Why DevOps Change Management is difficult is based on conferences and meetups the Daysha team attended in the first half of 2018.
In previous blogs we have written about change management, and there is little doubt that new ways of working are difficult to implement. What follows are the observations of change managers attempts to deliver DevOps.
Financial organisations understand that their own culture can be a problem. They need to have more openness and a ‘millennial friendly’ working environment that can attract younger people who will build what their peers want.
Persuading business people to engage in agile processes is not easy. Persuading business people to attend agile ceremonies can only succeed if the business can see they are being listened to. Finding common language – the language of customer value is vital.
Organisation structure is an impediment to new ways of working. Intellectually everyone knows you need a team to be pulled from silos to get to ‘done’. Existing silos and more informal fiefdoms mean new team structures are very difficult to impose.
Daysha offers SIM as a means to break conventional thinking.
Faux structures such as guilds are emerging. Guilds work well to retrain staff that are becoming free as routine tasks are automated. A new role, DevOps Champion, is being formalised by some companies and identifying these individuals early is a key to success.
Legacy is by far the biggest impediment to progress. Older people nearer to retirement have to be managed correctly. These folks tacit knowledge is an essential element of emergent design processes. These processes can be energising for more experienced staff once they believe its not a waste of time but you may have to show them it works elsewhere.
Reward systems based on more power equating to more direct reports need to be superseded by models based on increasing customer value add. This implies new measurement systems to compensate people. HR engagement is critical.
Several organisations are moving office and re-organising office space to bring about situations where biz, dev and ops teams sit adjacently. Organisations are structuring around product to achieve the same objective. Some organisations are creating more informal space, more open space with set aside quiet spaces for more concentrated work.
When older more established organisations decide to change how they work, they are not afraid; change is something they have experience of. They start with their own leadership to introduce concepts like servant leader models and strategies to empower teams. There is a belief that this approach will reduce cost of management. They anticipate high levels of attrition (up to 30%) and build this estimate into their transformation budgets.
A second generation of DevOps mgt is appearing. Hitherto, there was no experienced IT Mgt for DevOps. Now some of the early adopters are losing their senior people to organisations that are just starting their journey. This second generation are worth watching as they are correcting their first generation errors and should be able to accelerate DevOps journeys with higher quality if the business will let them. This is strong leadership and clear business vision.
Organisations that have outsourced are realising that if they wish to change they must either insource or ensure partners work to simple templates that conform to new ways of working. This can include tools and processes and in turn if there is an insource plan at some point in the future this approach makes it easier to achieve.
One Finnish organisation reduced Operations costs by a factor 4 and improved quality through insourcing. A leading Norwegian financial institution has built a business case to insource in 2019 as the outsource contract ends.
Co-lo is an essential element of a change program and if you cannot co-lo then at least form teams from countries in adjacent time zones.