In her Personality Matters series, Leslie Sachs examines the personalities and people issues that are found in technology groups from cross-functional, high-performance teams to dysfunctional matrix organizations.
Haste Makes Waste
Some members of the team will have a tendency to rush to complete their part of the work in order to just simply "make a deadline." However, rushing to hit a deadline does not always result in the best work possible. The team leader needs to be able to convince each member that their component must be completed accurately, as well as quickly. The final product is only as good as each of its subparts.
Volley Ball for Release Managers
Too often, technology professionals act like release management is a game of volley ball. Hitting the release over the net to the RM Team does not necessarily mean that you have met your objective. The real goal should be to make sure that the code is actually ready for deployment. It may feel good for the moment to keep the ball in play, but everyone on the RM team needs to stay focused on the big picture - deployment-ready code.
Is Everyone communicating?
Technology professionals are not always the best communicators. Techies frequently fail to do a good job of explaining the changes involved and their impact upon both the Release Management function as well as the QA testing effort. Make sure that the technology professionals on your team do a good job of putting together release notes describing all of their changes.
Change Control meeting that helps teams communicate
Your Change Control function should help teams communicate better. It should also be a catalyst for all of the other CM related functions to be completed. The Change Control Board should require that all proposed releases meet establish entry and exit criteria that includes CM Plans, Release Notes, Approvals and Test Plans. Change Control can be the gatekeeper to make certain that all of the other functions are completed successfully, prior to the release being approved.
Are developers given an incentive to not cooperate?
In some organizations, developers are only incented to write code and are not always held responsible to follow the development process. Effective teams avoid bad behavior by incenting all of their members to cooperate and work together effectively. Obviously, a big part of this is to follow the established development process and not just to try to work around mandated IT controls. That said, I have know many situations where developers got very creative in avoiding controls that they did not feel were fair or necessary. Often this was to the astonishment and chagrin of the senior managers who had approved and required the controls to be established. For example, developers are typically not allowed to put their changes directly into production. Yet many developers will be extremely creative when it comes to circumventing controls (and effectively violating their organization's audit requirements) for the sake of expediency. Many companies unintentionally reward their developers for such dysfunctional behavior because their incentives are only based upon delivery of the code - instead of achieving the business and organizational goals.
Assess the team in front of you
You certainly want to see everyone's point of view. You also want to make certain that strong personalities do not bully the other members of the team into silence. Effective teams take everyone's point of view into account. Insight into team dynamics is essential to understanding and managing effectively. I have seen individuals with very strong personalities overwhelm the other members of the team and completely derail the team from being effective.
Conclusion
Understanding the unique personalities that comprise your particular Release Management team can help you devise strategies designed specifically to help your entire team work more effectively together. You need to strive to have effective communication, a culture of openness and, of course, always realize that Personalities Matter!
