Successfully delivering valuable functionality in the first sprint or three can be difficult, and for some, simply impossible. But the lessons learned from the attempt are invaluable! Taking an early hit, failing in the short term is unimportant if it improves the chance of success in the long run.
Asking these questions during sprint planning is a great way to start a conversation that will both achieve the principles of collaboration and engagement, and ensure a greater understanding of the value that the product is expected to deliver to its users.
GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.
The DevOps Handbook describes the aspects of working toward a satisfying result for a customer while handling apparently conflicting goals within the organization. The book explains through case studies how companies have resolved the apparent contradictions, aligning everyone’s goals can bring about greater rewards and process improvements.
We all know that automated testing is a key component of a successful DevOps practice. However, it’s also common for organizations to underestimate the change effort required to create a complete testing strategy. In this blog post we are going to demonstrate the advantages of creating a clear automated testing strategy, in three simple steps
Over the years, I have coached and researched dozens of scrum teams to adapt to “real world” scenarios. Some may call them anti-patterns or some may call them “not scrum”-- but that is okay too because sometimes we have to work with what we have and still find ways to be successful.
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.
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?
At this point we were five plus years into a local transformation that was underappreciated and overlooked by the global IT organization. The frustration was high and the hope was waning. For me this became my motivation to start a journey to understand why some organization can adopt DevOps strategies successfully and other struggle.
