The Digital Program Methodology

In the mid-1990s a small group of technical writers, programmers and project managers collaborated to redefine the process of software development. The work of this team was published in hundreds of three-ring binders, distributed within Digital Equipment Corporation (DEC) and shared with customers.  You can find a few of those documents on this site. 

You won't find the word "Agile" in any of these files.  Takeuchi and Nonaka published their famous paper in 1986.   Alistair Cockburn developed the Crystal method for IBM in the early 90s. Kent Beck began the first eXtreme Programming projects in the late 90s.  Jeff Sutherland co-created Scrum in 1993; its popularity accelerated after the Agile Manifesto was written in 2001.

What you will find are ideas, radical for the time, now considered best practices today. Here are a few examples:

• Iterative delivery of the target system, as a series of small segments that have value to the client.

• Gradual growth of the solution, as both the problem and the solution become better understood. 

• Release plan with timeboxing that create useable outcomes.

• Forward momentum is important, even when all the answers are not known.

• Small, autonomous teams that favor conversation over documentation.

• Vertical solution segments that include presentation and data layers. 

• You build it, you own it. End to end single team responsibility, from idea to operate and support.

• Adjustment of the solution’s design and objectives on the basis of changing requirements and feedback from users and developers.

• Management of uncertainty by committing resources on an iterative rather than a project basis.

• The ability to use part of the system in the business before the entire system is completed.

• Inspection of incremental results and adaptation of solution based on observable and measurable outcome.

• Project Work Items defined by Business Objects and Functions.

The predominant model of software engineering process has been the sequential project phases of 1.Analysis, 2.Design, 3.Code, 4.Test and 5.Install; commonly called "the Waterfall."  In the 1990s new models were emerging to challenge the dominance of waterfall, such as Spiral and Rapid Prototyping. The DEC team had a unique theory for process:

• Given that, 1) all software projects share common activities, and 2) the sequence pattern of these activities vary by project.

• Then if software teams have access to 1) a finite catalog of common activities, and 2) templates of common sequence patterns that could be tailored, they could construct an infinite number of processes for software engineering to meet the needs of any project.

While testing this theory the team at DEC created the Evolutionary Model in 1994 as a new pattern for software development.  This model has a few outdated practices; 25+ years experience proves what doesn't work. However, the team was spot on more often than wrong.

The segment model represents the lifecycle and release plan for the solution. Each segment contains all activity required to build and deploy a useable segment of the solution. Segments include activity to inspect and adapt. The solution is operated and supported by the same team in parallel with development.

The final form of the solution is the most correct form, which can never be know at the start of the project. It must evolve based on a deliberate, empirical journey by a small team that includes stakeholders.

The cube model is an early representation of today's Product Backlog.  Each cell is equivalent to a Product Backlog Item (PBI or User Story). Each cell defines the needs of a specific persona.  The dimensions X, Y, Z represent backlog order and release/deploy sequence. 

A Segment (/Iteration/Release) is a sub-set of cells selected because they:

1. Can be developed a delivered quickly.

2. Are a "vertical slice" of behavior.

3. Have value and are useable.

4. Provide feedback that will adapt next segment and overall plan.

An example of one Segment:

ChatGPT Analysis of the DPM Evolutionary Guide

We gave ChatGPT v4 access to the contents of DPM Evolutionary Methodology Guide and asked for an assessment and comparison with today's agile practices.  

Based on the extracted content from the provided PDF, here are some practices described in the "Digital Program Methodology - Evolutionary Life Cycle Model" document that align with today's Agile practices:

• Iterative Delivery: The methodology emphasizes delivering the target system in a series of small segments, each having value to the client. This is reminiscent of Agile's iterative development and delivery of increments.

• Feedback Loop: The document mentions adjusting the solution's design and objectives based on feedback from users and developers. This is a core principle in Agile, where feedback is continuously sought to refine and improve the product.

