What Is Change Management?
People resist change. If a process works for them, they want to keep that process. It doesn't matter if another process might work better. They have a process. Change management is the process of moving to a better process and doing so with a minimum of disruption to the organization or project.
If you have been working in a traditional software environment, you are accustomed to discrete phases, well-defined documentation, and reviews at the end of each phase of the waterfall development process. The change to be managed in this case, is the move from waterfall development to Agile development. Moving from Waterfall to Agile can be difficult. Moving successfully without a plan is nearly impossible since the barriers will come upon you unexpectedly.
What Are the Barriers?
While there are many barriers to change, we will look at five. They are:
- Failure to define barriers
- Lack of leadership
- Failure to engage key stakeholders
- Failure to establish a clear change plan
- Failure to establish a method to measure progress in making the change
Failure to Define Barriers to Change
Before attempting to complete a transition to an Agile environment, you and your team have to know what you will be facing. You have to know what will threaten the successful completion the transition.
How to Implement
Organizational or process change is difficult to accomplish. To attempt to implement change without strong leadership is futile and a waste of time for all the people involved. Without strong leadership, the obstacles are too great to overcome.
The leader of the change must be someone who understands the objectives and the benefits of pursuing the objectives. In most cases, the change is going to be difficult and require the participants to be uncomfortable, sometimes for an extended period of time. The leader must be able to communicate to the participants the reason for the change, the benefits of the change, an honest assessment of how difficult the change will be, and a vision of the outcome of the change.
If the leader cannot communicate these aspects of the change, the effort will fail, either because those involved won't participate or they will leave, creating bigger problems than the need to change.
Failure to Engage Key Stakeholders
The effort spent implementing change is effort not spent on production. If an organization is tasked to create a system, the key stakeholders view progress in terms of completing the waterfall milestones. If you fail to sell them on a method, any attempt to implement the method will fail. If nothing else, they will see to it that it fails.
You must first convince the stakeholders, or "owners" of the benefit of the change. Does it save them money? Does it speed things up? Is it less likely to fail? All of these concerns must be addressed to the satisfaction of the key shareholders.
You also must control their expectations, making sure they understand exactly what the Agile team will be producing, and more importantly what they will not be producing. You won't be producing a requirements document before you start? Make sure they understand that you will not be producing a requirements document prior to the beginning of coding. But also make sure they understand the function of user stories and the importance of the members of the Agile team, including, or especially the user.
As a part of controlling their expectations, make sure they understand what will be delivered and the steps used to create the deliveries.
Failure to Establish a Clear Change Plan
As the manager transitioning your development team to an Agile environment, you must know exactly what an agile process involves. And you must be ready to explain this to your team, making sure you give them a clear idea of where you are trying to take them and, more importantly, how you intend to take them there. It's one thing to identify a goal, quite another to explain how you intend to accomplish the goal. How are you going to avoid an obligation to produce a requirements document? How will the configuration control board feel about the lack of a formal Requirements Traceability Matrix? How do you intend to get past the board without holding the explicitly required milestone reviews? No one wants to put a great deal of effort into a project if they have no assurance of the project succeeding. Providing the team with a plan is the first step in assuring them of the success of the transition.
The team must be confident they will not be required to create a complex document such as an RTM days, if not hours before the planned delivery and implementation. This means the team lead and the project manager have been in communications with the various boards, documenting the board exemption due to the Agile nature of the project. The plan should ensure there are no surprises when the various waterfall milestones come and go without addressing the new Agile project.
No Definition of What Success Looks Like
How do you know when you have successfully transitioned your method of software development? In order to know if you have succeeded, you must decide, ahead of time, what success looks like. While the characteristics may change while you are in the process, by developing a plan, and by tracking its versions, you are able to see where you are in the change process, what has changed during the period, and what the difference is between when you started and when you complete the change effort.
All changes, all modifications to the original steps and objectives should be documented, not simply talked about during a meeting or some other exchange of words.
What Are the Advantages?
If people don't see an advantage to making a change, they will resist the change. Your primary task as a change agent is to make sure the people who will be participating in and paying for the changes understand the advantages to change.
Moving to a disciplined Agile environment will:
- Increase the likelihood of producing software with functions the client wants
- Avoid recoding or last minute coding caused by miscommunications between the development team and the user
- Provide usable coding early in and throughout the process, letting the client see real progress
- Allow the user to make changes to the system as he or she becomes more familiar with the existing software
- Allow the development team to accomplish more with less interference, and with greater success in satisfying the client.
What are the Objectives?
Sometimes, in the midst of change, the objectives are difficult to recall. Change should be implemented in order to improve the process, in this case, software development. It should be implemented in order to decrease the cost of development. It should be implemented to better meet the expectations of the client and improve the working conditions of the developers and other team members. This means you have to know the current processes and be able to envision the future, or planned, processes. And you must be able to measure the changes in performance, efficiency, and quality.