Agile Manifesto

By / / , , , , ,
, , , , ,

Agile Alliance

On February 2001, seventeen people convened at the Snowbird Ski Resort in Utah to find common ground and develop an alternative approach to document-driven, heavyweight software development processes. The group included representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Programmatic Programming. They named themselves the “Agile Alliance” and created and signed the Agile Manifesto which became the cornerstone for the Agile movement.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation
Responding to Change over Following a Plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Streamlines Documentation

Historically, enormous amounts of time were invested in documenting the product for development and delivery. The list was extensive and included technical specifications, requirements, prospectus, interface design documents, test plans, documentation plans, and untimely approvals, resulting in bottlenecks and long cycle times. Agile does not eliminate documentation, rather, it streamlines documentation by providing the developer with just the essentials that are needed to do the work.

People Over Process

Valuing people more highly than processes or tools is easy to understand because it is people who respond to business needs and drive the development process. If the process or the tools drive development the team is less responsive to change and less likely to meet customer needs.

Negotiation vs. Collaboration

Negotiation is the period when the customer and the product manager work out the details of a delivery with points along the way where the details may be renegotiated. Collaboration is a different creature entirely, with development models such as waterfall, customers negotiate the requirements for the product often in great detail prior to any work starting.

This meant the customer was involved in the process of development before development began and after it was completed but not during the process. The agile manifesto describes a customer who is engaged and collaborates throughout the development process, making it much easier for developers to meet the needs of the customer.

Welcoming Change

Traditional software development regarded change as an expense and avoided it whenever possible. The intention was to develop detailed elaborate plans with a defined set of features and dependencies so that the team had a clear understanding of what should be developed and when it should be worked.

Agile welcomes changing requirements, even late in the development and uses rolling wave planning to decompose work just-in-time, without going into elaborate decomposition of the high-level plan.

12 Principles

The Agile Alliance also created 12 principles that support and expand on the four agile manifesto values. These principles have resulted in a number of widely accepted best practices that are used in many agile approaches such as extreme programming, scrum, DSDM, Adaptive Software Development, Crystal, and Feature-Driven Development.

The Agile Manifesto has spread like wildfire since 2001, forever altering the way we develop custom solutions and making impacts far beyond its original software origin.

Visual Representation of Agile Manifesto

Agile Manifesto Read Post »

Developing a Product Vision

By /
Developing a Product Vission

The agile development cycle relies on an accurate understanding of the customer’s needs and the ability of an organization to rapidly develop innovative solutions that best satisfy those needs. A product vision is the first step to defining what needs will be met through the development of a product solution. It gives the company, development teams and stakeholders a unified direction and a common understanding of the desired outcome. Product vision development includes: Identifying and connecting with your customer’s needs, conceptualizing the product features that satisfy those needs, understanding your main competitor’s product and identifying why your product is favorably different. 

To develop a product vision, it can be helpful to first, “Tell the Story”. The story captures the ideal experience your customer will have while using your product and the difficulties they may encounter with existing product solutions.

Here is an example of a user experience story:

U.S. Navy- MK48 ADCAP (Advanced Capability) Securing System

Chief Hatch watches as a torpedoman performs routine maintenance in the torpedo room while they are underway in hostile environments. The torpedoman struggles as he and a fellow sailor carry extremely heavy cables that are used for torpedo stowage. Due to their weight and material composition, the cables create sound shorts when they encounter other metallic objects in the torpedo room. It is crucial that the submarine navigates the seas undetected because the primary mission on submarines is counter-detection. The frequency of sound shorts, due to inefficient stowing, has been a problem for the submarine force since its inception.

Chief Hatch thought about the number of injuries that had occurred just this past year as a direct result of the current MK48 ADCAP securing system and stowage procedures. The desired solution would be a lightweight, equally strong system that would allow for maintenance to be performed safely by a single torpedoman. Ideally, the material composition would minimize sound shorts, allow for easier maneuverability and substantially decrease the amount of space required to stow and handle cables.

From the above example, it becomes clear that the current MK48 ADCAP securing system is compromising the stealth requirements of the mission and is creating a safety hazard for sailors at sea. The customer’s desired outcome in this story is a safe, easy to use, lighter and more discrete securement system.

The next step in creating a Product Vision is to create personas for your primary and secondary customers. These personas will help you capture what is most important or valuable to your customer.

Primary Persona: Chief Hatch

Torpedoman, Chief Petty Officer, Senior Enlisted, 38 years old

Persona Description:

