This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
Chaos Week Experience : Learnings Needed Hey All, My name is Siddharth and I am work for Natwest Group (https://www.natwestgroup.com/) as the Global DevOps CoE Practice Lead. Looking forward to yet another exciting #DOES event. In the mean-time seeking in suggestions & feedback on the Chaos Day we are planning later this year globally within the org. Based on Chaos Engineering we are having the Chaos event with following pointers: • Will have it for a week's time. • Remember for Natwest IT employees there are no direct external clients / customers. Every work is done for Natwest only at the end of the day. • The problems will be self identified by the team and will be submitted for review before the event starts. During the submission application they need to get their problem / issue approved by the business SPOC as well in terms of how critical the solutions is which would benefit them. • The Panel then will review the problem and the tools & automation assistance that is seek in the application & check its feasibility. If the relevant team can support it will be accepted else rejected. For e.g. if the team submits a problem that they would solve by having let's say AWS but the concerned cloud team do no think AWS test environment be provided then that submission would be cancelled. • Unlike as the theme of Chaos says, we intend not to break anything however not building any new products / solutions too as happens in typical Hackathon days. We just tweaking it a bit where problem identification happens prior the event. • During the event team will build up a solution along with the relevant tooling or process team along with designated mentors (provided by the event's team) and come up with a solution within a week's time. Basis on the crux of how event is planned to be scheduled. What I am looking forward is: • Your thoughts of the tweaks that we have done and any more possibly we should do. • Traps that we may fall under if proper planning isn't done. • Will our idea work or has worked for you. • What has been your experience by having such a event that I can take a clue from. Apologies for the long message but I felt to write as detailed as possible. If any more info needed in order to share your opinion back, please do let me know. Cheers.
Chaos Week Experience : Learnings Needed Hey All, My name is Siddharth and I am work for Natwest Group (https://www.natwestgroup.com/) as the Global DevOps CoE Practice Lead. Looking forward to yet another exciting #DOES event. In the mean-time seeking in suggestions & feedback on the Chaos Day we are planning later this year globally within the org. Based on Chaos Engineering we are having the Chaos event with following pointers: • Will have it for a week's time. • Remember for Natwest IT employees there are no direct external clients / customers. Every work is done for Natwest only at the end of the day. • The problems will be self identified by the team and will be submitted for review before the event starts. During the submission application they need to get their problem / issue approved by the business SPOC as well in terms of how critical the solutions is which would benefit them. • The Panel then will review the problem and the tools & automation assistance that is seek in the application & check its feasibility. If the relevant team can support it will be accepted else rejected. For e.g. if the team submits a problem that they would solve by having let's say AWS but the concerned cloud team do no think AWS test environment be provided then that submission would be cancelled. • Unlike as the theme of Chaos says, we intend not to break anything however not building any new products / solutions too as happens in typical Hackathon days. We just tweaking it a bit where problem identification happens prior the event. • During the event team will build up a solution along with the relevant tooling or process team along with designated mentors (provided by the event's team) and come up with a solution within a week's time. Basis on the crux of how event is planned to be scheduled. What I am looking forward is: • Your thoughts of the tweaks that we have done and any more possibly we should do. • Traps that we may fall under if proper planning isn't done. • Will our idea work or has worked for you. • What has been your experience by having such a event that I can take a clue from. Apologies for the long message but I felt to write as detailed as possible. If any more info needed in order to share your opinion back, please do let me know. Cheers.
What is the function of the formal application process?
I am sorry @ferrix. Which sentence or part of you referring when you ask about the application process ? I am assuming you talking about in general (which if is not the case please correct me) then it is for any function / application which is being supported or exists within the org.
Ahh that one. As you understand identifying problem is one thing and solving another. I might be aware that for e.g. moving my app to cloud would solve a given problem but is it feasible within the given constraints I may not be the best person. It is there the relevant representation for e.g. the Cloud Solutions SME should be there to make a call. So I need to have representation from let's say the concerned CoEs / CoPs to help me out to making this judgement. So to summarize and answer your ques. the Feasibility Review would be done by the rep. from each Engineering & Architecture teams (primarily but not limited to) to sit down and review each application or rather problem submitted by the team. Does it help ?
Well, if you can allow for some of the ideas to fail and lead to learning, you will need less structure.
Thanks @ferrix point taken. Appreciate the efforts you have put in to share your thoughts.
Is anyone seeing where SDO metrics do not apply as readily to non-stream-aligned teams (I'm using Team Topologies terms here). For example, for teams that would be more in the definition of "Enabling teams" that are not seeing as much value out of Software Delivery & Operational (SDO) Performance metrics. As one example, I have an enabling team whose focused on providing code samples, IaC templates, etc. that stream-aligned teams may consume within the org. These artifacts are "deployed" to code repositories or document repositories. Not traditional application deployments. I think the speed metrics (Lead Time, Deployment Frequency) may be easier to measure here, but unsure about qualities metrics. How do you MTTR a code sample? Or measure CFR? Perhaps measure # of rejected pull requests?). Looking for others' experiences here - or potential proxy metrics - that would still make sense here. We're also looking at measurable DevEx feedback loops within this team, such as # unique hits on code sample pages, CSAT or Customer Effort Scores (CES) when dev teams try to consume these artifacts. But that leans more into Product thinking and whether the team is building the right product, than if they are building the thing right. (cc @me1208, @matthew, @nicolefv, @jez)
My 2c - the DORA metrics don’t apply here as they’re for teams building and deploying running software artefacts into prod (stream aligned, as well as platform, & specialised component teams all). For enabling teams you might want to look at code quality metrics (SonarQube etc) for building the thing right generically. But even that might not work for IaC templates like terraform. But ultimately these teams are, by definition, helping other teams build running software rather than building it themselves - so they will impact the DORA or equivalent metrics of the other teams. Maybe measure them that way, however indirectly - at a “team of teams” level rather than individual team?
That's a good way to look at it. In fact, in the Thoughtworks case study we have in the book (p. 88) that's exactly what they did. The engineering enabling team was measured on the DORA metrics for the application teams/services.
The success of an enabling team is the success of the teams they help enable.
Agreed, I would stick with the "DORA metrics" (or whatever metrics the Value Stream selected) for the respective value streams that this team enables. Creating specific functional (XYZ enablement team) metrics may favor behaviors which do not optimize the end to end value stream.
You might want to think about some kind of measures of how valuable the app teams find the enabling team. Objectively that could be how many code snippets/templates/etc have actually been used and more subjectively something like NPS. I've seen these "enabling" teams becoming either inward-focussed and not listening to what their consumers want, or even worse, self-appointed standards teams, where they (try to) impose their ideas on the apps teams. I don't disagree with the concept of enablement teams, but I often disagree with the implementation.
Agreed, Andy - that's why we included so much detail about expected behaviors and practices for each team type - to act as "magnetic poles" towards which teams should gravitate in terms of behaviors and practices.
Thanks so much all for the feedback!!
What my team is trying to do is align to the overall improvement on the "Innovation Cycle", meaning lead time from idea generation/story pickup to deploy to production - for the teams consuming our tooling. It is a high-level measurement, and feedback on the improvements to this are pretty laggy, but this is the one thing we felt we could most directly impact.