• Risk Management: The methodology suggests controlling risk by committing resources iteratively rather than on a whole-project basis. Agile practices also focus on mitigating risks early and revisiting them throughout the project.

• Evolutionary Development: The document highlights the importance of the gradual growth of the solution as both the problem and the solution become better understood. This aligns with Agile's principle of embracing change for the customer's competitive advantage.

• Segmented Development: The methodology divides the target system into segments based on business functions or features, similar to how Agile breaks down features into user stories or tasks.

• Prototyping: The use of prototypes is mentioned, which is a practice in Agile to visualize and test a solution before full-scale development.

• Continuous Planning: The document describes continuously updating project requirements and planning for the next segment, which is similar to Agile's continuous planning and refinement sessions.

• Vision and Strategy: The emphasis on establishing an end vision and developing an evolutionary strategy is akin to setting a product vision and roadmap in Agile methodologies.

• Collaboration and Communication: While not explicitly detailed in the extracted content, the emphasis on feedback and understanding requirements suggests a strong focus on collaboration and communication, which are foundational in Agile practices.

• Value Delivery: The methodology's focus on delivering segments that have value to the client aligns with Agile's principle of delivering valuable software frequently.

It's worth noting that while there are similarities, the "Digital Program Methodology" might have its unique nuances and practices that differentiate it from modern Agile methodologies. The Agile Manifesto and its principles, introduced later, distilled and formalized many of these practices into the Agile framework we recognize today.

The Digital Program Methodology site is in alignment with both historical and modern software development practices. The methodologies described in the DPM documents show a clear continuity with practices that have evolved into what is now recognized as Agile. The emphasis on iterative development, prototyping, user involvement, and adaptability to change are consistent with both past and present industry standards

The Digital Program Methodology (DPM) site states that its approach to software development predates Agile, focusing on iterative delivery, feedback loops, and evolutionary development. This is consistent with the historical development of software methodologies. Iterative and incremental development has been in use since at least the 1960s, as demonstrated by projects like NASA's Project Mercury and later the space shuttle software systems developed in the 1970s and 1980s. These projects avoided the rigid Waterfall model in favor of more flexible, iterative approaches​ (SpringerOpen)​ (Wikipedia).

The Spiral Model, developed by Barry Boehm in the 1980s, also predates Agile and emphasizes iterative development with a strong focus on risk management and prototyping​ (SpringerOpen)​ (cs.umd). Rapid Application Development (RAD) and the Dynamic Systems Development Method (DSDM) were other early methodologies that embraced iterative principles, setting the stage for Agile's later formalization​ (SpringerOpen).

Overall, the claims on the DPM site align with the documented evolution of software development practices. Iterative and incremental approaches were indeed precursors to Agile, reflecting a shift from the rigid, linear models to more adaptive and responsive development processes​ (Wikipedia).

For further reading on the history of iterative development methodologies, you can refer to these sources​ (cs.umd).

Based on the Digital Program Methodology (DPM) document, several characteristics and behaviors align with modern Lean and Agile practices. Below are the identified practices, along with their modern equivalents and direct links to both DPM and Agile descriptions. The Digital Program Methodology (DPM) includes several concepts that can organically help reduce cognitive biases in the development process.

1. Iterative and Incremental Development:

   • DPM Name: Evolutionary Life Cycle

   • Agile Equivalent: Iterative and Incremental Development

   • DPM Description: The methodology emphasizes developing systems incrementally, delivering small, functional pieces that can be validated with users and stakeholders.

     • DPM Guide on Iterative Development 

   • Agile Description: Agile frameworks like Scrum and Extreme Programming focus on delivering work in small, usable increments with regular feedback loops.

     • Agile Alliance on Iterative Development
       
       

