Getting started with Slack for developer teams | Slack Frontiers

hi there brian mazaferi here senior solution engineer at slack and today i want to share with you how slack drives value for hundreds of thousands of developers around the world i want to start by talking about tools i don't know if you are a home improvement buff but i most decidedly am not i literally don't have a toolbox it's hard for me to even admit this but there was a time in my life where i didn't own a hammer i did however own a screwdriver so when i would need to hang up a picture on the wall i would use the tool i had and try and bash a nail into the wall with the handle of my screwdriver and you know what it got the job done of course it took longer sometimes i slipped and hurt my hand once i even bashed a hole in the wall when i totally missed the nail and eventually i literally broke my screwdriver so what's the point here well when i broke my screwdriver i finally ran out to the store and bought a hammer and even though i'm still not a super handy guy it's made all the difference to have the right tool for the right job and you know what the exact same thing applies to software development when you provide your engineers with the right tools you get a more engaged team working at a much faster pace earlier this year mckinsey studied hundreds of businesses to find out what conditions lead to higher developer velocity and they identified tools as having the single greatest impact because the right tools remove friction increase innovation and empower developers to do their best work plus improvements to developer velocity are paying off in business outcomes in this same study companies who are in the top quartile and most importantly top quartile meaning the top 25 on developer velocity are also 55 percent more innovative than the bottom quartile and most importantly they achieve 5x performance compared to their peers in the market so it's not just velocity for its own sake velocity is what leads to better business outcomes let's dive into some data here now this comes from the 2019 state of devops report from dora and it shows us that not only is this trend holding strong it's actually increasing so for instance when it comes to code deployments per year you can see that in 2017 companies in their elite performer category did an average of 322 deployments per year by 2019 that number increased to 1460 deployments per year that's an average of four deployments per day meanwhile the low performer companies did an average of seven deploys per year which is basically one deploy every two months and we can see the same accelerating trend reflected on the other side of the coin when we look at hours to resolve incidents the elite performers in 2017 took an average of 96 hours to resolve any given incident by 2019 that had dropped to an average of just a single hour in contrast the low performers take an average of over 2 000 hours literally months as you can see this holds true for change failure rates as well indicating that this increasing velocity doesn't come at the cost of code quality quite the opposite in fact by 2019 the elite performer companies were seven times less likely to have their changes fail meaning introducing code into production that degrades performance and requires a hot fix or a rollback but again while these metrics are striking the true cost is in the way they flow through to business outcomes these elite performer companies end up with 60 higher revenue and profit growth they're 2.4 times more likely to be growing at faster than 20 annually and importantly their engineers are 50 percent less likely to report burnout so what does one of these elite performer companies look like the key metrics to look out for according to that recent industry report from dora are multiple daily deploys less than 24 hours lead time for changes less than an hour to restore major incidents and a change failure rate under 15 now having identified these benchmarks what's the problem in 2020 there are more developer automation tools available than ever before so why aren't all software development shops making their way into that elite performer category well believe it or not that proliferation of tools can actually lead to huge challenges in information visibility and create operational silos between different teams and different parts of the pipeline if you're communicating in email or irc making all your decisions in meetings and web conferences and getting all your alerts and scattered tools you don't have the single pane of glass you need to keep everyone on the same page and orchestrate all of your tools into a well-oiled machine this is where slack comes in both on the front end helping you ship quality code faster and on the back end improving your service reliability when incidents do happen as they inevitably do let's start by looking at how slack helps developer teams ship quality code faster without slack developers lack visibility and context across the development process the force to switch between tools throughout rather than having that single pane of glass a single place to review rfcs do code reviews test and q a deploy and monitor the production environment every dev has their own partial view and notifying the right people to take the right action at the right time for example reviewing a pr performing qa relies on manual processes or keeping user groups up to date and since notifications live in email or the dev tools themselves they're often missed or not seen immediately slowing down the process leaving teams waiting and frustrating the engineers themselves all of this adds to a slower and riskier software development process with more potential for engineer burnout once an organization adopts slack however we see significant improvements in all of those areas it becomes far easier to align planning increase visibility and automation around cicd processes leading to increased developer productivity and to get that single pane of glass connecting all of the various developer tools which minimizes context switching and leads to faster catching of problems but what does all this look like in practice here i've got an example of a slack channel called project phoenix for the developers working on this project this channel becomes that single pane of glass not only is this the place where conversations and stand-ups can occur preserving those discussions and decisions and making them visible it also integrates with all of the tools the team is using as we can see here with the jira and confluence toolset from atlassian and as we can see from nikki's comment there these are exactly the type of interactions that might lead to wasted work and slower velocity which she has now avoided because of this increased visibility of slack now let's take a look at this channel in action say i'm working on project phoenix and a bunch of changes have just come down to the requirements for the login functionality in the past i might have had to reach out to all the team members via email or irc to figure out what they were working on or else jump into one of the many tools that the team is using taking me extra time and effort to try and sift through to find what i need but now because we're all working in a slack channel i can easily review and even use command f to do a contextual search of everything in this channel specifically now why don't i search for just messages that have the word login this is an incredibly powerful thing to have a single searchable pane of glass that connects all of the relevant people data and systems into one place for instance i can see that my first result here is from the confluence space where we're tracking the login flow documentation and not only have i found it but i can take the right action right from here these bi-directional integrations are key to slack's value in this entire process not only am i seeing notifications but i can action on those notifications without switching context and diving into a whole different system there we go this will need to change due to new login requirements so i've added my comment to the right confluence space right from slack and of course the channel is also notified about this new comment plus if i do ever need to dive into confluence i've got a deep link to do so right in every message and here in confluence i can see the comment that i just added but what if i need to get to work on this right away well i can see here that nikki is actually working on this jira story right now before slack we might have kept working on the same thing until we realized our mistake slowing us down and creating duplicative work but now because of the power of these bi-directional integrations not only can i see that she's working on it but i can take action potentially assigning the story over to myself and ultimately when i finish i can even close it out right from here by transitioning the story to done this way we're all on the same page and moving in the same direction increasing our team's developer velocity so we've just looked at an example using the atlassian toolset but i want to be clear with over 2 400 apps in slack's app directory this same story could be told with totally different development pipelines for instance over here in the project unicorn channel they're using azure devops and getting those same benefits that come from slack's single pane of glass and this same philosophy extends from development through deployment as well with slack integrations tools like github jenkins and literally thousands more we've seen here how teams are getting a ton of value from the visibility and actionability provided by slack but there's another element to how these elite performer organizations are able to do multiple deploys every day while still keeping their change failure rate well below 15 without slack the challenge many teams face is that their deployment process is often tens or even hundreds of steps across a bevy of different automation tools source control artifact repos database migration tools cid ci cd servers and more in an effort to reduce errors these processes are often painstakingly documented and deploys are only done periodically and at off hours while code changes pile up awaiting deployment but these elite performers have found that slack is the perfect tool to orchestrate this process making the entire thing seamless and transparent reducing errors and increasing velocity say i have a pull request ready for project phoenix i can now use a custom slack app we've called devbot to run the entire deployment process for me right here in the deployments channel so i'll go ahead and say devbot deploy phoenix now instead of following a painstaking process and logging into multiple tools devbot is going to do all of that for me via api and let me know anytime my interaction is truly needed so i'm ready to deploy and i can see i need to choose my pr it's giving me choices of only the prs that have gone through code review and been approved again putting checks and balances into this process and after a few more steps it's going to go ahead and give me my diff to double check i've just changed that one file which looks right to me and from here devbot has automated the entire painstaking manual process even letting me know now that our ci cd tool circle ci is in the process of doing the build of course if i do need to punch out to any one of these tools i've got hotlinks to do so right here in the slack message and in addition i can look back on this channel and see anybody else who's done deploys if i need to understand what happened previously or if something goes wrong i can go back and check on that meanwhile my circle ci build is almost done and my code is just about ready to push to qa now things have gone well so far but before i deploy to production i should likely have my qa engineer actually take a look at this again this is where the benefit of working right in slack comes in i can use reply and thread and because i'm threading off the slack message my qa engineer butch will have all the information he needs know exactly what he should be testing and where and it seems like he's already on it so again he's able to leverage these deep links that are in the message to know exactly what he should be testing check it out on the right qa server and look at that it looks like it's working great so now i'm ready to deploy to production plus i can see a couple of important things have happened here there's no worry about people stepping on each other's toes because everyone can see what's currently being deployed for instance chris here has some code ready to deploy and he's dropped a message in channel to let everyone know that he'll be deploying next this also applies historically again if we have an issue with some deployed code it's incredibly easy to scroll back through this channel and see who deployed what when i should point out this is based on a real life example the company that built this bot used to have a deployment process that took a full day and they limited themselves to doing deploys once per week to minimize the chance of something going wrong however once they built this custom slack app they were able to up their velocity by a factor of 25 going from an average of four deploys per month to an average of 100 now that is a massive improvement in developer velocity and this is what we see again and again slack ties together your entire development stack whether it's through our thousands of pre-built apps in our app directory or through custom apps tailored to your exact pipeline slack provides that single pane of glass to drive development forward in fact in the recently released total economic impact report from forester the analysts found companies that use slack see an average 16 increase in developer productivity 18 increase in build speed 17 reduction in testing time and 19 reduction in defects and here's a specific example of one of those customers seeing massive benefits from using slack for their development teams if you're not familiar with cvent 80 of fortune 100 companies along with more than 27 000 other global organizations rely on cvent software to plan market and execute their events cvent site reliability engineers developed release bot a custom slack app that allows developers to launch new releases from within slack just like we saw in the demo c-vent cto and co-founder david quatroni sums up the impact like this releasebot allows us in real time to make sure teams across time zones and offices are communicating correctly and aren't doing anything that's going to impact our customers in a negative way as you can see cvent is now in that elite performer category deploying hundreds of times per month let's move on now to the other side of the coin once you've got deploys happening multiple times per day how can you improve service reliability so that even major incidents can be resolved in less than an hour first let's explore just what is so challenging about outages and incidents incidents are chaos and traditionally they're handled via a phone bridge or zoom call supported by email and instant messaging tools let's say you have a sev1 incident and your app or service goes down for a significant portion of your customers what do you do you probably have an alerting tool like pagerduty that pages and emails a bunch of engineers they jump on a phone bridge or a zoom call to share information in real time and that's fine except every time someone new joins they're starting from scratch no context no detail no understanding of what's already been done or decided upon so every time someone new joins the conversation has to stop to bring this person up to speed this not only disrupts the conversations it slows down the response then as the team works through their investigations they may default to sharing progress through a combination of irc or chat tools and email further fragmenting the incident response and creating silos of information that don't always make their way back to the group as a whole the most important part of responding to an incident is mitigation getting the product or service working again the second most important part carrying out a postmortem to make sure the incident doesn't reoccur and that your team continually improves on their incident response how does that work with a phone call or resume you could have someone trying to take notes in real time but details are inevitably missed you can g chat back and forth but no one will have a single source of truth or you could make some poor soul dig through a trans transcript later on the lack of a single historical record for each incident makes postmortems harder and ensures that you'll only see part of the story when reviewing later on slack turns this entire paradigm on its head by spinning up a dedicated slack channel for each incident responders can join with the context they need not having to slow anyone down to get them up to speed investigations happen in a single centralized place with full visibility for everyone and incident reviews are made easy by the organic historical record generated by the channel here we can see an example of an incident channel again we're leveraging the thousands of integrations available on the app directory for tools like pagerduty and servicenow and we still have our zoom bridge but the difference is that it's no longer the source of truth and instead just becomes another method of communication while everything concrete is occurring in the channel now let's take a look at what this looks like in slack i can see here that a new servicenow ticket was recently logged saying that we've got multiple reports of customers unable to access our web app now this is a big problem since they can't load our service at all and it certainly qualifies as a sev1 incident for us so right here i can use those bidirectional integrations again to work with the servicenow ticket and slack is already acting as my single pane of glass but it quickly becomes apparent that it's time to declare an incident now instead of frantically emailing texting or iming people i can create a dedicated slack channel for this incident and even escalate it to make sure that our server team knows we have a sev1 going on plus i can see that automated alerts have gone out to the slack channels for the affected account and to a general incident summary channel so that the broader company can be kept up to date on what's happening without slowing down the resolution of the incident itself if i click into the actual incident channel i can see that a zoom has been spun up and folks are already hard at work trying to resolve it again because we're working in a slack channel these pager duty alerts that may be looping in new team members won't cause everyone to slow down instead new folks can get right up to speed and get contributing fast we can see people actively collaborating on this incident and we can even use functional reactions to indicate workflow and to note specific posts that need to be referenced in our postmortem later on saving time and ensuring we don't miss out on important learnings that can help us avoid these types of incidents in the future none of this is possible working primarily on a phone bridge so it looks like our incident is under control that's great news i'll hit our resolve button here which will tie things off for us now that the incident is done we've got this channel as an incredibly valuable historical record for later reference we can also use it to generate our root cause analysis and to do our post mortem plus because we're working in slack everyone that needs this resolution can be alerted in the proper channels i can see our incident summary channel here has the root cause analysis and the all clear and our accounts fairfield channel has been alerted as well since their account was one of the main ones affected by this incident at all levels the right information is getting into the right hands faster easier and more transparent just like we saw with development by tying together your incident management tool set through both our thousands of pre-built apps and the ability to custom tailor your own processes slap drives organizations into that elite performer category fact in that recent total economic impact study from forester managing incidents with slack led to an average 17 reduction in time to detect incidents and a 19 reduction in time to resolve incidents but let's give even more concrete with these numbers because incidents can be incredibly costly according to gartner the average cost of a minute of downtime is five thousand dollars say you currently have a hundred minutes of downtime per year if you could speed up your resolution by 75 using slack you'd save 375 000 per year and these numbers aren't just made up vodafone is one of the world's largest telecom providers and to monitor and escalate customer facing events their team relies on the pager duty integration for slack when an incident occurs in a production environment the integration notifies the right team down to the right individual within milliseconds all within slack they then run their incident response within slack and by doing so have been able to reduce their mean time to resolution from 20 minutes to less than five plus their executives have been thrilled at the visibility provided by working incidents in slack and they've been able to funnel learnings back into product development creating a better product faster so we've seen how slack can help you improve service reliability and ship code faster and when you succeed in those areas you'll also notice a third key outcome a productive and engaged developer workforce every engineering organization we talk to says this is one of their top concerns the relentless squeeze on top technical talent how do they recruit the best talent for their org and keep their current employees happy well a recent mckinsey study shows that developer satisfaction and retention rates are 47 higher for companies that give their devs access to relevant tools for each stage of the software development life cycle going back to my home improvement analogy say you're choosing between working for two companies one of which will give you a hammer and one of which will make you pound nails with a screwdriver even if it hurts your hands and slows you down which job would you choose not to mention developers love using slack slack isn't a silver bullet for talent but it's part of the equation in fact a huge portion of our business has come from grassroots adoption from the developers within a company plus developers love using slack and according to the 2020 stack overflow developer survey slack was second only to github as the most widely used tool amongst developers and it's easy to see why the outcomes that slack promotes are a key part of what pushes organizations into the elite performer category and as we saw those elite performers accrue outsized benefits like that 60 higher revenue and profit growth and lower developer burnout and turnover using the right tools makes all the difference and for many thousands of customers across the globe slack is the right tool for quickly resolving incidents shipping code faster and keeping your talent happy when you adopt slack you'll be joining thousands of other companies who have not only transformed their dev operations but the culture and results of their entire organization if you want to get started today it's incredibly easy to do so browse our app directory and check out the thousands of pre-built apps or check out our developer tutorials at api.slack.com to see just how straightforward it is to build custom slack apps and tailor your slack to your exact processes and pipeline last but not least thank you thank you for taking the time today to learn about how slack drives value for developer teams across the globe i've had a lot of fun here and i hope you have as well have a great rest of your day

Channel: Slack

Views: 955

Keywords:

Id: sPlNMzHDB4E

Length: 25min 25sec (1525 seconds)

Published: Tue Jul 20 2021