The rationale for using Agile in many environments is to allow for change -- change in requirements, user interface...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and even overall goals. Iterations in Agile development methodologies are designed to elicit feedback and requests for change. Handling them in a change management process should be smooth and natural. Here are six things to know about change management in an Agile context.
1. The goal of Agile is to enable change management, not prevent it.
Non-Agile methodologies have an implicit assumption that requirements can be final and only minor variations in requirements can be accommodated in a change management process. Requirements themselves may be subject to change in Agile iterations. The idea is to show product and application owners working software, and elicit feedback about whether that’s what they meant by their expressed requirements. And so, change management becomes a rationale for Agile, not something that needs to be controlled and managed after the fact.
2. Change management is inevitable in Agile.
Agile development provides a rapid response methodology to handling change within organizations. Requirements could change because of legislative changes, organizational changes or changes in business conditions. State laws and federal laws could change during the course of Agile development and so changes in requirements may result. There could be a re-organization and reassignment of responsibilities within an organization. That could result in functionality or user interface changes. Changes may be needed because product owners may not have realized what they had asked for, and changed their minds. They may not have realized that something else is needed instead of the feature implemented in the latest iteration. In other words, change management is inevitable whether you use Agile or non-Agile methods. Agile methods provide you an elegant and continuous way of handling them earlier and often.
3. There should be no change management during an iteration.
Change management is to be avoided in the middle of an iteration, since Agile modeling may have preceded the implementation in that iteration. In such cases, changes themselves need to be scheduled as stories or features for the next iteration. Changes done during an iteration may introduce defects due to inadequate modeling thought. When properly scheduled in iterations, modeling reviews can be done just before an iteration is started, and the kinds of defects due to architectural mistakes are avoided. These are regression defects due to unforeseen side effects of architectural and code changes. They are best avoided during an iteration but can be carefully considered at the beginning of an iteration.
4. Change management does not mean no prioritization.
Change management and changes introduced in iterations may still need to go through a prioritization process of stories or features. Changes are blended along with scheduled stories in an iteration, and the whole effort revisited with respect to selection for that iteration and schedule. Change management cannot be allowed to scuttle the originally planned rhythm of iterations or the original priorities. It just means that they are synchronized with otherwise planned stories. When change management is blended in with stories or features, careful thought can be applied to see if the changes need to go earlier in the iterations or can wait.
5. Change management does not change highest value story scheduling.
Good Agile development always includes the highest value (to the product owner or end user) stories in the earlier iterations. This can also be for technically challenging stories (or those with high development and technically feasibility risks) to be attempted for earlier iterations. Changes join this stream and if the changes carry high development risks, they need to be addressed in earlier iterations also. Drastic changes in requirements can still be accommodated if they carry a high value for owners or end-users or they carry high development risks. For example, you have been developing an application using Dot.net but product owners require a php version also done in parallel. This may be a drastic change requirement given additional skillsets that may be needed in the development team. It needs to be considered carefully and scheduled in at the right iteration if it has the right value to the stakeholders.
6. Agile does not eliminate change management challenges but provides a disciplined, streamlined way to manage them.
Change management challenges are not eliminated when using Agile methods. They may be necessitated by the external environment, not something within the development team. Agile provides a disciplined, streamlined way to manage them. Agile iterations provide working software earlier, enabling owners and users to recognize and address needed changes earlier. Change management in non-Agile environments assumes that changes come at the end of the development cycle and at most can be minor deviations from the original set of requirements. However, in practice these changes are anything but minor. Agile methods give you a way of recognizing that change management is inevitable and the development methodology needs to facilitate its incorporation in a natural and non-intrusive way.
Change management has always been a challenge in software development, whether you use Agile methods or not. If changes are needed, in Agile, they can be recognized earlier and interleaved with earlier iterations. This also provides a smooth way to also get development risks out of the way, earlier in the development cycle. Rapid change management is the rationale for using Agile methods and can add significant value to resulting software.
About the author: Nari Kannan is currently the Chief Delivery Officer of V-Soft Consulting, Inc., a Louisville, Kentucky-based software consulting firm. Nari has 20 years of experience in information technology and started out as a Senior Software Engineer at Digital Equipment Corp. He has since served variously as Vice President of Engineering or CTO of six Silicon Valley startup companies, working in the areas of business process improvement, IT consulting, automotive claims processing, human resources and logistics applications. He can be reached at firstname.lastname@example.org.