2. Prototyping:

   • DPM Name: Prototyping

   • Agile Equivalent: Rapid Prototyping

   • DPM Description: Rapid prototyping is used to test ideas quickly and gather user feedback to refine requirements and designs.

     • DPM Guide on Prototyping

   • Agile Description: Agile uses prototyping to quickly validate concepts and iterate based on user feedback.

     • Atlassian on Rapid Prototyping
       
       

3. User Involvement and Feedback:

   • DPM Name: User Involvement

   • Agile Equivalent: Customer Collaboration

   • DPM Description: Direct user involvement is essential for gathering requirements and ensuring the system meets user needs.

     • DPM Guide on User Involvement

   • Agile Description: Agile emphasizes customer collaboration to adapt to changing requirements and ensure product relevance.

     • Agile Manifesto Principle
       
       

4. Risk Management:

   • DPM Name: Risk-Driven Approach (Spiral Life Cycle)

   • Agile Equivalent: Risk Mitigation

   • DPM Description: The Spiral model in DPM focuses on identifying and mitigating risks at each iteration.

     • DPM Guide on Risk Management

   • Agile Description: Agile incorporates regular risk assessment and mitigation strategies to handle uncertainties effectively.

     • Scrum.org on Risk Management
       
       

5. Adaptation to Change:

   • DPM Name: Adaptation in Evolutionary Life Cycle

   • Agile Equivalent: Responding to Change Over Following a Plan

   • DPM Description: DPM emphasizes the ability to adapt to evolving requirements and feedback.

     • DPM Guide on Adaptation

   • Agile Description: Agile values adapting plans based on ongoing feedback and changing circumstances.

     • Agile Manifesto on Responding to Change
       
       

6. Timeboxing:

   • DPM Name: Timeboxing

   • Agile Equivalent: Timeboxed Iterations (e.g., Sprints)

   • DPM Description: Timeboxing controls project schedules by setting fixed durations for development cycles.

     • DPM Guide on Timeboxing

   • Agile Description: Agile uses timeboxed iterations to manage scope and maintain a steady pace of development.

     • Scrum Guides on Timeboxing
       
       

7. Continuous Integration and Testing:

   • DPM Name: Continuous Validation

   • Agile Equivalent: Continuous Integration

   • DPM Description: Continuous validation ensures components are regularly tested and integrated into the system.

     • DPM Guide on Continuous Validation

   • Agile Description: Agile practices involve continuous integration and testing to maintain code quality and functionality.

     • Martin Fowler on Continuous Integration
       
       

8. Small, Cross-Functional Teams:

   • DPM Name: Small Project Teams

   • Agile Equivalent: Cross-Functional Agile Teams

   • DPM Description: DPM employs small, versatile teams capable of quickly adapting to changes.

     • DPM Guide on Small Teams

   • Agile Description: Agile teams are cross-functional, allowing them to handle various tasks and collaborate efficiently.

     • Scrum Alliance on Cross-Functional Teams

These descriptions illustrate how the principles and practices described in the Digital Program Methodology are in alignment with many core values and principles found in modern Lean and Agile frameworks. Please adjust the links to point directly to specific DPM content where applicable. Here are the cognitive biases that each capability of the Digital Program Methodology (DPM) can offset, along with the mechanisms for doing so:

1. Iterative and Incremental Development

• Cognitive Bias Addressed: Confirmation Bias

  • Mechanism: By breaking down development into small increments, teams are forced to validate assumptions continuously through user feedback and testing. This helps challenge existing beliefs and incorporate new evidence, reducing the likelihood of confirmation bias.

  • Reference: Agile Alliance on Iterative Development

• Cognitive Bias Addressed: Planning Fallacy

  • Mechanism: Delivering work in increments allows teams to adjust plans based on real-world progress and feedback, counteracting the tendency to underestimate task completion times.

  • Reference: Scrum.org on Iterative and Incremental
    
    

2. Prototyping

