The Agilist Network

Tales and Tips from Agile Software Projects

The Flop

Posted by kenhoward on October 5, 2010

When Manu Ginobli of the San Antonio Spurs flops backward onto the basketball court,  it may or may not have been the result of getting shoved by an opposing player.   Most likely not.   Ginobli is the king of the flop…a pejorative term describing a technique used to trick the referee into calling a foul on another player.   In the past, the referee played an impartial role of “observer” and “decider”.    When flopping occurs, the referee actually becomes one of the participants in the game itself.   Deceiving the ref is practiced by some players, while recognizing and avoiding deception is part of the role of the referee.

This practice isn’t unique to basketball.   When Derek Jeter of the New York Yankees complained of being hit by a pitch when playing Tampa Bay a couple weeks ago, the umpire let him take his base.    Jeter later admitted that he knew he hadn’t been it.  The slow motion high def instant replay had already confirmed this.  However, since Jeter knew that the umpire couldn’t know for sure, he took advantage of the opportunity to get  a free walk.   Jeter didn’t break any rules, he just cleverly took advantage of an opportunity to take a free base by deceiving the umpire.

…and don’t get me started on pro soccer…same song, third verse…

In business, politics is often a factor that can interfere with the progress of a project.   When a software developer builds what was requested during iteration planning, it can be frustrating if the resulting component is rejected by the product owner at the end of the iteration.   The rules of the game state that the product owner should have been engaged throughout the process, and that a last minute rejection could be avoided.   When rejection happens, finger pointing, blaming, complaining, and even name calling cold also occur…the software developer blaming the product owner for lack of participation, the product owner blaming the software developer for doing a poor job of understanding the requirement, etc..

Either side could choose to “flop” and draw attention to the other as the cause of the wrong or missed requirement.  If that happens, it just delays what’s needed: high bandwidth communication and collaboration.   Reconciliation of the problem won’t happen by assigning blame.  The best resolution is to do what could have been done to avoid the problem in the first place.   Hopefully through realization of the results of the resolution process, the parties will learn to play nicely together in future iterations.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: