Search

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]

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]

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]

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]

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]

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]

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]

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]

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]

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 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.

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]

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.