Home 
Behaviorally Speaking Which best practice is best?
Behaviorally Speaking Which best practice is best?
|
 Best practices are dangerous. Trying to use a technique which worked well in one environment may be disappointing or even disastrous in another. There are many good reasons for this. Some best practices work great for a group at a certain maturity level and then bomb when the group changes or there is an outside influence that alters the needs and culture of the development team. If you are the person who is responsible for implementing software process improvement, then you need to consider a number of important factors before you attempt to implement best practices in your organization. Read on if you would like to learn some effective best practices for implementing - uh - best practices!
Misaligned best practices fail The discipline of software process improvement (SPI) has long suffered from practitioners who try to reuse what works in one situation as a justification for implementing what they believe will work in another - entirely different - environment. Of course, experience also counts for a lot but when a particular "best practice" is misaligned (meaning that it is not working well together with other practices employed by the group) or applied poorly then best practices can fail miserably. For example, some teams thrive on risk. Trying to implement an overly bureaucratic release management practice will never work since the team just isn't going to go along and will sometimes even actively sabotage the process (e.g. blaming every possible problem on the time consuming painful procedures that their release management guy put in place). Would you like a skin graft or an amputation? Imagine going to a doctor and having him inform you that his last patient did very well after he was given a specific surgical procedure. Of course your medical condition may be quite different and you may not want your doctor to assume that you also want that procedure without a proper exam and diagnosis. Yet this is exactly what some CM practitioners try to do in implementing process improvement. To be candid, some of my colleagues also have a "my way or the highway" attitude - insisting that their best practices MUST be followed or the team just will not function efficiently. I would suggest that the reason for this attitude is that few CM practitioners have sufficient skills in examining environments to see what will work and what will not for a given development organization. (Sure glad my doctor takes a little more personal approach!) Let's examine how we can best understand a development organization. Setting the goals for your team I always propose focusing first on the goals of the group. Do you need repeatable builds? Do you have trouble determining what version of the code is in production? Maybe your developers get confused and have trouble organizing their code on development branches or the mainline (e.g. trunk) of the source code repository. Code can often regress because the team just doesn't understand what needs to be done. Many financial services firms have the goal of complying with regulatory requirements (e.g. Sarbanes Oxley, SAS-70). The first step in any process improvement initiative must be establishing, defining and communicating the goals of the effort. Once you know what needs to get done then you often have some flexibility in how to accomplish these goals. Reasons for failure CM practitioners need to develop better skills at sizing up a situation and determining what will work best given a particular group of people, corporate culture and technological challenges. Some best practices may be awesome in some situations, but will not work well at all, because of forces that you just cannot control (e.g. economy, regulatory efforts, even corporate culture). Too often, process improvement professionals just get frustrated and decide that the problem with a development team is that, "they just don't want to change!" In fact, the group may not see any effective alternatives to the way that they are functioning. As a release manager (working around the clock with the rest of my team), I once walked into the CEOs office of a small financial services firm and said, "you don't need any process improvement here. What you need first is to allow your developers to get a good night's sleep!". Process improvement could not possibly happen because we were all too stressed and exhausted (and half the team was out sick). We, as change agents, can be more effective if we understand the environment within which we must operate. So understanding our own ecosystems can help us decide which best practices will work and which ones just won't (often because of forces over which we have no control). Instead of getting frustrated we can size up the situation a little better and get more effective at implementing change if we understand what is likely to work and what is likely not to work. I often focus on "just in time process improvement" whereby we implement just enough process to avoid making mistakes. Understanding your own ecosystem Ecologists and other scientists have often analyzed our "natural" environmental systems (e.g. ecosystems) in terms of internal (e.g. conservation) and external (e.g. weather) forces. This methodology is known as Open Systems Analysis. For example, heavy rains (or a severe draught) can change the way that an ecosystem works and result in growth or even extinction. In corporate environments, we can also learn a lot about our organizations by understanding them as "ecosystems" which are impacted by internal forces (e.g. corporate politics, organizational structure) or outside forces (e.g. regulatory demands, broader economy or supply and demand of technical talent). I discussed this technique in a little more detail in my May 2002 column, but essentially you need to consider at all of the forces which impact your organization. In order to successfully implement any best practice, you need to decide how those forces will impact your efforts. Forces of entropy Another example of applying open systems analysis is taking a look at what forces cause an organization to go from order to disorder. For example, high turnover, competition in the market or rapidly changing technologies can result in risks that translate into organizational chaos. This is not always bad and, in fact, some CM practitioners may find it a lot easier to implement change during times when the organization is changing (e.g. unstable). Best process is best! The bottom line is that we need to look at the environment that we work in and analyze what process improvement changes (e.g. best practices) will be effective and which ones will not. CM practitioners need to take a lesson from our colleagues in medicine and biology in observing the organization more clearly and diagnosing which interventions will be effective and which ones just will not yield the desired results. One important observation is that organizations in trouble actually need our help more and we have a fantastic opportunity to provide value as process improvement experts. Implementing best practices with an eye toward fully understanding people, process and technology is my pick for the best process which is best! Bob Aiello is a Senior Editor for CM Crossroads and an Associate Director at a major financial services firm in NYC, where he has company wide responsibility for Software Configuration and Release Management best practices. Bob is on the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he is also the chair of the CM SIG which meets in Midtown NYC. Mr. Aiello has a Masters in Industrial Psychology from NYU and a BS in Computer Science from Hofstra University.
Set as favorite
Bookmark
Email this
Hits: 6291 Trackback(0)Comments (1)
|
TrackBack URI for this entry
Subscribe to this comment's feed
 |
... Bob, Really enjoyed your article on "Which Practice is Best". At Lockheed Martin, they differentiate between the more technical software CM personnel and the more administrative CM persons. However, it is whim and someone's fancy as to who gets what title, which is very stressful in trying to manage one's career path. Having conquered more languages than most developers, and more tools than most managers can name, I find it offensive to be forced into an administrative CM position. Wouldn't anyone? Can you address this topic in CM CrossRoads? |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
