Multi Speed IT

Editor's Notes

• #2: © Two Hills Ltd 2015 Created and published by Two Hills letterbox@twohills.co.nz www.twohills.co.nz PO Box 57-150, Mana Porirua 5247 New Zealand This work by Two Hills Ltd is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Content must be attributed to "Two Hills Ltd www.twohills.co.nz".
• #3: The concept of two-speed or bi-modal IT Some example development lifecycles A story of four lifecycles as a project evolves How only half the world can be standardised, and how to deal with the rest Applying this idea to creating lifecycles: some are standard, others bespoke Trust and empowerment. Moving Change Management from control to facilitation What this means for the operating model Governance, risk, and the enterprise How many in the room even understand this analogy?
• #6: Lifecycles are the core of this – I think The essential story here is one of liberation Liberation approaches Agile, DevOps, BYOD…
• #7: Forgive me if this doesnt fit your mental model My characterisation
• #10: A system starts life as new, unusual, experimental. the team have special circumstances that justify doing change in some new way. The business has a high appetite for risk, because they want agility as they explore a new space, probing it to learn what works and responding quickly when they do. Trusted and senior staff develop the lifecycle they require, with a free hand so long as they stay within the policy. The lifecycle is a highly nimble one with rapid unconstrained changes. The team operate and support the system.
• #11: After an initial period, the system stabilises and settles down to known kinds of changes. These get standardised so they can be automated, and a regular cadence of change is adopted after the users get change fatigue from the wild early days. The team find support too distracting from development, and Level 1 is transferred to the central Service Desk. The team becomes a Level 2 and 3 resolver group, as well as iterative developers.
• #12: The team goes through a cost-cutting event and a number of staff are moved out. They no longer have the resources to operate the infrastructure and databases themselves, even though the servers are in the cloud. They persuade central IT Operations to take them on. the servers are moved off Amazon into the private corporate cloud and the central database team start doing maintenance.
• #13: After a year or two, the system is stable, it has become part of business as usual, is changing much less. The business loses interest in funding it, the development team is disbanded except for one developer, and it needs to be operated and supported. The code then goes through all the stages of a traditional waterfall release to production and is handed over to the core Applications Maintenance team as just another system to support. They change it when needed using their conventional conservative change cycle.
• #14: That's four different change lifecycles through the lifetime of the system. Ultimately all systems trickle down to central IT to own as "legacy". Given enough time it all ends up in a conservative operations lifecycle
• #15: There are as many lifecycle stories as you want to tell No one size or two sizes fits all A lifecycle of lifecycles A meta-lifecycle
• #21: The concept of two-speed or bi-modal IT Some example development lifecycles A story of four lifecycles as a project evolves How only half the world can be standardised, and how to deal with the rest Applying this idea to creating lifecycles: some are standard, others bespoke Trust and empowerment. Moving Change Management from control to facilitation What this means for the operating model Governance, risk, and the enterprise
• #22: © Two Hills Ltd 2015 Created and published by Two Hills letterbox@twohills.co.nz www.twohills.co.nz PO Box 57-150, Mana Porirua 5247 New Zealand This work by Two Hills Ltd is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Content must be attributed to "Two Hills Ltd www.twohills.co.nz".