Reddit Reddit reviews Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

We found 16 Reddit comments about Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. Here are the top ones, ranked by their Reddit score.

Business & Money
Books
Industries
Computers & Technology Industry
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations
Check price on Amazon

16 Reddit comments about Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations:

u/healydorf · 18 pointsr/cscareerquestions

> My boss is an understanding person and knows that we're stressed, but the larger organization seems uninterested in reorganizing to lessen our burden.

That's all you really need to know. You expressed a concern about the health of the team(s), and the broader org said "no, this is fine". They can live with all the benefits and consequences that come with that decision. All you need to know is whether or not you can live with all the benefits and consequences of that decision.

> Are most jobs like this?

I would say no, but practices that promote burnout aren't exactly uncommon -- toil is one example.

It's not uncommon for organizational practices/structures to foster high levels of burnout, but most orgs who give a shit will tend to fix those problems because turnover tends to be more expensive than simply fixing the problems that cause the turnover. Kinda sorta depends on the business's priorities, though. Showing the value of strategic investment in technical resources is ... difficult at times. I like the approach taken by Accelerate -- numbers and figures are what your manager needs to be focusing on, though it is hard to do when you're drowning already and engagement from leadership is low to non-existent anyway.

u/Dctcheng · 11 pointsr/devops

According to Accelerate https://www.amazon.co.uk/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

  • Lead time, the faster you get a feature out the better. Top companies do this in 1 hour
  • Deployment frequency, the more you deploy, the faster you can get features out and fix issues. Top companies do this on demand (several times a day)
  • Mean time to recovery, how fast you recover from downtime. Top companies do this in under an hour
  • Change rate failure, what feature when delivered is incomplete and requires more work. Top companies have a failure rate of ~10%
u/wouterla · 8 pointsr/softwaredevelopment
u/Euphoricus · 7 pointsr/programming

>I am unconvinced the report at ... really relates to high-quality software.

There are actually two stability metrics in the DevOps report. Mean time to recovery (MTTR) and Release Fail Rate. And while they are not something that people think of "quality" as a developer, I find it hard to believe that software of low internal quality could be released without massive pains. Both of which are lowest for high performers. When you listen to some talks by Jez Humble, who is one of the authors of the DevOps report, he says exactly what this article says. It is actually a core message of most of his talks.

Also, in the full book, they go into more details about actual technical practices and they find trunk-based development, developer-owned tests and refactoring correlates with high IT performance. And all of these practices are what Fowler and Humble associate with software quality. I really recommend reading the book, as the report is mostly condensed stuff for managers and executives to read between meetings.

u/OHotDawnThisIsMyJawn · 5 pointsr/devops

It's kind of dumb but there are two different "CD"s.

The first level is CI, which is committing code and having something that builds it automatically and runs all the tests.

The next level is CD (Continuous Delivery), which is a process that takes your successful integration builds and pushes them out to some set of environments (e.g. UAT or staging or whatever). From there you might have some set of additional tests that run, maybe load tests or integration tests with live external systems.

The third level is CD (Continuous Deployment), which is a process that takes your successful delivery builds and automatically pushes them to production.

In a true continuous deployment pipeline there's no gating step where people sign off on UAT (this doesn't mean there's no people involved anywhere, for example code review pre-merge is fine). You write your tests, you merge your changes, and if everything passes the changes just show up in production.

The part of your process that makes it not "true CD" is the human sign off in UAT.

That being said, TRUE AUTOMATED CD IS NOT RIGHT FOR ALL SITUATIONS! There are many business reasons that you might not want to or be able to apply a true continuous deployment model.

IMO the best book on this stuff that's out right now is https://www.amazon.com/gp/product/1942788339

u/cybernd · 4 pointsr/agile

Book recommendation: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

This book is not directly related to agile. But it is rather unique, because it is based on studies and not on authors subjective opinion. It tries to figure out, which mechanics are relevant for modern software development teams.

Most often our rituals are not based on evidence. They are originally based on convenience and afterwards kept up as dogma. Sadly the original introduction was often done by the wrong people.

For example agile was mostly invented by developers, but the widespread adoption of scrum was done by business people (managers as scrum master). As such a dogma was formed that may not be in the best interest of solid software engineering.

u/CaptainKabob · 3 pointsr/agile

That sounds tricky. I think you're starting with the right place: visualizing workflow;

A suggestion is that you focus on building trust by addressing pain points. What pains does the team have with the current process and can you concretely improve those in the short run (as opposed to abstractly saying "if we adopt this whole enchilada that will get better, trust me").

Another thing to focus on is measuring some of the health indicators in Accelerate. Honestly, you might be doing awesome already and the problem to be solved is recognizing and celebrating it. Good luck!

u/gooeyblob · 3 pointsr/sysadmin

Oh wow, great question! I've pondered this quite a bit and am currently reading up on two resources to deepen my understanding:

