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!
Did you enjoy this article? Help spread the word by sharing:
Engage in the conversation and leave a comment:
About Brian Copeland (19 articles)
With over 25 years of senior level experience in the software development industry specializing in organizational transformation and development, Brian has been instrumental in the testing of critical business systems, from mission critical applications to commercial software. Mr. Copeland’s career has included 10 years as the Test Operations Manager for the Titan II, 34D, IVA, and IVB programs, managing both flight and ground software-testing facilities for Lockheed Martin. Mr. Copeland also served as the Sr. Manager of Quality Assurance for the shared services of Deloitte & Touché, LLP. His diverse experiences range across the aerospace, medical device, title insurance, legal services software, big four accounting firm, and banking industries. Brian led the global testing organization for The Nielsen Company, overseeing the successful transformation of the testing function made up of over 750 testing associates. Mr. Copeland has been a key-note speaker at the International Business Forum, and has been a featured speaker at HP Software Universe. Brian is a past president of the greater Cincinnati International Institute of Business Analysts (IIBA), and holds an ITIL v3.0 Foundations and RCV certifications.