An increasing number of organisations - including many that follow Agile practices - have begun to adopt DevOps as a set of guidelines to help improve the speed and quality of software delivery. However, many of these organisations have created a new 'DevOps team' in order to tackle unfamiliar challenges such as infrastructure automation and automated deployments. Although a dedicated team for infrastructure-as-code can be a useful intermediate step towards greater Dev and Ops collaboration, a long-running 'DevOps team' risks becoming another silo, separating Dev and Ops on a potentially permanent basis. I will share my experiences of working with a variety of large organisations in many different sectors, helping them to adopt a DevOps approach whilst avoiding another team silo.
We will see examples of activities, approaches, and ideas that have helped organisations to avoid a DevOps team silo, including:
This session will provide 'food for thought' when adopting and evolving DevOps within your own organisation.
Bio: Matthew has been building, deploying, and operating non-trivial software systems since 1998. With an approach informed by cybernetics, systems thinking, and neuropsychology, he specialises in helping organisations and teams to adopt and sustain good software systems engineering practices such as Continuous Delivery, DevOps, and aspects of ITIL, with a focus on Software Operability.
He is a Chartered Engineer (CEng) and a regular presenter/facilitator at conferences and workshops around the world. He also initiated and helps to run PIPELINE, a Continuous Delivery conference, and the London Continuous Delivery meetup group."
Grass-roots adoptions of agile principles sometimes fail if they do not convince managers of the value of the new practices. Senior bosses or powerful customers that do not understand collaborative, iterative working are capable of destroying the potential increased productivity of development teams if they do not see the value in good agile behaviour.
Much of the language around agile is emotionally appealing but easily dismissed as childish by hardened executives. On the other hand, Donald Reinertsen's "Flow" starts with the hard line that decisions must be made according to their impact on Lifetime Profitability, yet still winds up advocating most of the practices of Scrum.
Steve examines his own situation working to rescue a "death march" project through a small selection of the principles of Flow. Maybe you will recognise something of your own project here, maybe it won't be too late..
Bio: Steve Carter is scrum master / developer in a small team working in the context of a large automotive software company. His explorations of the lessons and principles of agile, lean and flow are being brought to bear in leading a long-running "death march" project towards health in an environment hostile to collaborative working and sustainable pace. Steve places retrospection and removal of fear at the core of process improvement.