Agile suggest that teams should fail-fast to enable quick learning from mistakes. Learning from failure is one approach, you can also learn early and fast from successes, by doing experimentation, or by using a plan for knowledge acquisition.
Doug Barth, from PagerDuty, talked at DevOps Days London about their approach to start resiliency testing their systems without dedicating a lot of automation effort upfront. The goal was to quickly start learning about failure points and openly discuss how to fix them with only one hour per week of effort.
The lean startup is about fast delivery of desired products to customers, and increasing your understanding about the needs of customers. With the lean startup, people can learn faster from failures and become better innovators. There are teachers that use a lean startup based approach in education, which helps their students to learn faster.
Another AWS outage hit several large websites and their services last week. What can be done to avoid downtime? Architect for failover not just for scale.
Agile adoption and transformation is sometimes effective, and sometimes not. Is there a common thread to the failures? Does fear have anything to do with it? And what can we expect if we start an agile adoption initiative in an environment that is full of fear?
Usually failures result in anger, frustration and playing the blame game. However, failures are wasted if there is no learning from them. How can Agile teams make failures beautiful?
Philippe Kruchten described the Agile movement as "The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms..." and shared a list of twenty elephants in the room - uncomfortable issues that are ignored on purpose. The first of these unmentionables is that commercial interests are censoring failures.
Amazon has published a detailed report on the service failure plaguing one availability zone in the US East Region. The online media is full with analysis, commentaries and lessons to be learned from the event.
On December 22nd, 1600 GMT, the Skype services started to become unavailable, in the beginning for a small part of the users, then for more and more, until the network was down for about 24 hours. A week later, Lars Rabbe, CIO at Skype, explained what happened in a post-mortem analysis of the outage.
Multiple reasons can be quoted for the failure of software projects. Some projects fail because of bad requirements, others due to cost and schedule overrun and few simply due to bad management. If we do a root cause analysis, would all of the failed projects lead to bad code as the main culprit? Always?
The Google Apps Marketplace allows providers to create applications that integrate with Google Apps. The idea is to allow companies to integrate their own applications with Google’s applications serving some 2 million organizations totaling over 25 million individuals. Google also promises zero data loss and instant failover for Google Apps customers.
In response to a question about the Inherit Shortcomings of Scrum/Agile - Uncle Bob Martin penned (in the spirit of Martin Luther), 7 theses: No Technical Practices, 30 Day Sprints are too long, Scrum Master sometimes turns into Project Manager, Scrum carries an anti-management undercurrent, and others.
In this presentation filmed during Agile 2008, Henrik Kniberg talks about 10 possible reasons to fail while doing Scrum and XP. Maybe the team does not have a definition of what Done means to them, or they don't know what their velocity is, or they don't hold retrospectives.
In this presentation filmed during Agile 2008, David Douglas and Robin Dymond discuss about companies which try to adopt Agile, but don't go all the way, resulting in failure and rejection of it, and predictably having a negative impact on Agile's future.