Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
Agile Blogs
No desc available
Top 5 Ways to Incorporate CMMI with Agile Methods
There is a common misconception that CMMI and Agile are polar opposites. One relies on institutionalization and documentation of processes and methodologies, while the other emphasizes interaction among workers and “working software over comprehensive documentation” (Agile Manifesto). Process documentation and institutionalization is the lifeblood of CMMI, and it is often used in critical software development life cycles. On the other hand, the Agile approach is called into action when a project features incremental changes, particularly those that have not been included in initial requirement documents.
There have been criticisms of both, as well: CMMI is used only in security-intensive projects that need massive numbers of workers, layers of procedures, and a rigid development lifecycle. On the other hand, those who implement Agile have been referred to as an undisciplined “hackers” of development projects.
The Software Engineering Institute (SEI) doesn’t think that critics are exactly right; in fact, the institute believes taht naysayers are no farther from the truth. The success or failure of implementing Agile methodologies has nothing to do with documentation, according to Margaret Kulpa and Kent Johnson, authors of “Interpreting the CMMI: A Process Improvement Approach, Second Edition (2008).” You could write reams of documentation about your processes without necessarily practicing what is on paper.
What Agile Methods Mean to Your Process, People, and Products
Studies show that most successful projects were those that followed agile principles, proving that model-driven methods are not always the best when it came to managing changes, fast-paced project implementation, or even meeting market demands.
The concept of agile development is not new. However, many technologists still stick to the age-old notion that software development can be easily designed and the outputs predicted without giving much thought to the more dynamic factors of projects, such as communication lines, people, and change.
Project managers eventually realized that a lot of projects failed because of rigid requirements, faulty design, and the inability of project teams to adapt to change. For the most part, clients or end-users' requirements changed through the course of development lifecycles, that by the time applications were ready for deployment, the end products were a good degree different from what was initially planned. This would have been alright, except that towards the end of the development lifecycle, time and financial resources have overshot initial estimates by a good measure.
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper

