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 the standards compatible. The end result is a blended framework that has the best competencies to meet the goals of the organization. By taking a holistic approach, the resulting framework is comprehensive and can be used to address all of the needs of the product life cycle.
Organizing the Agile framework
Agile enthusiasts would argue that you do not "do" Agile - you "are" Agile. However, "being Agile" means that you must somehow organize your development processes around some combination of XP, Scrum, Lean, DSDM, FDD, and Unified Process among others. Organizing this into a coherent methodology can be a challenging endeavor especially for use in large organizations.
Dean Leffingwell in his book, "Scaling Software Agility", p. 87, notes that when scaling agile to the enterprise, there are two challenges:
- Challenges inherent in Agile itself (because of fixed rule bases and assumptions built into the methods) and,
- Those imposed by the enterprise (including impediments that likely exist within the enterprise that will otherwise prevent the successful application of the new methods.
As is noted in Leffingwell's book, both types of challenges must be successfully addressed in order for the enterprise to achieve the full benefits of Agile.
Applying Agility to Agile
Software Process Improvement is always a challenging endeavor with many obstacles that must be addressed in order to overcome organizational resistance to change. Demonstrating that processes are right-sized and robust is essential to promoting Agile best practices. It is my opinion, as a process improvement practitioner, that Agile needs to grow into a comprehensive and well-organized framework that is well understood and can be applied to any application life cycle. One way to do this is through blending standards and frameworks, when necessary, to meet organizational goals. Mapping and harmonizing Agile to industry standards and frameworks will help to show senior management that Agile can be the basis for a comprehensive framework that can also support IT Governance and compliance.
Agile practices are tremendously valuable to organizations and need to be supported and promoted. Overcoming the challenges inherent in Agile itself will help promote Agility into its rightful place in software development methodologies and realize tremendous value for those organizations who are wise enough to adopt them!
Bob Aiello is the Editor-in-Chief for CM Crossroads and an independent consultant specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at [email protected] or link with him at http://www.linkedin.com/in/bobaiello.