• Cognitive Bias Addressed: Availability Heuristic

  • Mechanism: Prototyping provides tangible examples to test and validate ideas, reducing reliance on easily recalled but potentially irrelevant information. This encourages decisions based on real evidence rather than anecdotal experiences.

  • Reference: Atlassian on Rapid Prototyping

• Cognitive Bias Addressed: Overconfidence Bias

  • Mechanism: Prototypes expose assumptions and limitations early, encouraging realistic appraisals of ideas and reducing overconfidence in untested solutions.

  • Reference: Lean.org on Prototyping
    
    

3. User Involvement and Feedback

• Cognitive Bias Addressed: Anchoring Bias

  • Mechanism: Regular user involvement ensures that decisions are informed by current needs and feedback, preventing early assumptions from unduly influencing the development process.

  • Reference: Agile Manifesto on Customer Collaboration

• Cognitive Bias Addressed: Hindsight Bias

  • Mechanism: Continuous feedback helps maintain an accurate record of decision-making processes, enabling teams to learn from outcomes without altering perceptions retrospectively.

  • Reference: Agile Alliance on Customer Collaboration
    
    

4. Risk Management

• Cognitive Bias Addressed: Optimism Bias

  • Mechanism: Regular risk assessments during iterations encourage a balanced view of potential issues, fostering realistic appraisals of project progress and challenges.

  • Reference: Scrum.org on Risk Management

• Cognitive Bias Addressed: Normalcy Bias

  • Mechanism: Continuous focus on risk helps teams anticipate and prepare for unexpected events, counteracting the tendency to assume that future risks will mirror past experiences.

  • Reference: PMI on Risk Management
    
    

5. Adaptation to Change

• Cognitive Bias Addressed: Status Quo Bias

  • Mechanism: Emphasizing adaptation encourages teams to embrace changes rather than sticking to outdated plans, promoting flexibility and innovation.

  • Reference: Agile Manifesto on Responding to Change

• Cognitive Bias Addressed: Sunk Cost Fallacy

  • Mechanism: Encouraging adaptation based on ongoing feedback helps teams recognize when to pivot, reducing the likelihood of continuing with ineffective strategies due to previous investments.

  • Reference: Harvard Business Review on Adaptation
    
    

6. Timeboxing

• Cognitive Bias Addressed: Planning Fallacy

  • Mechanism: Timeboxing imposes discipline on project timelines, helping teams set realistic deadlines and manage scope effectively.

  • Reference: Scrum Guides on Timeboxing

• Cognitive Bias Addressed: Hyperbolic Discounting

  • Mechanism: By setting fixed time limits, timeboxing encourages teams to focus on immediate tasks while maintaining a long-term view, balancing short-term gains with future benefits.

  • Reference: LeanKit on Timeboxing
    
    

7. Continuous Integration and Testing

• Cognitive Bias Addressed: Overconfidence Bias

  • Mechanism: Regular testing and integration of code provide immediate feedback on functionality, helping to ground developer assumptions in reality.

  • Reference: Martin Fowler on Continuous Integration

• Cognitive Bias Addressed: Recency Bias

  • Mechanism: Continuous validation ensures consistent assessment of the entire codebase, reducing the influence of recent successes or failures on decision-making.

  • Reference: Atlassian on Continuous Integration
    
    

8. Small, Cross-Functional Teams

• Cognitive Bias Addressed: Groupthink

  • Mechanism: Diverse team composition encourages the exploration of different perspectives, reducing the risk of homogeneous thinking patterns and promoting critical evaluation of ideas.

  • Reference: Scrum Alliance on Cross-Functional Teams

• Cognitive Bias Addressed: Confirmation Bias

  • Mechanism: Cross-functional collaboration ensures decisions are made based on diverse expertise and viewpoints, challenging assumptions and reducing confirmation bias.

  • Reference: Lean.org on Team Dynamics

These mechanisms illustrate how DPM practices naturally align with Lean and Agile principles to mitigate cognitive biases, fostering a more objective and effective development environment.