Overcoming Resistance to Change with Distributed Agile


Overcoming resistance to change and addressing challenges with distributed Agile requires considerable skills and experience. Agile development practices are incredibly popular, with many developers, because they work well and they add value. Unfortunately, many Agile enthusiasts are unprepared for the challenge of overcoming organizational resistance to change - especially from senior management unwilling to sponsor a methodology which is unfamiliar to them and does not carry the same name recognition as other frameworks such as the CMMI. That's not to say that we should give up and continue to write volumes of requirements "shelf-ware" that is outdated before it is used. Every process improvement effort has its own set of challenges and obstacles to be dealt with. Read on if you would like to explore overcoming resistance to change - the Agile way.

The view from the top


In my practice, I have heard CXOs proclaim that waterfall works just fine and yet they are also the first ones to express surprise when projects miss the mark because the development team focused on (volumes of) immutable requirements documents instead of delivering software that works and meets the needs of the customer. Best practices such as continuous integration and Agile testing (with its inherent integration of testing from the very beginning of the project) have clearly demonstrated their wisdom and value (being used on many non-Agile projects as well). Yet, it could be argued that Agile enthusiasts need to work on their delivery (as well as their overall framework).

Remember the CMM?


Years ago, most software process improvement experts were either using the CMM (with its painful assessment process) or adapting the ISO 9000-3 standard to their software development effort. The CMM had a number of Key Process Areas (today we call them Process Areas in the CMMI) which had to be implemented in specific "levels" and experts cautioned against skipping levels. This meant that you could not implement code inspections (in Level 3) before you had finished Software Subcontractor Management (in Level 2). The rigidity of the model required that you complete one level before moving onto the next. I have been part of the process improvement community promoting the use of the CMM (now CMMI) for many years and almost all of my colleagues have moved solidly into the Agile camp with much better results. Recently, I was privileged to hear industry luminary, Ivars Jacobson speak on this topic. Dr. Jacobson noted that he had seen Level 5 CMM organizations that developed lousy code.

Lessons Learned

Processes need to be right-sized and focused on achieving the goals of the organization. There are times when detailed documentation does need to be written - up front and very thoroughly maintained. For example, writing a life support or a real time trading system must have thorough documentation, as well as clearly defined procedures to track requirements from inception through production release (and then after that, also track bug fixes in maintenance mode). Many companies are required to comply with section 404 of the Sarbanes-Oxley Act of 2002 and this responsibility requires specific competencies in terms of IT Governance and compliance. So either Agile needs to be adapted to meet these requirements, or a large number of critical projects cannot use the Agile methodologies.


Implementing standards and frameworks


Recently, I had the opportunity to research and design a framework to implement a Quality Management organization. This assignment included support for both development lifecycles as well as non-development activities (e.g. Service Management). My recommended framework included ISO 9001:2000 which establishes the Quality Management System (QMS), ISACA Cobit 4.1 IT Processes, and the IEEE 12207 life cycle standard, as an overall "umbrella" to support the other standards and frameworks. Among CMMI, IEEE 828 CM Plans, ITIL v3 - I carefully specified the use of Agile practices in support of the software development life cycle. My framework included support for the entire application life cycle or even more broadly, the product life cycle. My goal is to right-size the Agile and non-Agile methods to achieve the goals of the organization.

Mapping, harmonizing, tailoring and blending

Many of the standards and frameworks have strengths and weaknesses that may or may not overlap other standards and frameworks. Identifying the commonality as well as the gaps is known as "mapping". Harmonizing refers to identifying the gaps and adding - or possibly deleting tasks - in order to make

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.