Learn how to adopt Azure DevOps Rules to control your DevOps processes such as locking down Work Items after they are closed.
Not only do high-velocity organizations get better at what they do, they get better at getting better at what they do. This scales so that no one can keep up with them. After all, most companies hire from the same pool of talent, they use the same software practices such as Agile/Scrum, they use the same tools, and so on.
Beyond Lean, another important contributor to DevOps is the safety science movement. In this blog, Ron discusses this subject and show how important this is and how it changes the ways we think of the systems we build.
Accessibility improves usability; considering accessibility reviews early-on and at all stages gives us an opportunity to not only save cycles of design, dev, and QA, but more importantly, it creates a more usable product for everyone.
We need to regularly update our Mental Models but more importantly we need to find better means to update our Mental Models if we are serious about enabling a better culture which enables more innovation and happier individuals in our organization.
What is DevOps? This is a question that I find challenging to answer and the more I study the subject the more difficult it is to define the term. One way to think of DevOps is by applying the notion of Complex Adaptive Systems.
The very notion of economies of scale arose during the early industrial age but unfortunately is still prevalent in many industries, including software development. However, that has changed with DevOps but it still isn’t obvious otherwise I would not come across customers that still work in this paradigm.
Unfortunately, many enterprises have multiple organizations and projects in their portfolio and merging them into a single project can seem a daunting task. While there are tools out there that can help, there is no “Single Tool To Rule Them All”.
if you want to change something, never immediately assume that current conditions are immutable. If you’ve never discussed the possibility to change, you cannot know whether others – your partners, customers, teammates, or managers – would resist, or the reverse – enthusiastically gush and support the change.
How do you deal with the fact that the developers in your organization cannot or will not own the process of delivering into production? How do you deal with the fact that your operations engineers cannot or do not fully understand the software to which they have been given stewardship?