A Scrum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams. Powerful tools often have side effects that, if not countered, can do more harm than good. There are several “anti-patterns” that organizations adopt that negatively impact the value a SoS can deliver. In Scaling Agile: Scrum of Scrums: Anti-patterns Part 1 we explored The Soapbox, The Blame Game and Surrogate Project Manager, which three typical anti-patterns. Two other common anti-patterns are the Three Bears and Pyramid syndromes. (more…)
November 10, 2016
Scaling Agile: Scrum of Scrums – Anti-patterns Part 2
Posted by tcagley under Agile at Scale | Tags: Agile, Anti-patterns, Scrum of Scrums, SoS, Teams |Leave a Comment
January 19, 2016
Agile Acceptance Testing Anti-Patterns
Posted by tcagley under Agile, Testing | Tags: Agile, Agile User Acceptance Testing, Anti-patterns, Testing |Leave a Comment

Don’t just throw it over the wall.
A user acceptance test (AUAT) is a process that confirms that what is produced meets the business needs and requirements. User acceptance testing is a form of validation done by executing the product. For a software product, UAT is performed by executing the code in the user’s environment and comparing the outcome to the users needs. In the classic V-model of testing, acceptance testing is the final proof that the requirements have been transformed into functional code. Agile frameworks have incorporated the steps for acceptance testing numerous ways. Not all of the patterns that have been adopted for Agile User Acceptance Testing (AUAT) are effective, and in some cases they are anti-effective. (more…)
July 9, 2015
Scaling Agile: Scrum of Scrums – Anti-patterns Part 2
Posted by tcagley under Agile at Scale | Tags: Agile, Anti-patterns, Scrum, Scrum of Scrums, SoS |Leave a Comment
A Scrum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams. Powerful tools often have side effects that, if not countered, can do more harm than good. There are several “anti-patterns” that organizations adopt that negatively impact the value a SoS can deliver. In Scaling Agile: Scrum of Scrums: Anti-patterns Part 1 we explored The Soapbox, The Blame Game and Surrogate Project Manager, which three typical anti-patterns. Two other common anti-patterns are the Three Bears and Pyramid syndromes. (more…)
April 25, 2014
Reviews and Inspections: Anti-Patterns
Posted by tcagley under Process Improvement, Reviews and Inspections | Tags: Anti-patterns, Inspections, Reviews |[4] Comments
Reviews and inspections are powerful tools that can deliver a great deal of value, if they are done correctly. Like all powerful tools, if you use them incorrectly the results will not be as expected. There are several typical anti-patterns that can effect reviews and inspections. The top six are:
- Finding Fault: Reviews and inspections remove defects and provide the basis for teachable moments. Finding fault or assigning blame for the defects found during or in a review will generate an adversarial environment that incents the person whose deliverable is being reviewed to hide defects or to strenuously debate whether anything is actually a defect. Neither outcome promotes the goals of the review process. Note: not finding fault does not mean that leaders and managers should not correct problems or not to get people help when they need it.
- Lack of Preparation: Most reviews and inspections require preparation. Preparing ensures that the time spent doing a review or inspection is focused on removing defects rather than reading the deliverable in a group setting. When teams or organizations begin to forego preparing for reviews, they instead spend inordinate amounts of time in review meetings doing the preparation together and then doing the review. This approach is highly inefficient and because we all tend multitask, our attention span will tend to wander during long meetings, which reduces effectiveness. I have also observed that as review duration increases, participation decreases.
- Combining Reviews and Approval Events: Combining reviews and inspections with approval events generally shifts the focus of the process from defect removal to getting approval to progress (sometimes called sign off). Making a good review or inspection into a hurdle for approval incents the author and his or her allies to hide, downplay or generally spin any potential defects so that the project can keep moving. Going down this path will insure less defects are found, not that less defects exist.
- Manager Involvement: It is a rare team in which the person that controls (or strongly influences) team member’s salary or promotion opportunities is truly a peer of those on the team doing the work. Involving managers in reviews and inspections will tend to increase the level of defect hiding, posturing and just plain brown-nosing. None of these behaviors are conductive to efficiently and effectively finding and removing defects. Reviews and inspections work best in an environment where sharing and accepting feedback is not dangerous to one’s career.
- Nothing To Compare With: Reviewing any deliverable against nothing or just reviewers experience is generally ineffective and tends to spin down into discussions or debates based on opinions. Reviews are most effective when the deliverable being reviews is compared to something everyone can reference. Team, organizational and/or industrial standards, architectural frameworks or even previous deliverables are all useful to compare against in a review or inspection.
- Not Enough Time: The requirement to do a review or inspection without enough time to do it right defeats the reason for doing reviews. I can’t count the number of times I have heard teams rushing thought a review say, “well this is better than nothing.” Well, perhaps it really isn’t better than nothing. At the very best, a rushed review will leave defects in deliverables that will need to be removed later or that your customers will get to find for you. Even worse, short cutting the time needed to do reviews correctly sends a message that we only pretend to believe in the processes we use and the IT really doesn’t know what they are doing. The consequences in the long run are usually a change in management or outsourcing.
If you recognize any of these anti-patterns, fix the problem. If you need help making the point get a coach or consultant to help you. Organizationally, if you can’t correct these anti-patterns, stop using reviews and inspections and do something else, such as hiring lots of extra independent testers. Doing reviews and inspections poorly is not doing you any favors.