Part 12 in a series of 17. To start at the beginning, first read Agile vs Fragile: A Disciplined Approach or an Excuse for Chaos.
Agile principle eleven deals with the team itself. This principle focuses on the enablement of the team to leverage their unique position as the closest people to the problem manage the work. It also enables the team to safely take risks. The team is typically creating new solutions, and doing it in a rapid fashion. Agile promotes the team trying new things without worrying about being chastised for wasting project time. Teams are encouraged to learn from their mistakes to improve future sprints, and improve the overall delivery. One of the biggest indicators that a team might be Fragile is that leadership still insists on reviewing and approving the project plans, and changing direction. This is NOT a characteristic of an Agile team. This is the characteristic of a leadership team that has not empowered the team to be successful.Another characteristic of a Fragile team is the continued insistence on maintaining very formal boundaries between project roles. I am not saying that there should only be developers who do everything, but what I am saying is that testers can no longer afford to sit back in their testing role and not participate in any of the traditional development activities. Testers need to jump in and help across boundaries, just as developers should be helping testers. This isn’t to say that developers are equivalent to testers and can replace them, because if that were true there wouldn’t be any defects in the first place as the developers would have adequately tested their own work. What I am saying is that breaking down the barriers means that developers may help set up test data or run automation, and testers may help set up production data and help train support. Proper Agile promotes an environment where the team sees that they are all in it together with a common purpose and goal.
In the next installment of the blog we will talk about the 12th Agile principle. 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.