This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-05-19
Channels
- # ask-the-speaker-track-1 (220)
- # ask-the-speaker-track-2 (196)
- # ask-the-speaker-track-3 (323)
- # ask-the-speaker-track-4 (212)
- # bof-arch-engineering-ops (1)
- # bof-covid-19-lessons (1)
- # bof-leadership-culture-learning (1)
- # bof-project-to-product (14)
- # bof-sec-audit-compliance-grc (2)
- # demos (7)
- # discussion (1192)
- # discussion-more (15)
- # faq (4)
- # games (69)
- # games-self-tracker (2)
- # gather (5)
- # happy-hour (39)
- # help (79)
- # hiring (10)
- # lean-coffee (13)
- # networking (10)
- # project-to-product (12)
- # psychological-safety (1)
- # summit-info (156)
- # summit-stories (3)
- # xpo-anchore-devsecops (5)
- # xpo-cloudbees (4)
- # xpo-copado (1)
- # xpo-epsagon (1)
- # xpo-gitlab-the-one-devops-platform (13)
- # xpo-harness (1)
- # xpo-hcl-software-devops (9)
- # xpo-ibm (4)
- # xpo-itrevolution (16)
- # xpo-launchdarkly (26)
- # xpo-mirantis-devops (10)
- # xpo-pagerduty (11)
- # xpo-planview-tasktop (10)
- # xpo-redgatesoftware-compliant-database-devops (8)
- # xpo-snyk (3)
- # xpo-sonatype (4)
- # xpo-split (25)
- # xpo-synopsys-sig (4)
- # xpo-tricentis-continuous-testing (4)
@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.nitti would be great to chat more about this in Gather if you are free later?
Hi @mik can you expand on your point around roadmaps and OKRs (keep separate) pls?
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.
Thanks. So, antipattern was OKRs articulating features rather than Outcomes?
And pattern is to allow experimentation and pivoting of the activities and features within the OKR quarterly outcome roadmap?
@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?
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.
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).
But as much as possible, the individual teams will pay for the licenses, hosting or compute costs associated to using those tools.
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.
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.