Search

In this article we will share a case-study of our experience combining Scrum and CMMI Level 5, what we refer to as "Agile 5", to significantly improve the delivery rate of product capabilities while maintaining a high level of quality and employee satisfaction. We will also share the pain experienced during our journey of blending these industry best practices and the lessons we learned. [ABSTRACT FROM AUTHOR]

It is possible to combine Agile and Capability Maturity Model Integrated (CMMI), but few organizations are doing this in practice. There are many challenges to be overcome, not the least of which is the very different mindsets of adherents of each approach. More importantly, we have a better option available to us in the form of the Disciplined Agile (DA) Framework. The DA process decision framework provides light-weight guidance to help organizations streamline their software processes in a context-sensitive manner. It does this by showing how various capabilities such as solution delivery, operations, enterprise architecture, portfolio management, and many others work together in a cohesive whole. The framework also provides a range of options for addressing these capabilities, describing the tradeoffs associated with each option. The DA Framework provides organizations with an easier and better described path to agile capability maturity than the strategy of force-fitting Agile and CMMI together. The Capability Maturity Model Integrated (CMMI) model purports to provide guidance to help organizations improve their software processes. This has in fact happened in some organizations, albeit in manners that are not as streamlined as many people would like. Agile strategies - such as agile development techniques, agile architecture techniques, agile management techniques, agile modeling techniques, and more - offer the potential to streamline and improve your software processes. This has occurred in practice in a multitude of environments. Agile has become the standard approach in many organizations and continues to grow in the majority of companies around the world. It is possible to combine Agile strategies and CMMI together: CMMI describes what should be done and Agile describes how it should be done, so combining them should be a good idea. That's the theory - Practice shows there is a better way. [ABSTRACT FROM AUTHOR]

In this article we report our experiences applying Agile practices and Art of the Possible methods in a software sustainment organization, specifically the F-15 Avionics Integration Support Facility (AISF) at Robins Air Force Base. [ABSTRACT FROM AUTHOR]

Today organizations are questioning if the CMMI is still relevant as they move to more popular agile approaches, such as Scrum. But many of these same organizations are also discovering that agile approaches alone are failing to provide the product quality their customers are demanding especially in constrained and regulated environments. This article employs a case study of an organization that recognized they had gone too far in abandoning their CMMI-based heavyweight processes in favor of an agile approach. The article describes how the organization rapidly put critical lite-weight practices in place-- complementing their agile approach-- that measurably improved performance in just a few months by using a combination of three frameworks; CMMI, Scrum and Essence. [ABSTRACT FROM AUTHOR]

Such is the case with Agile and CMMI, two paradigms that appear to be diametrically opposite [1] ... or are they perhaps coexistent or even mutually reinforcing [8]? To what extent is Agile or CMMI at the tipping point and why? On the LinkedIn blogs, the advocates of Agile or CMMI so vigorously reject the alternative explanations of the other camp that sensible discussion of coexistence of the methods seems beyond the tipping point... until now. A new way of thinking put forth by Ivar Jacobson in the Software Engineering Methods and Technology (SEMAT) and the Essence Kernel [4] may supply the key to this puzzle. The purpose in preparing this paper is to demonstrate in practice the way of thinking of SEMAT and its Essence Kernel and its utility in framing the harmonization issues between two disparate approaches, the Agile method and the CMMI framework. Underlying the opportunity value proposition, expanding and accelerating the dissemination and adoption of SEMAT and its Essence Kernel will be accomplished by systematically demonstrating its application to the audience and user base of the leading frameworks and methods, thereby, engaging and involving these new audiences in SEMAT and its Essence Kernel, its way of thinking, and its way of working... and yielding new converts. The largest audiences among the leading frameworks and methods are Agile and the CMMI. And so we start there with A Strategy for Harmonizing Agile and CMMI Tensions. The issue is whether Agile and CMMI harmonization is a done deal or whether Agile and CMMI harmonization is a work in progress with the heavy lifting yet to be committed to and undertaken. Let's begin. [ABSTRACT FROM AUTHOR]

In 2014 software is the main operational component of every major business and government organization in the world. But software quality is still not acceptable for many applications. Software schedules and costs are frequently much larger than planned. This short study discusses the proven methods and results for achieving software excellence. The paper also provides quantification of what the term "excellence" means for both quality and productivity. [ABSTRACT FROM AUTHOR]

