This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # ask-the-speaker-track-1 (705)
- # ask-the-speaker-track-2 (287)
- # ask-the-speaker-track-3 (195)
- # ask-the-speaker-track-4 (356)
- # bof-american-airlines (68)
- # bof-arch-engineering-ops (28)
- # bof-covid-19-lessons (4)
- # bof-cust-biz-tech-divide (2)
- # bof-leadership-culture-learning (5)
- # bof-next-gen-ops (10)
- # bof-overcoming-old-wow (7)
- # bof-project-to-product (5)
- # bof-sec-audit-compliance-grc (5)
- # bof-transformation-journeys (6)
- # bof-working-with-data (3)
- # burnout (31)
- # demos (72)
- # games (114)
- # genecon (1193)
- # genecon-help (197)
- # happy-hour (252)
- # hiring (25)
- # lean-coffee (30)
- # networking (20)
- # project-to-product (21)
- # psychological-safety (9)
- # summit-info (798)
- # summit-stories (4)
- # xpo-atlassian (10)
- # xpo-datadog (6)
- # xpo-delphix (32)
- # xpo-digitalai-accelerates-software-delivery (9)
- # xpo-gitlab-the-one-devops-platform (5)
- # xpo-harness (3)
- # xpo-hcl-software-devops (9)
- # xpo-infosys-enterprise-agile-devops (10)
- # xpo-instana (8)
- # xpo-itmethods-manageddevopssaas (9)
- # xpo-itrevolution (20)
- # xpo-launchdarkly (6)
- # xpo-logdna (12)
- # xpo-logzio (2)
- # xpo-moogsoft (4)
- # xpo-muse (7)
- # xpo-nowsecure-mobile-devsecops (6)
- # xpo-opsani (16)
- # xpo-optimizely (3)
- # xpo-pagerduty (10)
- # xpo-pc-devops-qualifications (9)
- # xpo-planview-tasktop (14)
- # xpo-plutora-vsm (10)
- # xpo-redgatesoftware-compliant-database-devops (6)
- # xpo-servicenow (18)
- # xpo-snyk (11)
- # xpo-sonatype (43)
- # xpo-split (34)
- # xpo-sysdig (29)
- # xpo-teamform-teamops-at-scale (20)
- # xpo-transposit (11)
- # xpo-tricentis-continuous-testing (5)
@t.girouard — this is Track 4 for today’s live Q&A during your speaking session. Good luck!
@jeff.keyes @steven.boone @elise-yahner @helen.beal This is where we'll do Q&A for the VendorDome! See you all soon!
Hi everyone! I'll be here to answer questions during and after my session. I've prepared myself for the awkwardness of hearing and seeing myself present. What I'm presenting today took me about 29 takes, half the time I wasn't even able to get my name out right 🙂. Needless to say I miss talking in front of a live audience. With that, I welcome your questions and feedback. Thanks and enjoy the show!
haha, you’ll get used to it, just a matter of staying longer at home on one hand, at the same time, accept how it flows the second time, also on stage for real you’ll make these mistakes. DOES is not the apple event
@mckaymic what was the term you used to describe the name of your squads?
My squad is called Razee. https://en.wikipedia.org/wiki/Razee We spend a few hours scrolling through a list of Nautical terms to find it. We think the definition is quite fitting for our team.
We completely replaced Jenkins for our code delivery. We used LaunchDarkly in conjunction with our Razee CD tools (http://razee.io, shameless plug)
@mckaymic: is this Razee the tool you mention in Phase 4? The one built on top of LaunchDarkly and used by the devs to manage the changes and integrate with SNOW?
It's an internal app we call RazeeFlags. Since we have created it, LaunchDarkly has provided a similar integration with SNOW so eventually we will sunset RazeeFlags
okay, cool. I was about to ask if you were willing to share the source for RazeeFlags haha. One of the big pain points in my org today is SNOW tickets and how to deal with it when moving to DevOps, etc. Therefore I am always interested when someone mentions SNOW in a DevOps talk and some kind of integrations
We could open source it. One hurdle is that our app doesn't communicate with SNOW. We have another service within IBM that provides us an API to create and manage SNOW tickets.
I see, so there is another component in the middle. Gotcha. Would be interested to see an architecture diagram of all the things you talked about here (my solution architect hat speaking now 😉 )
@rodriguessemensati.e Feel free to reach out to me (<mailto:email@example.comfirstname.lastname@example.org>). I'd be happy to talk about this more with you directly.
Nice talk @mckaymic thanks so much!
Welcome @hjewkes for our next session's Q&A! Please feel free to ask your questions and comments for Henry here. Thank you #xpo-split-feature-flags! cc: @madaline.finfrock
Hey, @hjewkes Do you feel that using feature flags or other options to manage feature x code deployment, it's easier to handle it if you use async services as opposed to sync? Async has a level of independence that sync doesn't
Are you asking about it when the service being managed is async, or the feature management tool itself?
The services being managed - ideally one service per feature, though that's not very realistic, but it would look like an ideal scenario to me. If features are implemented in async services, feature flagging would seem to be more straightforward to manage. Many tightly coupled sync services depend improperly on sequence of service calls to work. Feature flagging one of those services might break the chain and cause undesired side effects.
There are certainly approaches out there which leverage deployment and validation of feature changes through routing of traffic to versioned services, in which I do think that this becomes quite relevant, but I think as long as good service contracts are established that feature flags can be leveraged effectively whether sync, async, or monolith. When a feature change impacts multiple services, the flags let you release the changes to each part of the system individually and then rolled out in a coordinated manner to avoid those side effects
I think that when you get legacy code in the conversation, good service contracts (or really any artifact that clearly expresses intent) are the first thing out the window. It's really a lot of small judgment calls until your code is stable enough to be played with more. I am very interested in using feature flagging with a product that I'm working with, but this may not be the first thing we do. Thank you for your thoughts. I am enjoying the presentation
Thats fair, even with all of the tools available the cultural aspects of maintaining strong contracts are challenging. As long as you have an effective implementation, I find that Feature Flags are almost always a safe first step though (of course, I'm biased haha). Effectively any change you are making in the code (in a single service or across services) can be made safer by placing the ownership of its release on the developer or team who wrote it
The first Vendordome session is about to start! Ask your questions here in this channel and get session info here: https://sched.co/ebhq
"any modern software has already telemetry in place" ... yeah, guess we're running a dinosaur 😃
always keeping a positive attitude, I like this!
it's a log type when I write things, that way I can turn it off if I need to.
Could be it different, yeah, but this works for now.
Adventures in DevOps! https://podcasts.apple.com/us/podcast/adventures-in-devops/id1475784710 We discuss a wide range of topics facing DevOps teams, from organizing DevOps teams, release management, cloud services, and the latest security trends. (also replied in the other thread)
Welcome @helen.beal who will be moderating for today's VendorDome Q&A between @steven.boone and @jeff.keyes!
@helen.beal - in your opinion, what is the difference between value stream management and value stream maps?
Hey, Bryant from HCL Software DevOps here! We absolutely do, stop by our booth and watch the demo of HCL Accelerate. The relationship between complex data is key to drive advanced metrics.
You are going to be able to see end to end and then take action on those items day to day with actually seeing your Value Stream and using it.
I have found that when you show them the VSM, the problem shifts from visibility to action. Doing something about it is the real bottleneck in my experience
Yes! You can see the constraints, waste etc but it takes experience to know what to do next
Sometimes the truth is so bad, that it demoralizes the org - it’s too big to face
That's where outside help can be a major boost - there's always something small to start with and build from. If you can run a mapping session, there's probably enough enthusiasm to make some progress.
Its really about the culture of having that conversation. There is a million things that teams can go do, lets get those prioritized!
Hopefully it isn't being simplifying that far.
We want to simplify the data gathering so you have more time to focus on the culture and improvements. Then be able to track if those improvements are working
Companies (ahem some vendors)....of course they are. VSM is much more than that of course.
We do a VSM with every team with do our embed/bootcamps with. They really help bring up waste and make it more visible for the whole team to see what is going on and helps drive better conversations with the teams.
Just recently have we started doing this. Implemented with vendor assistance. Very informative to expose gaps and waste in current processes.
Value stream mapping is definitely becoming the norm, but it's not a one time event. The process is iterative and the map will change (for the better) overtime as gaps/problems are identified.
That is a great point. we do a current vsm at the start and then also give the team a to-be vsm of the items that our team would focus on to remove waste and what that vsm would look like and then drive change toward the to-be vsm and then document the changes of time. Its also a good way to be able to call out the victories the teams make toward CI/CD
The big eye opener for most teams is when you calculate their Value and non-value times along with the flow efficiency of their current vsm.
Thats a great way to do it, get a baseline then set a goal of where you want to be in 6,12,24 months. Then track it and make sure you meet those goals.
Yeah. We even take it a setup farther and help them code the delivery pipeline on one of their repos. We just finished one that took them from getting from pr to stage in 5 days down to 40 minutes.
PS: if anyone's interested in chatting more about this stuff, come out to the lean coffee on value streams soon!
"Brogrammer" shops are nice to work at. but in the wild west there are no indoor plumbing.
@helen.beal IMHO you manage Services in total or in partswhich in turn constitute value stream bits&pieces - backtracking from costvs margins aka pricing policy you come back to discriminating the value stream parts and from there you go up into the Service Tree finding out optimizations in cost/service committments/etc. => my closed loop idea of value stream management 😎😄
hes actually sitting at a piano absolutely ready to riff once this session is over...
@steven.boone Is this "E shape" skillset related to what Gartner is calling a "versatilist"?
Thanks for taking the question. Sorry for the Garter-speak. Former company was big on G so I drank a lot of kool-aid...
Visibility -- or more accurately -- knowing the REAL state of things is always a challenge. Automation of updates to key tools helps a lot but the real trick is getting everything together so that you have an accurate holistic view.
Does maximum value require visibility of features from end to end in the value stream?
The broader the view, the more likely you are to find the real bottleneck, so 'end-to-end' is a key factor
There's a breadth view and depth view. The breadth view is what we want to enable everyone to see and we can best enable handoffs between stages. That's the full end-to-end value stream. However, we don't want to get too caught up in the depth view. This can often derail a value stream mapping session when the specifics aren't important to the great vision. (Example: How many reviews are required to merge a PR?) These are good areas for those specific team leads to hyper focus and refine their own processes.
Absolutely, you get diminishing returns from micro focus, and you risk the attention and energy of the participants
Once the team understands how to use the framework, they can dig in where they want more detail
@steven.boone - VSM are just like Agile Epics/User Stories. How are VS broken down into simple VS and are they useful or just overhead. IO words, is one VSM sufficient?
I'll cover for Steve while he's presenting....we find when modeling value streams, each product team needs one core value stream defined. For larger teams, it's often helpful to have child value streams (subteam or squad level) and/or functional value streams for teams that may cut across multiple product teams.
@james.simon1 from the provider perspective I'd believe so, but not from the customer perspective since they are mainly outcome driven, right ?
Also - I highly recommend adding security testing to your value streams. There are a lot of possible benefits here - one is being able to trace how long it takes to actually move a vulnerability that is reported and added to a backlog all the way out to "fixed in production"
Even better if continual engagement with security, risk, compliance throughout the product development lifecycle.
Absolutely Myles! Imagine getting developers involved in things like threat modeling so they can better understand exposure and risk.
and imagine security better understanding risk from a business perspective and not just vulnerable/not vulnerable.
Agreed - at my previous place of work we established cross functional "Safety Teams" including all governance, risk and compliance support for Value Streams
I agree 100% with this. And it’s not just “take this security tool and make devs run it in CI”. You have to set things up so that it saves time in the end — doesn’t just add another hurdle. Doing this at Dev time needs to make the security review easier. Bonus points if your tools can help devs be more productive (e.g. by flagging non-security issues like reliability / crashing problems, etc.)
Dashboard is like a mirror. Shows you how ugly you are :)
@nickeggleston Someone GOt to invent a DASHBOARD-Integrator or -Tracker / -Sensemaker APP :rolling_on_the_floor_laughing:
it’d be interesting to see the data between the number of dashboards/domo cards/etc correlated to statements like “i dont have the tools to do my job”
This is interesting as I feel we've generally heard that "VSM is a process problem, not a tools problem". However, I agree there are situations where devs where can't perform because they don't have the tools to support them. From personal experience, these are types of issues come to light during retrospectives or the value stream mapping process itself. Once it's tracked and monitored, then the finer adjustments can occur.
Interesting. I wasn’t thinking about developer tools. I build Products for internal team members and i definitely hear a lot about “not having the right tools to do function x” and when we do discovery with these same customers, i see an abundance of domo cards and dashboards.
another benefit is that you can use security as a quality metric - just like you would not push deployment to prod if it failed key tests.... you can do the same with critical vulnerabilities found.
quoting Micheal Scott “Win, win, win, win, win”
We always joked that the CEO wanted a dashboard that just said :thumbsup: or :thumbsdown: with only details with the latter.
What dashboard is your CEO interested in seeing? Just a list of release management requirements? Or the possibly the set of epics that were/weren't delivered?
It worked out over time, that was the joke at the time was "don't tell me the good, tell me who I need to talk to to get things fixed", it was an education for him over time.
We integrate with over 50 tools today in the SDLC! I am currently working with a customer on Aha! and the use cases. Lots of exciting features around tracking larger initiatives in the Value Stream.
Is value stream component reuse count in different streams a good performance/value indicator ?
That is a good question - is certainly lets you know about popularity within the organization. Personally, from a security perspective, I would want to know how many VULNERABLE components were being reused over and over again.
true points I wanted to pivot thinking toward the semantic flexibility in creating value stream components fostering reuse and along your ides better oversight in terms of security management because of less components overall.
Reuse in general lends itself well towards robust and more individuals with insight into how to manage and troubleshoot the process. For example, standardizing around a AppScan proces means there's something the entire organization can rally behind and more easily understand. Whether that's interpreting the results or the standard of High/Medium issues to rectify before release. It sounds like you are starting to reach towards a DevOps or VSM "scorecard" which is an exciting are to think about. How do you quantify best practices down to a number or an A/B/C grade? You should keep an eye on HCL Accelerate. 😉
can you correlate dollars? Dollars saved from outages due to defect reduction, dollars generated by new features (retaining clients, getting new clients, and if features were addition billable item)? can that be visualized too?
Currently we are doing the metric analysis to provide those key insights to the business but yet to put dollar signs to that. We have it on our roadmap and would love to discuss more.
for some of our Ops side development we have started to put in counters to see how often some automation is triggered and adverted downtime, so that we can put some dollars to that, and then get that automation added to Product Development so that we can show the value of the defect reduction.
To add on to that, you can check out more info about HCL Accelerate in the https://doesvirtual.com/hclsoftwaredevops.
Trends over time is key to seeing ROI on these initiatives, we can help out there!
Yes, ROI, is an estimate till it is realized…
Hey, Bryant here from HCL Software DevOps. Being able to see your Value Stream in real-time is a game-changer!
Any tips to reach into silos to get their value streams to feed into the overall value stream? (Kinda like a value stream of value streams :))
As a type of silo, we wrote our own to add clarity to other teams VSM.
One of the key first steps is getting everyone in the room together to talk about the Value Stream. Make sure key stakeholders from those silos are there from end to end. Do it on a white board first, see which stages need some help.
hi, I was wondering if there is any part of Value Stream Mapping dedicated to decision making and the process inherent to it: stakeholders involvement, discussion, validation,
Hello João - that is a really important part of the overall process. The short answer is that it depends on how you set up your stream and the phases that you include in it. As a basic example - people can have a "backlog" phase and then track how long it takes for things to move from the backlog to something else. That process likely involves many of the things you mention. If you find that it is taking a long time - maybe you then add in additional phases to break it down and get better understanding of where those processes are getting stuck.
I actually imagined it would be good to have a separated tracking of the analysis process from the implementation process
It certainly can be, and you are right that the dynamics are different. The point here is being able to have the flexibility and visibility to make better decisions. I have not seen a lot of Value Streams that specifically call out the stakeholder discussions and decisions to date - but you potentially COULD if you found that there were significant delays there.
@brad499 - question asked earlier: @steven.boone Is this "E shape" skillset related to what Gartner is calling a "versatilist"? (edited)
Unplanned work is a killer. Also don't allocate WIP to 100% because you don't have slack to take on unplanned work.
it's a great point Ben - have you found a good way to make unplanned and planned work more visible together?
No yet. Mostly because our ITIL Ops tool is "tuned to" Ops work and our Dev Kanban tool is "tuned to" Dev.
I'm accustomed to "generalizing specialist" (with 'T' or 'H' shaped skills). Did Gartner relabel that as versatilist, or is it something different? (I'm envisioning 'Bill Murray' in Groundhog Day saying 'Oh I;m versatile!' 🙂
I kind of feel like 2020 has been more of the "W" shaped human... up and down and up and down and...
facepalm we really don't need a term like 'versatilist' from Gartner. I agree @brad499, it's multi-disciplinary teams with T-shaped (or comb-shaped) people, as we've known since the 1980s in Japan in Product Development (The New New Product Development Game, 1986)
@jonathansmart1 I know... I find the term cringeworthy, though that's not the first neologism G has come up with to repackage and brand existing information. I love the references you come up with and share.
Choose your pain: Monolithic services suffer from flexibility issues, Micro-Service-Mashes suffer from complexity issues ! It's all about optimizing modularity, reuse, security, sustainability, reliable improvements through release, ... 😥
The sweetest satisfaction comes when we eliminate work that no longer provides value
regarding the topic on penalizing the dev who wants to implement CI/CD or test automation instead of completing story points: well, unless you assign story points for those improvements the developer wants to do... why shouldnt we treat technical debt as any other item in the product backlog? 🙂
You absolutly should then you can show the business with a metric like Distribution what is really happening in the SDLC. My favorite story is helping customers bubble up these technical task that they think are "free" 😉
ha, got featured live, awesome, thanks @helen.beal. I was multitasking and then heard my name and I was like "what, is that me? did I ask something and forgot?" 😄
If we are measuring individual developers by story points, there's more basic things to fix than testing. 😄
Yeah, sorry for the Gartnerspeak... they love to invent terms for things... and I find the V-word rather awkward, but there are a lot of companies that follow Gartner so it helps to know a little of the lingo.
@chris.gallivan good point, but you know that the "walking dead" are resilient ! :rolling_on_the_floor_laughing:
yeah, I like it too, but I have to stop my brain from asking about what powers their movements... ow ow ow ow ow
https://www.youtube.com/watch?v=5Z6EvBFblvg - for whatever reason this comment reminded me of this
the pandemic has exposed a lot of "interesting" features of human psyche and systems...
In some ways human brains are the holographic principles representation of the zombies feeding off of them - chaotic, untrackable in ways, irrational, greedy, maximizing input for unknown output,....:rolling_on_the_floor_laughing:
centralized command and control vs decentralized individual choice and control - which experts do you listen do... quality of data sources...
if you are enjoying the VendorDome session live now, make sure to https://doesvirtual.com/plutora to get a https://doesvirtual.com/plutora of the Forrester report 'https://doesvirtual.com/plutora’ to learn more about how vendors like Plutora are enabling enterprises to accelerate software delivery and improve quality while still managing risk!
Value Stream is looking at the flow of value rather than a methodology. The learnings from Value Stream should help drive what Agile methodologies your team uses. Metrics and stage times are going to give you visibility if your methodology is working for the team. Kanban is the dream right?
Indeed. Seems like if I manage via Kanban, it would be easier for HCL to illuminate things for me
A value stream is the flow of value end-to-end, agnostic of role silos. A kanban board can be used to visualise the value stream. There are points where work is being worked on and work is waiting. A kanban board is helpful to visualise the knowledge work in the system of work
Most kanban boards (irrespective of methodology that are team are using to get work done) is usually a narrow window on the end to end flow (e.g. just the IT bit)
It's not about a methodology. It's understanding and visualising the system of work
Kanban boards are great, but as Jon points out they only cover part of the value stream and they also require manual updating so are often out of sync with reality
This shines a light on the lack of flow upstream with PMO and Finance and Steering Committees
e.g. one org that was saying yes to twice as much work as the throughput of the system of work. They were oblivious to it, until visualised on a giant kanban board / VSM
that's a good strategy to have end-to-end kanban boards, although without connecting the kanban status with additional data like CI/CD and quality data it's difficult to answer questions like should I release this code, where are we slow and what versions are in each environment. By building relationships across all of our tooling, we can start to not only answer these questions but help proactively manage our work.
Yes. Optimise for Better (Quality), Value, Sooner (Flow), Safer, Happier.
@jonathansmart1 I recall images from youre previous talks of maps that took up a whole room. Easy to do if everyone is physically present. In the model where everyone is WFH, how do you visualize and communicate such complexity?
I use Mural for this, but I always try to make maps that only cover 15-20 steps to keep it usable and minimize the cost. You get diminishing returns from detail, and in my experience, a simpler map with more data is better than a huge map where you can't collect as much.
I also create maps at different levels, so there's a separate map for release and one for a single team sprint, and each team has their own map
Virtual boards are much, much better than physical whiteboards. The team can contribute in real time, vote anonymously, add comments, and zoom in where they like, then afterwards it can be exported instantly or shared with anyone in the org.
@jonathansmart1 your point about upstream visibility is so important - it's always the biggest surprise and the most wasteful part, because it's never considered as part of the process
Anyone interested in talking more about all this, come out to the lean coffee on value streams soon!
Steps to implement VSManagement - do a VSMapping first then connect the information flow to one of your products?
a value stream map is a great place to start. once you get an understanding of process and tooling you can start to model it in a VSM tool (like HCL Accelerate). You can get started with just a work item mgmt tool like Jira and then add CI/CD, quality, security and others as you go for more visibility.
"The price of light is less then the cost of darkness" - @jeff.keyes "That's deep man." - @steven.boone
It was pretty solid. Well done. It reminded me of one of my favorites from Rick Warren - "People don't change when they see the light. They change when they feel the heat".
Lots of great conversation here! Get lots of info about the value stream management solution, HCL Accelerate, including a free software download, at the https://doesvirtual.com/hclsoftwaredevops. And check out our https://pages.services/hcltechsw.com/data-driven-devops-ebook/.
The Value Stream - is that created at the deployable unit? the product? the team? the line of business? all? something else?
Fuzzy front end - takes us a long time to decide on the wrong thing to build
Don Reinertsen talks about managing the Fuzzy Front End on this podcast: https://projecttoproduct.org/podcast/don-reinertsen-part-1/ - it’s super insightful!
There is a talk by @halfmoondad later in the conference on the fuzzy front end
lol, I was at a company that 5 years ago just replaced the system what was implemented to replace punch cards. so they are just 2 gen away from punch cards… lol… talk about old technology…
Wow @jeff.keyes - sounds like there is potential for a bunch of "you might be a Silo-ist if...." one-liners
True that! I'm thinking I need to start a list...they just roll out because there are SO MANY SILOS
Have more questions specifically about HCL Accelerate? Ask them in the #xpo-hcl-software-devops channel! And feel free to DM @steven.boone 🙂
Yes, break the silos! Eliminate the wait times and hand offs if they are an impediment to flow. Optimise for the end-to-end flow of the most value, in the shortest time, with the least effort. The biggest impediment to flow will likely be upstream in PMO or Finance. "A system of local optimums is not an optimum system", Goldratt. Limited value to strengthening what is not the weakest link in the chain. ToC.
You will always fire fight until you start building things fire proof.
Paying down technical debt is huge... and the first part is being able to acknowledge its there.
Well Done! Thanks @steven.boone @jeff.keyes @helen.beal for sharing your insights on an interesting and valuable discussion!
That is were attaching dollars for Technical Debt is important.. show how many man hours are used to break=fix, show how many penalties paid to clients. Show how many clients were lost, did not renew… those dollars can really jump you into the line… of Product development.
Want to see Plutora first-hand? Join our demos that start every half hour during the conference! Next ones are at 1:30pm PT, and 2:00pm PT! https://zoom.us/j/94961808380?pwd=R0NYSVRMOE5wNTYvaW16eDdYTC9DQT09!
Sounds interesting but must prioritize session talks and slack catch-up over demos while they are happening...
Having technical debt (items) on the backlog is good. It's not exactly the same thing as treating it identical to a user-story. Even if it gets estimated the same way (e.g., with points or whatever) - you still differentiate between stories (value-items) versus defects vs debt. We want to be able to separate value-adding activity (value demand) from waste production & elimination (failure-demand) versus debt/risk mitigation.
Great talk, thanks for taking questions live,, great job with being MC @helen.beal
Getting started - paraphrasing @jeff.keyes Pre-work 1. Pick an app 2. Look at it end to end Then once you have that 1. Pull a bunch of people into a room and put a box for every step in the process 2. Then get the data from all those tools into process and note places were "gosh its kind of dumb that we are doing THAT" or "WOW that is taking a lot longer than it should" 3. Make some changes, measure the results and tweak/refine @steven.boone - you need to understand where the handoffs are and then go to them and go "how can I work better with you". Understand how their job operates and that will help you understand the things you need to do.
And when you are done that step, keep looking, asking questions, challenging the existing. There is always room for improvement when you look at the end to end flow as every system has at least one constraint.
Welcome @colin827 for our next session's Q&A! Please share your questions and comments here! Thank you also to #xpo-sonatype-devsecops
continue the conversation with @jeff.keyes @helen.beal @steven.boone over in #ask-the-speaker-more !
Tonight - grab a pint and let's talk pipelines! Join the #xpo-hcl-software-devops "Pints and Pipelines" happy hour with @bryant.schuck and @nicholas.mathison to learn how to get started with the free Community Edition of our value stream management tool, HCL Accelerate. https://pages.services/hcltechsw.com/does-virtual-2020/
Great job covering a lot of important topics @steven.boone @jeff.keyes @helen.beal!
Code in PROD with confidence - what is the key thing to get that confidence? (tools? practices? testing or proper test environment?)
All of the above. Tools help with automation and verification. Processes are key to having Information Security, Audit etc become comfortable with what you are doing
Proper Test Environments are also key - having configuration drift between environments leads to problems in production
Well said. I feel like test environment management (or lack of) is a major Achilles Heel of any DevOps transformation
Yes, In addition to the Test Environments such as servers, middleware, configuration etc. I think a lot of organization miss the data aspects of Test Environments - have proper set of test data that you can consistently and quickly reuse is a critical.
That's a constant struggle, as well, and lack of data causes app dev teams to do everything possible to skip good testing, or pole vault over one test env into another.
That pole vaulting is something I've seen cause immense amounts of pain. Test data management is an art. Phrases like "data masking" get thrown around like it is easy.
It's one of the harder things with larger complex environments - especially when you have multiple applications and your micro-services are stateful - creating sets of data and being able to reset the data becomes complex. It's hard to resist "cheating"
How can companies working with external Software Factories employ Agile and DevOps?
would like to hear more as to why the CICD team is not devops...they (my guys) seem to think they are...I don't know enough to tell them otherwise...
@colin827 we had both arms go through understanding what the “DevOps” mind set should be, and once they started showing a common understanding then we started to bring them together with feedback loops, inviting Dev to BPM and inviting Ops to Requirement gathering… seems to be working so far…
You need to find out what that companies SDLC is. Many times, you'll start with Water-Scrum-Fall. However, trying to Integrate the backlog and Product Demo's helps.
Being able to get the code (warts and all) at end of every sprint helps with tightening the "feedback" loop with the vendor
So if the SDLCs from the vendor and the internal team is in sync its possible to excel in the main DevOps KPIs? Any advice or specific Anti-patterns you have seen when using an external SW Factory?
@denver.martin - That's great. There's no easy answer - so finding something that works for you is great
Whenever I see the job advert proposing to "join our great DevOps team" - most of the time it's immediate "no"
Hey! (still very new to the devops industry) - but i'm interested in why you'd say that?
I believe that having the separate team called "DevOps" team has nothing to do with the DevOps methodology. It's like having the "Agile team". Or "TDD team". If the organisation spends money on something called "DevOps team" - chances are that I won't be enjoying working there.
@nickeggleston yes, it is a quite popular concept. As many people mentioned here - usually it is just a fancy name for the team that manages developer tools and/or PaaS/IaaS clusters.
What role titles are u seeing for those focused on the cultural/organization transformation in the wider sense of DevOps?
Very good question ^^^ I'm also interested what a true DevOps position would be called or entail.
@dkirkpatrick DevOps and Agile support each other, but I wouldn't call them different degrees of the same thing
@nick.kritsky Yes, it's a common problem - some teams are really product teams doing devops and doing great work, but it's becoming a defacto standard for tooling team
In the devOps line in slide 8, I think if the feedback loops were shown that would be the requirements/plan/design item.. it is the interconnected feedback that feeds that item, Feedback from Ops or feedback from sales or feedback from clients.
Last year at DOES I had a bunch of people ask me if I was a "DevOps Engineer." I never really knew how to respond other than to say, "I write code and ship it to production automatically. If the customers like it, we keep it."
@dkirkpatrick It's a bit more than that. There's a feedback loop from production (ie operations) back to development that isnt really discussed in Agile.
Ah, right. That makes sense. That wasn't necessarily visible in the diagram....
@timothy.haagenson798 that is a loaded question… I like to hire engineers that can think. in the DevOps mindset… track work in the 4 types of work, understand the 3 ways, working to improve daily work reduce unplanned work, and want a culture that frames the 5 Ideals…
We also need to recognize that these transformations are seldom org-wide initiative and much more likely to be in one business unit or group
Colin, what about environments where there is no immediate production, like with software that still ships on disks or has to go through various partners and vendors. you are doing the exact same work with the same people, but your "production" is the first step of the next process, but not production itself
@timothy.haagenson798 I see DevOps Engineer phrase in the job market trending to be more of the tooling person (ie installing, managing, maintaining Git, Jenkins, Nexus etc etc) and supporting dev teams using it.
I agree, and I have seen engineers apply that know the tools but do not understand the concepts or the culture of DevOps..
I think it's part of the techy personality to take cultural terms like DevOps and start tying them to technologies and tools (e.g. Git, Jenkins, etc)
@sean.wilson Its hard to do DevOps then as there's no tight feedback loop. Many times you're working on the next version or the 2nd version by the time it gets to production. In cases like that you probably have limited interaction with the Ops team.
Visit the https://doesvirtual.com/sonatype booth to download a copy of the 2020 State of the Software Supply Chain report Colin just referenced
@john.hoffler Yup. I love to talk about Source Code Mgmt; Artifact Mgmt; Build Mgmt etc etc, but sometimes you just cant help jump into the actual tools.
not really since we have to push to the next steps as IF it was production. so all the common flows can exist, but it is hard to finish the loop.
interesting...could you say that an SRE could incorporate devops?
great talk today @colin827, thoroughly enjoyed it
Welcome @t.girouard for our next session's Q&A! Please leave your questions and comments below here. Thank you also to #xpo-tricentis!
@colin827 I agree with that. SRE is just a specific implementation of DevOps principles
I would say the same thing about DevSecOps - a specific implementation of DevOps principles with a security focus
@colin827 what was the document you referred to regarding vulnerability management?
Thank you @colin827! - just one question i know you defined DevOps in the beginning but i'm still wondering what a true "DevOps team" would be to an organization. Someone has to facilitate the implementation... So, would the DevOps team be facilitators of the DevOps methodology rather than just the team that runs the CI/CD process or tooling integrations? :thinking_face:
I like to define the team that supports the teams pushing code to production (and creating the business value) as Developer Tooling team [although someone suggested SDLC Stack team]. The team running the DevOps methodology is the business facing team. I normally like to see the management of the Developer Tooling working with the Operations and Information Security to refine the devops process - and a sucessfuly framework around that is something like BSIMM which help sframe the security aspects of it
@nickeggleston I asked a similar question to what you were wondering in one of the earlier threads. Hope this helps.
is anyone using a product that can do testing across multiple release platforms/operating systems?
you can look into this that i used in the past : https://www.parasoft.com/products/parasoft-soatest/
@deanna.stanley Sonatype has a document that they produce yearly called the "State of DevOps Report". @weeks can send that to you or you can go to their website and register to get a copy. It's a great read
Hey Tim, how did you fully map application feature to automated test to ensure that you fully see the deltas? in some places you have no automated tests, in some cases you may have automated tests without knowing exactly (accurately) the mapping to the app features.
Hi Sean, I think this video will help explain it a bit: https://www.youtube.com/watch?v=Lr1_kEvY-aE&list=PL_mckFOFnjHmB5xgonrUlaICMFOR-fTyo&index=3&t=50s
@ali.zahor Thank you for this question! Our LiveCompare technology can detect changes in an SAP environment and we are working to extend this capability to other technologies. However, at this time, we have not yet extended it to Java and .Net environments.
Hi Everyone, Thanks so much for coming to listen to my talk on human in the loop automation. Please reach out of if you have any questions!
Welcome @tina for our next session's Q&A! Please leave your questions and comments below. Thank you also to #xpo-transposit!
an API is only as good as it's documentation :man-shrugging:
Agreed. But even at its best with great documentation, there can still be a ton of hurdles to jump through before you can access your data.
We are using ServiceNow for End-to-end automations and creating self-healing applications based on tickets. We have automated the Change tickets too.....
That's great. One of our observations in creating Transposit is that ServiceNow actually did a great job (especially given when it was created) around managing the communications and business processes. But then with the rise of agile and DevOps, we see the more developer side of the house not really having the same sort of tools for process and tracking. So we really want to bridge that gap.
Nice to see productized solutions to my personal behaviors and opinions as I clearly don’t scale as large as this might. (I see all of these issues in all of our client teams — I’m the monitoring team.) Very interesting possibilities…
@ffaatuai Thanks. Yes, one of the interesting pieces we find is that there is no single source of truth -- there's monitoring, paging and escalation, etc. And you will always need all these tools. So we really think integration is key to extending and capturing across the entire DevOps stack.
Thanks for engaging with us! Transposit has got some great happy hours planned for this week — we hope you’ll join us! • Today, 10/13, at 5:30 pm PDT learn the ins and outs of what makes a good Scotch with Sarah McKinney, sommelier and spirits expert from 3 Michelin star Napa restaurant The French Laundry. Join us for a chance to win a top shelf prize in our raffle. • Tomorrow, 10/14 at 5:30 pm PDT we’ll be joined by Fighter Pilot Anthony 'AB' Bourke. He’ll share nail-biting stories from 9/11 and speak about the power of post-mortems, followed by an "ask me anything" style Q&A. You’ll also get a chance to win a reserve pinot noir from AB’s winery in Russian River Valley.
These are so great @laurel that I shared them in the #happy-hour channel too! Thanks for all of your hard work!