|
Most managers acknowledge that having team members agree on unified goals is
essential to productivity and success. However, achieving consensus as to the
best methodology for reaching those goals can present a real challenge for even
the most experienced professionals. Read on to learn what the experts in the
field of group processes have to say about the dynamics of teamwork and see how
this knowledge can impact your CM environment/practices.
Many professionals in the behavioral sciences (e.g. Industrial/Organizational and School Psychology) apply their understanding of learning and motivation to work environments in order to maximize productivity. These practitioners are frequently called upon to help solve behavioral problems in order to optimize the performance of both individuals and teams. Although Deming, the father of Quality Management, insisted that rallying individual employees with esteem-enhancing slogans is counterproductive (and arousing frustration and resentment in some), other behavior scientists have actually found that combining positive statements with tangible rewards does lead to improved performance. The real fun begins when one has to inspire colleagues to "play nicely" together in situations when the interests and objectives of one person may, at times. conflict with another member of that group or a different group with which they interface regularly. Such scenarios are commonplace in the world of CM as the various development and testing teams continuously interact throughout the software development process. This dynamic is also common to the one social grouping to which everyone belongs; the family. Every person has had first-hand experience living with others who have very different personalities, tastes, etc. Many times, the individual group members (especially siblings) may have had conflicting interests and/or goals, re: resource allocation, or other issues. Yet, the managers (aka the parents) repeat the mantra that "we are a family" to emphasize that the whole is greater than the sum of the parts. In well functioning families, each child is recognized first for their uniqueness and inherent worth, but also for how they utilize their gifts to enhance the family as a distinct entity. By repeatedly reinforcing the message that individual success is dependent upon group synergy and mutual support, parents provide the first example of effective teamwork. This core understanding of the benefits of positive interdependence is a latent social skill available to most which successful managers try to promote in their employees, as well. Now, back to the business world: Let's begin with the overall goal of the organization being to produce quality software with zero defects. After all, one small bug in a financial services company's code can easily result in a bad trade costing millions. But, just because "all roads lead to ROME", doesn't mean all the travelers necessarily want to take the same route to get there. One obvious "fork in the road" separates the developers from the testers (whose different functions and perspectives frequently contribute to an adversarial relationship in many organizations). Imagine the two groups as opposing teams playing a game of volleyball. Developers hit the release over the net to QA. Then QA finds bugs and hits it back to the testers. If the product gets past QA and afterward bugs are found, then QA is blamed for not finding the bug. So, the developers are subtlety motivated to have QA "accidentally" miss some problems until after release, so that they can claim to have done their "piece" of the project on time. (In fact many discussions occur regarding whether or not a bug found is serious enough to hold up the release.) The only way out of this dilemma is to consistently and conspicuously reward effective collaboration between the two groups. Ideally, individuals within both teams should be incented only to create successful products, not simply to have someone else to blame for failures! Many Agile practitioners advocate embedding testers directly within the development team. However, having the testers in the development team can create a conflict of interest for the firm (and may fail IT compliance and governance standards). Developers want to meet their deadlines (and may have significant financial reasons for wanting to do so). If a bug is found in production - the firm may loose a lot of money. Embedded testers may be pressured to let problems "slide by". If they resist, the developers may consider the tester to no longer qualify as a supportive (and committed) member of the team. This can result in less information being given willingly to the test team and, of course, will result in them being kept in the dark during subsequent releases. Embedded testers are obviously more effective when they do know exactly how the application is supposed to function and exactly what functions have been changed for a particular release. Clearly, open and honest communication is critical for successful Agile, and in fact, for all teamwork. Blackbox vs. Whitebox vs. Graybox Blackbox testing means that the testers have no visibility into what has been changed. The testers just follow their regular test plans or some just "bang on the keys" to see what breaks (some people actually insist that this is the best testing methodology). Whitebox testing means that you know what has changed and can focus testing solely on the changed functionality. This is convenient when testers are embedded with the developers. Graybox is, not surprisingly, an eclectic compromise between the two approaches - the testers still do some blackbox testing after they have used their inside knowledge to specifically test the known functional changes. Agile also strongly advocates robust unit testing (e.g. junit) and continuous integration. With all that in mind, QA still needs to have visibility into what has changed without having to be pressured into approving a release before it is ready. There has to be a tolerance for missing deadlines or at least some mechanism for communicating the risk of putting a release into production before it is fully tested. Without these controls, the group dynamics create an adversarial relationship that pits the development team against the test team - all to the detriment of the organization. Where CM fits in CM provides the QA team with visibility into what has changed (e.g. changesets) so that priorities can be managed more effectively. But the real priority is for management to lead the hardworking members of both teams to realize that each group can truly fulfill its function within the organization only by cooperating completely with the other. Both development and testing professionals must be motivated, by management, to consider their job done only when they have enabled the others to do their best work as well. Technology leadership needs to recognize that neither team alone can produce a working system, but managed as a cooperating team, their efforts complement one another and produce results that win! In School Psychology, we sometimes see family dynamics that are also less than desirable. It's important to note that the most common characteristic found in most dysfunction systems are poor communication systems and lack of respect. Effective interventions are often needed to help the parents understand their own unique contribution to the family system. By empowering each parent to recognize their special talents and to communicate more effectively, they become more confident and subsequently more accepting of the others' contributions as well. Agile parents, in turn, are more able to support their children as they learn to resolve conflicts that inevitably arise. Developing the ability to appreciate interpersonal differences and derive benefit from this awareness is a life lesson with numerous applications. Parents who effectively manage the conflicts of sibling rivalry also empower their children to live happy and productive lives (not unlike the value added when development and testing enjoy a healthy relationship). When everyone is working together, the results are always superior to whatever the individuals could have accomplished on their own. Leslie Sachs is a New York State Certified School Psychologist with over 20 years of experience. Ms. Sachs has worked in a variety of clinical and business settings where she has provided many effective interventions designed to improve the social and educational functioning of both individuals and groups. Ms. Sachs has an M.S. in School Psychology from Pace University and interned in Bellevue's Psychiatric Center in NYC. A firm believer in the uniqueness of every individual, she has recently done advanced training with Mel Levine's "All Kinds of Minds" Institute. She may be reached at LeslieASachs@gmail.com
Set as favorite
Bookmark
Email this
Hits: 4097 Trackback(0)Comments (0)
|
| Last Updated on Wednesday, 19 December 2007 04:37 |


Most managers acknowledge that having team members agree on unified goals is
essential to productivity and success. However, achieving consensus as to the
best methodology for reaching those goals can present a real challenge for even
the most experienced professionals. Read on to learn what the experts in the
field of group processes have to say about the dynamics of teamwork and see how
this knowledge can impact your CM environment/practices.