Stripe's Developer Coefficient report: https://stripe.com/files/reports/the-developer-coefficient.pdf

Accelerate: The Science of Lean Software and DevOps: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

It's kind of a wordy title for that book, but it's interesting to see what the authors deem to be the really key things for safely accelerating development velocity. We've addressed a lot of the things in the book via intuition over the years but I really would love for us to start being more methodical and process oriented in trying to improve things. I'd be interested to hear what you think!

I'd love to have some metric that represented how "sure" developers feel when they are developing new services/features and estimating timelines as well as how "sure" they are about deploying changes without having unplanned reverts and things of that nature.

u/slowfly1st · 3 pointsr/projectmanagement

Cannot recommend this book enough:

https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

​

Don't sell agile. Sell the value of it. Our company is over a hundred years old, far away from a startup, and lots of our teams follow agile principles. If we weren't better off, we wouldn't do it.

u/euclid223 · 2 pointsr/agile

Scuse my ignorance... What does OM mean? 😁 But yes, we're trying to optimise for overall flow of customer value. The other metrics account for "de-risk deployments by doing it a lot", "don't break production" and "if you do fix it quickly". These are not of our own design by the way... Completely plagiarised from https://www.amazon.co.uk/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

The overhead for measuring feature lead time is minimal thankfully. I put a label such 'value-marker-1' against the first and last stories in a Jira epic. A new valuable thing inside an epic just means I increment the number on the labels I use. Also means you can have measure multiple valuable things in an epic with overlapping timelines. My cronjob gathers this up daily along with a bunch of other metric information. I owe a detailed blog post to https://medium.com/onzo-tech by the end of March.

We're seeing a healthy tension across the route numbers and it looks hard to game one without sacrificing elsewhere. I am measuring deployment leadtime too but haven't set a target there as I can see it leading to bad behaviour. One thing I am currently wary of is the short term temptation to reduce technical quality in return for lower leadtime. It would eventually manifest in higher change failure rate and increasing lead times

u/JosephPratt · 1 pointr/devops

TL;DR Google "Cost of Delay", Puppet's 2016 State of DevOps Report page 43 for rework calculations, and compare %C/A improvement to increased %Innovation (%I).

This has been a major challenge opportunity for us. I would start by aligning the conversation to Agile Principle #1's three main tenants: Customer Satisfaction, Valuable Software, and Early and Continuous Delivery. If you are in a large (and old) IT organization such as mine, these tenants are loosely held to, barely understood, or simply dismissed. However, in order to measure the success of a digital transformation, these three things must be measured. For the sake of our VSM effort's MVP, we've focused on measuring Early and Continuous Delivery. (You can also discuss this in the context of the 3-ways of DevOps. Early and Continuous relates to the first way. Customer Satisfaction and Valuable Software are feedback loops of the second way. And getting us there is the third way.)

For our first pass at measuring Early and Continuous Delivery, we discussed how we could reduce total cost of change by reducing overall lead time (LT). A simple calc is team member count * hourly rate ($/hr) * 6 hrs/day * overall LT in days. You can get specific and do that calculation per value stream process block and add it up, or keep it high level and you'll be in the ballpark - off by 10-15% at the most. If you're working in hours, then you can adjust the formula by dropping the "6 hrs/day" part. (If you're working in minutes, you should just make the case for purchasing Google Nap Pods or something. =))

The problem with relating overall LT reduction to a cost of change reduction is it's not completely accurate unless the lead time and process time (PT) are the same. So LT = PT + QT. And unless we propose that queue time (QT) is spent doing nothing related to other value-add work (which would be tough to argue), then really the PT is the total cost of change. (I'd imagine we'd both agree that context switching has some non-value-add overhead, but how much? Maybe 10%?)

What we've found is that if we're talking about reducing overall LT the best measurement to catalyze the improvement conversation is to consider Cost of Delay (also check out here and here). You can show that by reducing overall lead time, we can capture the first-mover advantage, thus reducing or eliminating Cost of Delay. We are in a competitive capitalistic market after all. Our business measurements are relatively immature, so we used hypothetical numbers to demonstrate this. Obviously real numbers would be more impactful.

Next, consider %C/A. Rework (aka waste work) is potentially one of the biggest wastes of IT budget (and more importantly a development team's time) that a VSM can capture - a low %C/A is most certainly creating rework. Check out page 43 of Puppet's 2016 State of DevOps Report as it provides a simple calculation for rework cost. It may also be important for the group creating the VSM to perform RCA on a low %C/A process block as this may actually be the principle constraint of flow.

Moreover, a %C/A problem in Production has a direct impact on Customer Satisfaction. Framing improvement work with a risk-based mindset will inform you that solving a low %C/A problem in the Prod process block has a measurable impact on Customer Satisfaction. (Two before and after short surveys to your customers, internal or external, should show a diff in Customer Satisfaction if the %C/A in the Prod process block is improved.)

The last point is more of a qualitative measurement, and that is around %Time for Innovation (%I). I hope your organization doesn't devalue development teams as I have seen from time to time, but remember, development teams contain some of the most creative and capable women and men in the entire company. It's important that they move away from doing work a machine can do through automation and focus on innovative (aka creative) work. If you research HP's printer firmware transformation, you'll see that they related %C/A work (warranty) to %I. It makes sense that if the team is not doing rework, then they have time to focus on innovation. While this doesn't directly relate to Agile Principle #1, it will likely map to Customer Satisfaction and/or Valuable Software, since %I time can be spent doing A/B testing, spiking new and relevant technology, or simply interacting with customers directly thus gaining empathy for their jobs to be done.

I also highly recommend Accelerate: The Science of Lean Software and DevOps. The first part gets into some numbers and is essentially targeting middle management and up. It will give you some scientific foundations for some of these improvement conversations.

The business justification of VSM and improvement work is a big subject, and I'm still learning. Remember that finance is as much art as it is science. I hope this gives you some ideas!

u/ratfaced_manchild · 1 pointr/ExperiencedDevs

> How do you go about debugging this situation

A combination of monitoring dashboards (new relic, datadog, rollbar etc.) and looking at the codebase and recent releases to see what may be the problem, the solution is usually either a restart/rollback/fix-forward

> Are there system wide graphs that are viewed first before narrowing down to specific component or microservice?

Yes, these are critical. If you don't have monitoring in production, you're flying blind.

> what specific metrics would you evaluate, and how would you use those to go down to the component that has problem?

A combination of service availability (is service up? receiving requests?) and what I call "functional correctness" (is service doing what we expect? is the DB being filled with garbage data?)

> Is there an article or video talk that you can provide for me to dig deeper?

I suggest you start with this: https://www.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339

And like others have mentioned, do some google searches on "Software/Site Reliability Engineering"

Edit: one thing I forgot to mention, we are alerted to problems automatically, and this automation is critical, you need to set up your monitoring dashboards to alert when you start deviating from your baseline, like another comment said, if customers complaining is what's alerting you to a problem, then that's a monitoring and alerting gap that needs to be fixed!

Edit2: this alerting can happen through phone calls, slack messages, emails, etc.

u/livebeta · 1 pointr/cscareerquestions

Accelerate (book)


Planning methology

The 12 Factor App

Tooling: Go google for Continuous Delivery.

AWS Devops cert is not as useful as practical system design experience. Try other clouds as well, they are pretty good

u/brennanfee · 0 pointsr/linuxadmin

> If it's a pet that's not generating revenue

Sure, sometimes you have to make choices. As long as you are doing it with the full input and knowledge of your employer (or the client)... fine. The problem, to me, is there are a lot of "technologists" out there who think they know better and go forth and make decisions on behalf of their organizations without even a clue of how some of those decisions will impact, even destroy, a company (even small ones).

All too often we hear about some company getting hacked and all their passwords being leaked. While it is true that some companies cravenly tell their people "we don't have time for that" when it comes to basic security measures... but far more often it is lazy developers making choices without their employer knowing.

> and is fully backed up in multiple locations I wouldn't protest that much.

That is your saving grace right there. I did say, perhaps not in the comment I linked to you (forgive me), that having a snapshot or backup of the "special snowflake" can often be enough. It's not great for reproducing it but does give the ability to recover from failure and, mostly, that's enough. The real question is what is your MTTR?

> and more importantly price,

Well, I would argue that the company will always be better off financially going the DevOps route (and the data backs me up on that). But, still, as I said... sometimes choices have to be made.

https://www.youtube.com/watch?v=gsjCWrCUjNg

https://smile.amazon.com/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339


u/JanJansen2634 · -4 pointsr/webdev

Edit: Since this is getting heat here's an excerpt from a book covering research done on this:

>Trunk Based Development

>Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance. Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into trunk and never had "code freeze" or stabilization periods. It's worth re-emphasizing that these results are independent of team size, organization size, or industry.

>Even after finding that trunk-based development practices contribute to better software delivery performances some developers who are used to the "GitHub Flow" workflow remain skeptical. This workflow relies heavily on developing with branches and only periodically merging to trunk. We have heard, for example, that branching strategies are effective if development teams don't maintain branches for too long - and we agree that working on short lived branches that are merged into trunk at least daily is consistent with commonly accepted continuous integration practices.

>We conducted additional research and found that teams using branches that live a short amount of time (integration times less than a day) combined with short merging and integration periods (less than a day) do better in terms of software delivery performance than teams using longer-lived branches. Anecdotally, and based on our own experience, we hypothesize that this is because having multiple long-lived branches discourages both refactoring and intrateam communication. We should not, however, that Github Flow is suitable for open source projects whose contributors are not working on a project full time. In that situation, it makes sense for branches that part-time contributors are working on to live for longer periods of time without being merged.

The book if you want to check their methodology / biases