“Chief Hatch believes that a nimbler and easier to use securement system will allow for smoother and more efficient weapons handling, increased sound silencing, mission stealth and a safer crew.” 

Chief Hatch has been on submarines for 18 years. He has watched as weapons have been updated and modernized throughout his career, except for the torpedo handling gear. He is frustrated with the excessive weight of the archaic securement system, especially when it results in crew injuries.

Goals:

  • Chief Hatch wants to update the archaic MK48 ADCAP Securing System with a light-weight, easier to use stowage system without compromising: strength, stability or efficiency.

Motivations:

  • Chief Hatch believes his junior sailors would have a higher retention rate and fewer safety related injuries if they had a lighter more efficient method of stowage in the torpedo room.

Pain Points:

  • The current securement system straps and heavy material composition creates a cumbersome holding mechanism that often results in fatigue, neck injuries and damaged equipment from improper stowage.
  • Multiple sailors are needed to stow, pivot-load or re-stow a torpedo resulting in strain on the current workforce.

Secondary Persona: Lieutenant Marks

Weapons Officer, 30 years old

Persona Description:

“My best days are when I have 100% weapons readiness, all periodic maintenance and weapons handling has been completed safely and on time and I have received no complaints for faulty equipment or poor storage practices.”

Lieutenant Marks has been in service for eight years and is most frustrated when poorly maintained or out of date equipment must be reused to maintain weapons readiness. To Lieutenant Marks a lighter cable with the same strength rating means, easier to maintain weapons readiness and happier sailors.

Goals:

  • Lieutenant Marks wishes to maintain physical readiness in the Torpedo room.
  • She also wants to increase efficiency, safety and technical readiness using modern stowing equipment.

Motivations:

  • Lieutenant Marks is motivated by personal standing in the command, squadron and group.

Pain Points:

  • Lack of material readiness as a result of outdated or overused equipment. 
  • Failed or degrading equipment due to poor maintenance and improper handling. 

Now that you better understand the desired user experience and what is most important to your customer, think about the following questions when you build your product vision.

  1. Who will use your product or service?
  2. What do they need out of the product or service?
  3. What is the product you are developing?
  4. What category does it fit into?
  5. Why should your customer buy this product or service?
  6. What is your competitor’s product?
  7. What sets your product apart from the competitor?

Here is an example of a product vision developed from the above steps:

ADCAP (Advanced Capability) Securing System Product Vision

FOR: “The U.S. Navy”

WHO: “Need a more efficient, reliable and lighter means of securing weaponry.”

THE: “Mark 48 ADCAP Securing System”

IS A: “Modernized Weapon Securing System”

THAT: “Allows for fast stowing and easy handling while pivot tube loading and re-stowing heavyweight torpedo”

UNLIKE: “The current heavy gauge rubber coated straps with rigid metal ends”

OUR PRODUCT: “Provides lightweight handling, increased material strength and improved flexibility resulting in easier stowage and handling.”

STRATEGY: “Replace fleet wide Navy weapon straps on all existing and future classes of submarines”

Developing a Product Vision Read Post »

EIA 748-D Released – Change Notes

By / / ,
,

EIA 748 D Released

Portions extracted from the EIA-748-D © SAE International (with permission).

Are you aware that a revision to the Society of Automotive Engineers (SAE) / Electronics Industry Alliance (EIA)  Standard 748 Earned Value Management Systems, has been released? The new revision is SAE / EIA 748-D. Officials have been discussing the changes at recent industry conferences.

Sections 2.1-2.5 – No Changes to EVMS Guidelines

No changes have been made to the 32 EVMS Guidelines in Sections 2.1-2.5 of the standard. The changes are primarily clarifications of the existing text:

Section 1 – Additional 4th Note

Section 1 “Scope of EVMS” previously “Introduction” in 748-C now has an additional 4th Note:

“Note 4: There are occasions where it is beneficial for complementary systems or methodologies (e.g., Enterprise/ Manufacturing Resource Planning, Agile Software Development, Theory of Constraints) to interface with the EVM System. These complementary systems or methodologies can be used to deliver functionality and value to the customer while EVM provides a standardized method for measuring progress and reporting across the contract. The EVMS documentation should describe the interface content as well as the recurring control process to maintain data conformance and system compliance.” © SAE

Section 2.6 –  Six Additional Terms

Section 2.6 “Common Terminology” includes six additional terms:

ACTIVITY OR TASK: An element of work with an expected duration in the network schedule that is performed during the course of a project. Activities generally have expected resource requirements used to determine the budget for the work effort. One or more activities may relate to a work package.

