The failures seem to be a result of the 'focus'. When the focus seems to be on the 'control' of others (ie application groups) rather than the improvement of delivery of services you tend to get off track. When off track, the manner in which the planning, design and process changes are made and how procedures are updated--tend to be without the involvement of the people that use the processes. Or stated another way, that lack of focus on the current state and needs of the business seems to alienate parts of IT and introduce 'dictatorial' approaches.
“DevOps” seems to be evolving as a movement. It has a variety of definitions based on how it’s being used. My summary is that it’s all about communication and people focusing on the right thing…the business. It is an effort to step outside the ‘bureaucracy’ created and start ‘anew’ with limited ‘necessary’ controls and shedding all the unnecessary. Streamlining approaches so they are more ‘agile’ in nature. Focusing more on the delivery of results vs the check of a box to satisfy a process requirement. Eliminating the need for processes that manage other processes that manage other processes that really do the work.
Organizational shifts do not solve problems, communicating and rallying around visions and priorities solves problems. So ‘shifting’ functions to another group will not make the process better… the process owners and stewards are the targets and have the accountability to make things better… a few key thoughts to process improvement:
· Be a good listener – understand the needs of the business
· Focus on the ‘data flow’ and not the ‘org flow’
· Minimize the unnecessary ‘wait states’
· Manage by exceptions and don’t try to control things that don’t need control
· Hold people accountable
· Don’t implement punitive steps because ‘1’ person or group caused a problem.