To convince people of the value of Agile, we need to produce new software that is full of wonderful features that the old software didn't possess while functioning exactly the way as the old software did. [ABSTRACT FROM AUTHOR]

Many organizations have adopted agile strategies to some extent, often applying simple methods such as Scrum on a few software development projects. Although they have succeeded on a handful of projects--clearly a good start--they now want to scale agile to address enterprise-class solutions. As the old saying goes about success, "What got you here is not going to get you to the next level." This article explores several important issues when it comes to applying agile strategies at scale. First, it explores what it means to scale agile. Our experience is that without this understanding it is incredibly difficult to come to an agreement as to how to tailor agile strategies to meet your needs at scale. Second, we overview the Disciplined Agile Delivery (DAD) process decision framework and show how it provides a solid foundation from which to scale agile. Third, we explore how DAD's (process) goal-driven approach is the key for scaling agile solution delivery. Fourth, we warn you of the dangers of assuming that you just need to adopt a few new practices. Fifth, we review some survey-based evidence that summarizes the experiences of the industry when it comes to applying agile at scale. [ABSTRACT FROM AUTHOR]

Very Small Entities (VSEs) developing systems or software are very important to the military since the components they develop are often integrated into products made by larger organizations. Failure to deliver a quality product on time and within budget may threaten both customers and suppliers. One way to mitigate these risks is to put in place proven engineering practices. ISO has approved recently the publication of standards and technical reports, known as ISO/IEC 29110, to address the needs of VSEs. [ABSTRACT FROM AUTHOR]

Software development success, estimation, and measured value continue to challenge projects and organizations today. Schedule and budget seem predictable, perhaps unjustifiably in light of the inability to capture product size expectations early and often. Function Points (FP), Use Case Points (UCP), and Story Points (SP) are three approaches for establishing size (or size of effort). Each of these is applied in a case study to identify similarities and differences. The measure of preference is left for the discerning reader. Limited details about the project, its team size, duration, and goals are intentionally excluded from the research since the intended focus is on comparing the project's measurements. [ABSTRACT FROM AUTHOR]

In this paper, we present lessons we learned while working with a large program, helping it to modernize its very large transaction-based system that operates 24x7, while adopting agile software development. We focus on two agile architecting methods we used that provide rapid feedback on the state of agile team support: architecture-centric risk factors for adoption of agile development at scale and incremental architecture evaluations. [ABSTRACT FROM AUTHOR]

Since 2005 we have worked with clients to apply the Scrum framework and to help scale agile development to product groups involving from a few hundred to a few thousand people, in multiple sites. This is organized as large-scale Scrum frameworks 1 and 2, summarized in this article and elaborated on in our two-volume book series on very large-scale agile development. [ABSTRACT FROM AUTHOR]

The essence of stability in software development is the ability to produce quality software with infrastructure that will meet long-term business goals. The essence of rapid and agile development is the ability to deliver capabilities quickly based on customer priorities. Stability often requires cross-functional analysis and infrastructure support that will build foundational technology for the capabilities to stand on, which takes time and resources. But today's organizations must attend to both agility and enduring design. This article presents three tactics that support rapid and agile stability: aligning feature-based development and system decomposition, creating an architectural runway, and using matrix teams. [ABSTRACT FROM AUTHOR]

Today's DoD acquisition environment relies on the DoD 5000 series of guidelines. Nothing in the DoD 5000 series precludes the use of Agile methods. In fact, Agile methods provide both tactical and strategic benefits. However, achieving these benefits is not likely to occur without changes to the traditional DoD mindset. [ABSTRACT FROM AUTHOR]

Now that the CMMI® has been organized into three constellations for assuring an organization's capability to perform development, acquisition, and service, there is a need to extend the range of value of the CMMI to a new normal. As an organization improves its process maturity, strategic imperatives need to replace waste and neglect as the driver of CMMI value. Only those organizations able to elevate their game and transition from tactical to strategic use of the CMMI will be able to reap its full value. [ABSTRACT FROM AUTHOR]

Many believe the CMMI® [1] and Agile methods [2] are at odds. This article will provide practical techniques to take an Agile organization to CMMI Level 3 without jeopardizing its Agile approach. The phrase "Agile organization" as used in this paper refers to any organization that uses an Agile approach on the majority of its projects. By "Agile approach" we mean the extension of Agile software concepts such as iterative development, daily standup meetings, frequent delivery, customer collaboration, and continual refinement of plan, to include systems engineering and project management. [ABSTRACT FROM AUTHOR]

