discussion-more 2021-05-19 | Devops Enterprise Summit Slack Archive

Andrew Salt - Arbor Education09:05:30

@olimpia.nitti how did you justify the cost of doing this? Did it slow your new feature deployment down taking resource to do it?

Olimpia Nitti10:05:30

@andrew.salt Yes we prioritized new features to find space for the conversion

Andrew Salt - Arbor Education10:05:16

@olimpia.nitti would be great to chat more about this in Gather if you are free later?

Jon Smart [Sooner Safer Happier]11:05:00

Hi @mik can you expand on your point around roadmaps and OKRs (keep separate) pls?

Mik Kersten (Project to Product, Tasktop)11:05:59

When I first rolled out OKRs at my org 8 years ago we ended up tying some quarterly OKRs to roadmap items (eg, “deliver capability x”. We then realized we were intertwining two planning processes (OKRs and release/sprint planning/roadmapping) in a way that was ineffective as the release plans needed more autonomy and fluidity, whereas we would never change quarterly OKRs during a quarter. So we will still have thematic OKRs (eg, “complete FedRAMP certification level x” that will apply to multiple value streams and that need to feed into roadmaps, but never the detailed roadmap items themselves.

Jon Smart [Sooner Safer Happier]11:05:28

Thanks. So, antipattern was OKRs articulating features rather than Outcomes?

👍 1

Jon Smart [Sooner Safer Happier]11:05:43

And pattern is to allow experimentation and pivoting of the activities and features within the OKR quarterly outcome roadmap?

Bart Kelly (Tasktop)13:05:17

@olimpia.nitti and @colas.a, thanks again for sharing your experience. When you created the shared funding model (70% central, 30% Agile teams), was this distribution driven by the need to decompose legacy apps (creating micro services, aggregating controls, etc.) or was it done for another reason? As your shared services mature do you anticipate the funding distribution to change? Do you have an objective end state in mind?

Alfredo Colas14:05:07

Bart, First a clarification, the 70/30 refers to Agile / DevOps specific investments only not to the overall IT funding model for the company. The actual split was an outcome not a predefined target. The principles were that Central would pay all fixed or enterprise costs and teams would pay for their variable costs.

Alfredo Colas14:05:32

Paraphrasing the DevOps handbook, the central team pays for centralized platforms and tooling services that any Dev or Ops team can use to become more productive so that they can spend more time creating value instead of obtaining the infrastructure (or figuring out which tools to use).

Alfredo Colas14:05:40

But as much as possible, the individual teams will pay for the licenses, hosting or compute costs associated to using those tools.

Alfredo Colas14:05:05

These principles are not unique to DevOps, we use them across the company. We pay centrally, for example, for email or ERP or HR platforms. We expect teams, business units to pay for any platform that is specific to them or for any truly variable costs associated to their usage of the platforms.

Alfredo Colas14:05:43

Long term, my expectation is that central / fix costs go down, adoption goes up and we create significant more value outside of IT costs to justify the on-going investments.

Alfredo Colas14:05:47

@bart.kelly Feel free to reach out to me directly if you have more questions

Bart Kelly (Tasktop)14:05:45

@colas.a thanks for the clarification. I will reach out directly.

2021-05-19

Channels