Is it enough to derive a solution if the solution does not work in the context of the organization, application or project? A 15-step change control process (e.g., solution) that includes full impact analysis, estimation, and traceability is appropriate for a mature organization, but is it appropriate for an immature organization that has never experienced change control?

Using another scenario, how likely is ‘defect prevention', a CMM Level 5 key process area (KPA) going to succeed in a company where there is little or no desire to have consist processes or there is no historical data being tracked? While defect prevention is considered a good practice, if an organization that is CMM Level 1 (e.g., ad hoc) is tasked to do a CMM Level 5 KPA, the forces currently in play within the organization will likely lead the KPA activities to become low priority (or people will avoid them) and ultimately fail to take root.

In addition, how likely is long term planning to succeed when a company is driven by quarterly profits? This is where the study of antipatterns plays a role and may be helpful in considering future solutions.

What is an Antipattern
When talking about what an ‘antipattern' is, we must also address what a ‘pattern' is. A very simple definition of a pattern is that it is a ‘good' solution with the implication that the solution actually works within the context of the organization or group. Ergo, an antipattern is defined as a ‘poor' solution. What is meant by that is that an antipattern is a solution to a problem that may appear like a good idea, but lacks the necessary input to make it effective and workable.

An antipattern will appear when a solution is decided and deployed, but the context and forces are not factored in and consequences of the solution are not considered. The context and forces may be considered critical input prior to defining a ‘good' solution (aka, pattern). By context, this refers to the setting or experience level of the organization in which the problem lives and in which solution must work. By forces, this refers to various influences in play (political, procedural, social, resistance, maturity, etc.) that can affect a solution and therefore the solution's adoptability within the context.

To learn more about antipatterns and patterns consider reading "AntiPatterns and Patterns in Software Configuration Management" by William J. Brown, Hays W. "Skip" McCormick III, and Scott W. Thomas, "Software Configuration Management Patterns" by Stephen P. Berczuk with Brad Appleton, and visiting http://c2.com/cgi/wiki?ProcessAntiPatterns, part of the Wiki Wiki Web.

How Antipatterns impact Change Control
Change control is a configuration management process used to manage changes to important baselines like requirements and production. Change control may be considered a critical practice in that it often can be used to manage critical items within a project lifecycle, an application lifecycle, or the organization.

It can be challenging to implement change control effectively. Often the reason why is because there is an antipattern (a.k.a., poor unworkable solution) in place. Where a solution appears to exist, the forces and context were not considered prior to designing the solution. As mentioned above, to implement an advanced form of change control (that includes full impact analysis, estimation, and traceability) into an immature company may imply that the context and current forces had not been considered in the preparation of the solution.

Change Control Antipatterns
Below are three examples of antipatterns for change control. These are just some and more can certainly be considered.

Antipattern Name: Equal Vote

Problem:

• How do we decide on change?
  Context:
• A decision must be made to accept or reject a change request.
• There are a variety of people that participate in a change control board (CCB)
  Forces:
• Some people have more company positional power than others
• You may be obligated to accept or reject a change due to business reasons
• Corporations are not typically run as a democracy, but run as a hierarchy.
  (Poor) Solution:
• Establish a CCB and give everyone who attends an equal vote in a CCB.
  Consequences:
  
  .  There is a feeling of resentment or disempowerment when the ‘true' power voter(s) makes the decision to accept or reject the change request.

Better Solution:

• While there may be a variety of members on a CCB, differentiate between members who discuss the change and those who have the real voting power. This establishes the expectation up front that much like any company, those in higher positions have more of a decision making vote.

Antipattern Name: CCB Junior

Problem:

• We must assign people to the new change control board (CCB)
  Context:
• People are schedule-driven and typically very busy
• Junior people may not be as busy as the experienced people
• Some people have more experience and knowledge than others
  Forces:
• The experienced people are already making the decisions
• Resistance to new change control process
• Managers are always looking for places to put the junior people
  (Poor) Solution:
• Put junior level people on the CCB.

• Poor decisions are reached in relation to change requests because inexperienced people on the CCB make the decisions. Many times others (who have more knowledge or empowerment) see these poor decisions, take control by making their own decisions, thereby circumventing the CCB. The CCB becomes considered ineffective.

Better Solution:

• Select appropriately empowered members to the CCB. Ensure there is a role transition plan (those who are already making the decision see that the change control process and CCB align with their current role, but with a little more structure (keep the structure to a minimum at first). Ensure the empowered team has a similar distribution of knowledge and power. If someone has much less empowerment, remove them from the CCB or do not give them voting rights (see Equal Vote antipattern). An empowered, enthusiastic team willing to take extraordinary measures to meet project goals.

Antipattern Name: All Changes are Created Equal

Problem:

• How do we manage the changes coming in?

• A group of changes (requirements or defects) are on the ‘list' targeted for a project.

• Changes may have different levels of priorities

• Expediency by management to start working or developing something
• Lack of prioritization process or experience in prioritizing
• The push from management to get it ‘all' done (cannot say no)

(Poor) Solution:

• All change requests that are ‘approved' for projects, have undiscussed equal priority.

• Ad hoc prioritization is done inconsistently at the individual developer perspective. Typically, developers work on whatever interests them versus the true priority. Then some of the actual high priority changes do not get completed.

Better Solution:

• Build in a prioritization sub-process with the appropriate guidelines (e.g., based on customer prioritization). Prioritize the changes and ensure these changes are track. Management should monitor that high priority changes are being worked on first.

Antipattern Name: Frozen Requirements

Problem:

• We must ensure there is a set of requirements to work from on the project release

• Requirements get identified at various points in time and reviewed during the requirements phase.

• The project continues through the project lifecycle.

• Change happens - there is a demand for new/modified features and functionality
• Its hard to work from a changing list of requirements
  (Poor) Solution:
• Define a static set of requirements (e.g., baseline) and work to that for the project. Any new requirements get moved to the next project release.

Consequences:

• Potentially important changes do not make it into this project release. This may have a negative business impact. The changes sometimes find their way in anyway (uncontrolled scope creep) but the changes are not documented in the release notes (since they are unknown).

Better Solution:

• Recognize and manage the change happens. Define a set of requirements (e.g., baseline) to start with and apply change control to manage changes to that requirements list throughout the lifecycle of the project via appropriate control control procedures.

Summary
Antipatterns may be a useful way to evaluate potential solutions. By considering the context of the problem and the forces that are in existence, it may provide a way to evaluate the solutions and identify which is best for your situation. Given that change control may be considered a critical practice in that it often can be used to manage critical items, I hope the antipatterns discussed above help you avoid common mistakes. I also hope it allows you to re-evaluate any change control processes (or any CM processes) in place that may not be working well by considering the context and forces within your scenario.

References

Trackback(0)

TrackBack URI for this entry

Comments (0)

Subscribe to this comment's feed

Write comment