The article reports on the benefits of combining Capability Maturity Model Integration (CMMI) and Agile model. It states that CMMI facilitates an evolutionary path towards optimization, while Agile helps improve several operational and transactional activities. It notes that the combine models operate synergistically to enhance the other's performance, speed to deployment, and acculturation.

The problems with the Waterfall Model and the challenges involved with evolutionary acquisition of defense systems have been well-chronicled. This article describes how Agile techniques can be applied to address these challenges under today's defense acquisition regulations. The article employs a previously published hypothetical space system acquisition case study, along with a case study of a legacy modernization project that employed Agile techniques to aid the acquisition process. [ABSTRACT FROM AUTHOR]

The article discusses the various factors involved in the agile development of computer software in the U.S. It explores the recommendations provided by the authors of the "Manifesto for Agile Software Development" which provides assistance to developers in enhancing the performance of computer software. These include considering customers in the application of process and equipment to be included in the development process, meeting the needs of customers of customers in making software design, and revising plans. It states that considering the ways will help developers prevent the failures involved in software development.

Because large software projects are troublesome and often out get out of control, a number of effective development methods have been created to help reduce the problems of large software projects. Two of these methods include the well-known Capability Maturity Model® (CMM®) and the newer CMM Integration (CMMI®) of the Software Engineering Institute (SEI). When these methods are applied to small projects, it is usually necessary to customize them because, in their original form, they are somewhat cumbersome for small projects, although proven effective for large applications. More recently, alternate methods derived from smaller software projects have become popular under the general name of Agile software development. Since the Agile methods originated for fairly small projects, they can be applied without customization and often return very positive results. It is possible to merge Agile concepts with CMM and CMMI concepts, but projects cited in this article did not do so because such mergers are comparatively rare. [ABSTRACT FROM AUTHOR]

Since the advent of applying Agile [1] practices on DoD projects, specifically Scrum [2] practices, the burning question asked by many has been, "How does Agile integrate with Waterfall [3] milestones?" Agile development is by definition incremental, meaning major functionality is completed and demonstrated to the customer, users, and other stakeholders at specified releases and through a series of short, scheduled iterations (or sprints). Waterfall projects rely on completing all requirements by the Preliminary Design Review (PDR) milestone, completing all design by the Critical Design Review (CDR) milestone, and completing product development by the Test Readiness Review (TRR) milestone. Some success has been made to abate this issue by breaking the typical waterfall-based milestone reviews into multiple interim reviews enabled by the flexibility in the DoD 5000 acquisition regulation requirements. Interim reviews reflect the iterative nature of Agile as they can be held more frequently and with tighter focus than the traditional days-long milestone reviews. This article presents an approach that uses surveillance points throughout the project lifecycle as the basis for technical interchange meetings (TIMS) each of which includes a demonstration and review of completed functionality that can be deployed as an operational component of the final product. When deployed into the targeted domain, users are encouraged to provide reflections of product usage in the form of feedback to the project team in real time. [ABSTRACT FROM AUTHOR]

The original intent behind the agile software development movement and its goals have become diluted over the past decade, with many teams simply doing selected agile practices instead of becoming agile practitioners. Many adopters and their organizations now claim to be comfortable with the idea of agile software development and their own use of it, which is probably an indication that they are doing it wrong. [ABSTRACT FROM AUTHOR]

The DoD is facing challenges to rapidly deploy operational capabilities in complex environments where bridging legacy and new technologies are key to success. The challenges arise as a result of diminishing budgets and the need for new capabilities to operate in war environments, including the global war on terrorism. To balance this imperative need with rapid response, we found that our developed Agile life-cycle paradigm was a viable solution to meet challenges brought about by changes in the environment. This article demonstrates how a DoD program used an Agile approach, throughout every phase of the program's life cycle, to rapidly field capabilities. [ABSTRACT FROM AUTHOR]

The article discusses software development programs which includes capability maturity model and agile software in defense systems software development.

A personal narrative is presented in which the author explores his experience of being in agile software development and programming.

A personal narrative is presented which explores the author's experience as a professional software developer.

The author reflects on rapid and agile stability in software development. She says that agile refers to a group of iterative and incremental development approaches where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. She explains that these teams should have the ability to respond to change while following a plan and applying an interative approach to provide continuous delivery of software to customers.

The article reviews several web sites including the Agile Software Development Manifesto, the Software Program Managers Network, and the National Institute of Standards and Technology: Computer Security Resource Center.