Keynotes and Speakers for ITx 2018
Rob England B.Sc., MIITP, CITP is an independent IT management consultant, trainer, and commentator based in Wellington, New Zealand. Rob is an internationally-recognised thought leader in DevOps and IT Service Management (ITSM) and a published author of seven books and many articles. He is best known for his controversial blog and alter-ego, the IT Skeptic. He speaks regularly at international conferences.
Rob labels himself a "DevOps anticryptoequinologist". (He's interested in DevOps for horses not unicorns.)
Rob is an acknowledged contributor to The DevOps Handbook, and to ITIL (2011 Service Strategy book). Rob was awarded the inaugural New Zealand IT Service Management Champion award for 2010 by itSMFnz, and made a Life Member in 2017.
This workshop covers major underpinning Agile/DevOps/Lean principles that managers need to grasp, to manage or govern the transformation to a new way of working. It equips agile managers to understand, make, and approve decisions on new ways of working: all about the “why”, none of the “what” or “how”.
We will go through ten major principles, with discussions and small games to get our heads around them (and more principles associated with them):
• More important to improve work than to do work
• Work must be sustainable
• You can’t fix a complex system
• Navigate uncertainty and ambiguity
• Trust people
• Success is achieved through failure
• Product not project
• Shift quality left, bake it in
• Get out of the way of the flow of value
• Do less to do more
Most people in traditional IT are challenged by at least one of these ideas. Without these principles, you are likely to think your people are "on drugs", and you may obstruct change (and look silly). Even managers who think they get it, haven't actually internalised these concepts. Come test yourself.
What's more, in order for an organisation to change the leaders need to change. We will talk about what these principles men for the ways that we manage. So come along to get your head around The New Ways Of Working, and The New Ways Of Managing too.
Please note that this is a MasterClass workshop and is at additional cost to the conference.
The cost is $495+GST. Please select this option when registering ITx, or contact firstname.lastname@example.org to register.
When we impose fixed time, money, and deliverables, which is the classic project management formula, then the only variable available to a project manager is the quality of the outputs. So the moment they encounter anything at variance with the requirements and the business case (which they inevitably will, as these are complex systems), they cut short testing, training, and documentation; and they start preparing a formal defect list to be heaved over the wall into production.
We end up in the extraordinary position of being in the business of manufacturing defects which we formally deliver to our customer tied up with a ribbon and ask them to sign them off as delivered.
This is clearly insane.
So how did we get in such a ridiculous position as to be manufacturers of defects?
The answer goes back to the 1980s, and the failure of organisations to effectively govern their IT. All enterprises manage three primary resources: people, money, and information. Back then, governors of organisations were good at managing money and were starting to understand how to manage people, but information was a black art.
As the sophistication and complexity of information management grew, governors and executives became nervous at the increasing amounts of money being put into this resource and their complete lack of understanding of why and how the money was used.
Rather than actually learn and understand as they did for finance and HR, governors responded by imposing a project management framework around IT, where the benefits were promised upfront before money was handed over, and the outcomes were measured at the end.
This would have been OK if it had been done in an agile way - where a program defined what the benefits to be derived were but not how to derive them. unfortunately, IT responded in its usual excessively fastidious way by imposing pedantic engineering methodologies like Prince2 which defined in detail how to execute on delivering the outcomes.
Most of all it led to the lunacy where you don't get your money until you commit to time, cost, and deliverables. All such business cases are theatre, ceremonial, a lie.
At their heart, Agile and DevOps are fundamentally about shedding the yolk of project management and redesigning IT ways of working from first principles to build complex systems without theatre or excessive ceremony. We build systems where we iterate towards a hypothesis, exploring, failing, and incrementally growing a solution.
If you build your organisation out of projects you are building out of blocks that evaporate. A project is a transitory phenomenon, not a structural component. You probably know of one or more organisations whose BAU is whatever was left when the projects vanished.
Building a business out of projects' droppings is a bad idea. We should build our organisation out of products, with standing product teams which are a permanent function for the lifetime of the product. Our operating model is based on product not project.
The project will be at the business level. IT will provide capacity not outcome, through continuous streams of work delivering at a fixed sprint velocity.
Mental health and wellbeing experts join those with first-hand experience managing their own mental health to talk about how to ensure a workplace culture that supports mental wellbeing in the tech sector. Featuring clinical psychologist Jacqui Maguire and Mindfulness coach Kerene Strochnetter alongside tech education researcher Caitlyn Duncan and IT consultant Rob England.
The adoption of DevOps is gaining traction in many businesses, both large and small. The "unicorn" organisations that do DevOps from Day One can plunge right in. For we "horses" that deal with legacy systems and practices, we have to evolve by stages towards a DevOps ideal. As organisations ease into the challenging ideas of DevOps, they grow in maturity through stages. This session will discuss a four-stage model typical of that journey, based on Rob's experiences with clients. We look at how to determine where you are on that model, what to do at each stage, and what some of the implications are for organisational transformation.