Agile vs Fragile: Retrospective Look Forward

Part 13 in a series of 17. To start at the beginning, first read Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos.

The last Agile principle is all about retrospectives. This is one area where a lot of teams have dropped the ball. They don’t take the time to do retrospectives because people don’t understand the value they bring. They are perceived as a waste of time that could be spent on the next development sprint.  What they fail to realize is that on a long marathon, it is the small corrections in the sprint execution that make the difference between success and failure.  True Agile teams take retrospectives seriously, and each and every team member is laser focused on improving sprint over sprint.

Fragile teams may do lesson learned sessions, but only because the Agile guide tells them they need to.  They aren’t taken seriously, and the results are rarely acted upon.  They become “blame game” sessions where everyone tries their best to ensure that failure of the sprint was not their fault, and that the sprint would have been successful if only the other team had done something differently.We have looked at the twelve principles of Agile teams and identified some of the characteristics of both Agile and Fragile teams as it relates to these principles.

One of the interesting things I have observed across Agile teams is that many of them either haven’t fully embraced Agile or have had bad experiences with Agile so they have decided to “modify” Agile to fit their organization.  One team in particular developed a hybrid model called Scr-Agile-Fall. It works like this.  User stories are prioritized into a backlog but there is a targeted released date for a cumulative list of specific user stories (meaning they’ll all be released together instead of individually). Sprints are then employed for the design, code, and unit test phases of development, but then an integrated system test is performed prior to the release of all the completed features for the “in-scope” user stories. It is waterfall planning and release schedules with agile/scrum design and development.  What these teams fail to realize is that the problem isn’t the methodology they choose, but the discipline they have in leveraging that methodology that determines their success.  When teams adopt a methodology, but don’t fully embrace the principles, it leads to unpredictable and inconsistent results.  It truly becomes Fragile.

In the next installment of the blog we will look at what Agile means for processes and documentation. In the meantime…Keep on testing!