AUTHORIZED UNPRICED WORK (AUW): A contract scope change which has been directed by the customer’s contracting officer but has not yet been fully negotiated/definitized. It includes a value, excluding fee or profit, typically associated with the authorized, unpriced change order.

ELEMENT OF COST (EOC): The categories of cost such as labor, material, subcontractor, and other direct costs as defined by company accounting practices.

OVER TARGET SCHEDULE (OTS): A replanned schedule baseline that extends beyond contract milestone dates, delivery dates, or completion date. An OTS is usually accompanied by an increase in budgets resulting in a corresponding Over Target Baseline (OTB). It typically requires customer approval to implement.

RISK AND OPPORTUNITY (R&O): An uncertain future event or situation that could impact the ability to achieve overall project requirements within defined cost, schedule, and technical objectives. Risk has two components: (1) the probability (or likelihood) of a particular outcome and (2) the consequences (or impact) of that outcome. The consequences of risks are typically thought of as negative that may need to be mitigated to minimize the impact to the project. A risk event with positive consequences is referred to as an opportunity that may be captured as a benefit to the project.

SUMMARY LEVEL PLANNING PACKAGE (SLPP): An aggregation of far-term work efforts (scope, schedule, and budget) that are not able to be identified at the control account level but can be distributed to reporting level WBS elements.

Section 2.6 – Term Changes

Section 2.6 “Common Terminology” includes changes/clarifications to existing terms:

ESTIMATE AT COMPLETION (EAC): The current estimated total cost for authorized project work. It equals the cumulative to date Actual Cost of Work Performed (ACWP) plus the estimated costs to complete (Estimate to Complete or ETC) the authorized work remaining.

LEVEL OF EFFORT (LOE): Support type activities that lack measurable output or product that cannot be discretely planned or objectively measured in a practical manner. LOE automatically earns performance with the passage of time, an earned value technique.

MANAGEMENT RESERVE (MR): An amount of the total budget set aside for unplanned, in scope effort that may arise during the course of the project which cannot be identified in advance and is used to handle execution risks. Management reserve budget should be commensurate with the level of project risk. It is not part of the Performance Measurement Baseline (PMB).

OVER-TARGET BASELINE (OTB): A Performance Measurement Baseline (PMB) that exceeds the Contract Budget Base (CBB). It is implemented to produce a realistic schedule and budget plan for the project’s remaining work. It typically requires customer approval to implement.

Section 2.7 – 3 Additional References

Section 2.7 “List of Suggested References” has been updated to include 3 additional references. The complete list is below:

– NDIA IPMD EVMS Intent Guide
– NDIA IPMD IBR Guide
– NDIA IPMD Surveillance Guide
– NDIA IPMD EVMS Acceptance Guide
– NDIA IPMD EVMS Application Guide
– NDIA IPMD Planning and Scheduling Excellence Guide (PASEG)
– NDIA IPMD Industry Practice Guide for Agile on Earned Value Management Programs (New)
– NDIA IPMD Master Definitions List for IPMD Guides (New)
– NDIA IPMD Earned Value Management System Guideline Scalability Guide (New)

Sections 3 thru 5

In Section 3.2.1 WBS Dictionary, discussion regarding segregation by WBS element for direct costs has been removed.

In Section 3.3.1 Control Accounts, discussion regarding guidance that a Control Account shall not span multiple WBS elements has been removed.

In Section 3.3.1, a new figure, Figure 1 – Establishing Control Accounts was added.

In Section 3.4.3 Subcontract/Procurement Schedules, the phrase “high risk” has been removed.

In Section 3.8.2 Cost Performance, The Labor Rate and Efficiency variance calculations were corrected. The corrected equations are below.

• Labor Rate Variance Calculation = Actual Hours x (Earned Rate – Actual Rate)
• Efficiency Variance Calculation = Earned Rate x (Earned Hours – Actual hours)

In Section 3.8.2 Cost Performance, the acronym “EAC” has been replaced with “ETC”.

In Section 3.10.2 Authorized Changes, discussion regarding allowable changes for optimum utility has been removed.

In Section 4 System Documentation, the term “GEIA” has been replaced with “SAE”.

In Section 5.1, Evaluation Process, the term “officer” has been replaced with “authority”.

In summary, EIA 748-D has added/modified a few items for clarification but does not change any of the implementation, reporting, surveillance, or enforcement aspects of Earned Value Management Systems.

Purchase a copy of the standard here: https://www.sae.org/standards/content/eia748d/

EIA 748-D Released – Change Notes Read Post »

Scroll to Top