Scaling Agile: Scrum of Scrums – Anti-patterns Part 2

Different sort of pyramid syndrome

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.

 

Beginning Agile: Obstacles to Effective Listening

Are you listening?

Listening is important for anyone involved in developing, enhancing and maintaining software. Teams that don’t listen well have difficulty identifying and refining needs and coordinating their work. With the demonstrated criticality of listening, organizations and teams should work  hard to facilitate improved listening.  Every development methodology and framework advanced has made great effort to improve communication, of which listening is a key component. However, significant obstacles to effective listening remain. For example:

 

Agile Acceptance Testing Anti-Patterns

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.

 

Scaling Agile: Scrum of Scrums – Anti-patterns Part 2

Different sort of pyramid syndrome

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.

 

Splitting Users Stories: More Anti-patterns

This hood is making an ineffective split of his face.

An anti-pattern is a typical response to a problem that is usually ineffective. There are numerous patterns for splitting user stories that are generally effective and there are an equal number that are generally ineffective. Splitting User Stories: When Things Go Wrong described some of the common anti-patterns such as waterfall splits, architectural splits, splitting with knowledge and keeping non-value remainders. Here are other equally problematic patterns for splitting user stories that I have observed since writing the original article:

1. Vendor splits. Vendor splits are splits that are made based on work assignment or reporting structure. Organizations might use personnel from one company to design a solution, another company to code and another to test functionality. Teams and stories are constructed based on organization the team’s members report to rather than a holistic view of the functionality. I recently observed a project that had split stories between on project management and control  and technical activities.  The rational was that since the technical component of the project had been outsourced the work should be put in separate stories so that it would be easy to track work that was the vendors responsibility to complete. Scrumban or Kanban is often a better choice in these scenarios than other lean/Agile techniques.
2. Generic personas splits. Splitting stories based on a generic persona or into stories where only a generic persona can be identified typically suggests that team members are unsure who really needs the functionality in the user story. Splitting stories without knowing who the story is trying to serve will make it difficult to hold the conversations needed to develop and deliver the value identified in the user story. Conversations are critical in the flesh out requirements and generating feedback in Agile projects.
3. Too thin splits. While rare, occasionally teams get obsessed by splitting user stories in to thinner and thinner slices. While I have often said that smaller stories are generally better there comes a time when to split further is not worth the time it will take to make the split. Team that get overly obsessed with splitting user stories into thinner and thinner slices generally will spend more time in planning and less in delivering. Each user story should apply INVEST as a criteria to ensure good splits. In addition to using INVEST, each team should adopt a sizing guideline that maximizes the team’s productivity/velocity. Guidelines of this type are reflection of the capacity of the team to a greater extend and the capacity of the organization to a lesser extent.

Splitting stories well can deliver huge benefits to the team and to the organization. Benefits include increased productivity and velocity, improved quality and higher morale. Splitting user stories badly delivers none of the value we would expect from the process and may even cause teams, stakeholders and whole organizations to develop a negative impression of Agile.

 

Reviews and Inspections: Anti-Patterns

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.