| Follow @wpschaub
Vancouver, Canada
Since mid-’80s, I have been striving for simplicity and maintainability in software engineering. As a software engineer, I analyse, design, develop, test, and support software solutions. I am passionate about continuous innovation and to share learnings from the digital transformation, by Microsoft and the ALM | DevOps Rangers, to a DevOps culture to adapt people, process, and products to continuously deliver value to our end users. You can follow me on www.linkedin.com/in/wpschaub, https://willys-cave.ghost.io, https://twitter.com/wpschaub, and https://www.agents-of-chaos.org.
Authored Comments
Thank you for the great feedback. As I eluded to in the example, you typically rely on a combination of fault handling strategies, such as retry and circuit breaker to fine tune the system. Good point on instrumentation, which feeds the invaluable feedback loop to help within pro-active monitoring and root-cause analysis.
Good point - many root causes of "fear to fail" are fixed deadlines and expectations, especially in an organization that is going through an Agile transformation bottom-up. I have witnessed many sprint planning sessions that start with the product owner presenting a roadmap with milestones and list of features expected for each milestone. The line of autonomy is often breached, when product owner influences the team on HOW and WHEN to deliver features - as a result, the team becomes focused on milestones, instead of quality and continuous improvements.
As discussed in other articles, most of the transformation journey challenges are based on the people, the organization's culture, and a misalignment of expectations.