Agile Application Lifecycle Management (ALM)

of 95 /95
Agile ALM Application Lifecycle Management Dealing with Complexity Jurgen Appelo [email protected] Version 3
  • date post

  • Category


  • view

  • download


Embed Size (px)


Explains how to do Application Lifecycle Management (ALM) in an Agile way.

Transcript of Agile Application Lifecycle Management (ALM)

  • Agile ALM

    Application Lifecycle Management

    Dealing with Complexity

    Jurgen Appelo

    [email protected]

    Version 3

  • Jurgen Appelo writer, speaker, trainer, entrepreneur...

  • Get my new book for FREE!

  • Can Application Lifecycle Management (ALM) work in an environment that grows ever more complex?

    And how does this relate to the first Agile principle, which promotes people over processes and tools?

    ALM: Dealing with Complexity


    Typical software development

  • One small change





    Or to say STOP! We wont change this.

  • The result is a big entangled mess


  • Quasimodo software

    heart of gold, broken body

    Image via Google Search

  • And it doesnt get easier


    Increasing number of technologies


    Increasing levels of globalization

  • Increasing amount of customization

  • Lehmans Laws of Software Evolution

  • Continuing Change Lehmans 1st Law

    A system must be continually adapted or else it becomes progressively less capable of satisfying its users.'s_laws_of_software_evolution

  • Increasing Complexity Lehmans 2nd Law

    As a system evolves its complexity increases unless work is done to reduce it.'s_laws_of_software_evolution

  • Self-Regulation Lehmans 3rd Law

    The system evolution process is self-regulating with product and process measures closely following a normal distribution.'s_laws_of_software_evolution

  • Organizational Stability Lehmans 4th Law

    The average activity rate (maintenance) in an evolving system is invariant over its lifetime.'s_laws_of_software_evolution

  • Conservation of Familiarity Lehmans 5th Law

    As a system evolves all people involved with it must maintain mastery of its content and behavior to achieve satisfactory evolution.'s_laws_of_software_evolution

  • Continuing Growth Lehmans 6th Law

    The functional content of a system must be continually increased to maintain user satisfaction over its lifetime.'s_laws_of_software_evolution

  • Declining Quality Lehmans 7th Law

    The quality of a system will decline unless it is rigorously maintained and adapted to operational environment changes.'s_laws_of_software_evolution

  • Feedback System Lehmans 8th Law

    Evolution processes constitute complex feedback systems and must be treated as such to achieve significant improvement over any reasonable base.'s_laws_of_software_evolution

  • How can we ever deal with all this change?

  • Application Lifecycle Management (ALM)

  • Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance.



  • ALM is a set of disciplines that together govern the process of turning business ideas into software.


    ALM changing to meet development organizations' needs

  • Any tools, technologies, or techniques that attempt to connect and maintain connections between activities over the life of a piece of software from the first glint in the glimmer of an executive's eye, through system retirement.


    Just-enough application lifecycle management (ALM),294698,sid92_gci1396258,00.html


    ALM visualized in models, from bad


    to absolutely terrible.

  • Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

    Conways Law's_Law

  • ALM 1.0

    Separated disciplines Silos of information Fragile integration

  • ALM 2.0

    Single repository Roles and connections One truth


  • Complex Systems

    A complex system is a system composed of interconnected parts that as a whole exhibit one or more properties (behavior) not obvious from the properties of the individual parts.

    Sometimes called the sciences of complexity (plural)

  • General Systems Theory

    Autopoiesis (how a system constructs itself)

    Identity (how a system is identifiable)

    Homeostatis (how a system remains stable)

    Permeability (how a system interacts with its environment)

    Ludwig von Bertalanffy (biologist) 1901-1972

    Study of relationships between elements

  • Cybernetics

    Goals (the intention of achieving a desired state)

    Acting (having an effect on the environment)

    Sensing (checking the response of the environment)

    Evaluating (comparing current state with systems goal)

    Norbert Wiener (mathematician)


    Study of regulatory systems

  • Dynamical Systems Theory

    Stability (stable states versus unstable states)

    Attractors (systems getting sucked into stable states)

    Study of system behavior

  • Game Theory

    Competition versus cooperation

    Zero sum games versus non-zero sum games

    Strategies (including evolutionary stable strategies)

    John von Neumann (mathematician)


    Study of co-adapting systems

  • Evolutionary Theory

    Population (more than one instance)

    Replication (mechanism of making new instances)

    Variation (differences between instances)

    Heredity (differences copied from existing instances)

    Selection (environment imposes selective pressure)

    Charles Darwin (naturalist) 1809-1882

    Study of evolving systems

  • Chaos Theory

    Strange attractors (chaotic behavior)

    Sensitivity to initial conditions (butterfly effect)

    Fractals (scale-invariance)

    Edward Lorenz (meteorologist)


    Study of unpredictable systems

  • And more...

    Dissipative systems (spontaneous pattern-forming)

    Cellular automata (complex behavior from simple rules)

    Genetic algorithms (adaptive learning)

    Social network analysis (propagation of information)

    Study of all kinds of systems

  • The Body of Knowledge of Systems

    Complex systems theory is the study of complex systems using multiple system theories

  • Simplicity: A New Model

    Simple = structure is easily understandable

    Complicated = structure is very hard to understand

    Ordered = behavior is fully predictable

    Complex = behavior is somewhat predictable

    Chaotic = behavior is very unpredictable

    Simplification = making something better understandable

    Linearization = making something more predictable

  • Structure-Behavior Model

    Complex and complicated seen as different dimensions

  • 9 lessons from

    complexity thinking


    Focus on people

    motivation competence


    communication collaboration

  • Expect change

    resilience robustness

  • Support self-organization

    growth alignment

  • Embrace emergence

    no constructionism no predictions

  • Embrace diversity

    adaptability innovation

  • Support decentralization

    delegation empowerment

  • unpredictability, unknowns

  • Heed incompressibility All models are wrong, some are useful

  • People Relationships Change Self-organization Emergence Diversity Decentralization Non-linearity Incompressibility

    One approach to bind them all

  • Agile Software Development

  • An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with "just enough" ceremony that produces high quality solutions in a cost effective and timely manner which meets the changing needs of its stakeholders.


    Agile Modeling

  • Lets start with the good old Iron Triangle

  • Then add some modifications...

    Split Cost (Resources) in People and Tools

    Split Scope in Functionality and Quality (suggestion: Scott Ambler)

    Add a dimension for Process (suggestion: Alistair Cockburn)

    Add a dimension for (Business) Value (suggestion: Jim Highsmith)

  • 1. People

    2. Functionality

    3. Quality

    4. Tools

    5. Time

    6. Value

    7. Process

    And we get...

    the 7 dimensions of software projects

  • People


    collaboration small teams



    self-organization trust



  • Functionality

    customer involvement


    user stories

    acceptance criteria

    minimal marketable features

    user demos

    inch-deep, mile-wide

  • Quality

    technical excellence

    test-driven development

    pair programming

    definition of done

    refactoring emergent design


  • Tools

    daily builds

    continuous integration

    automated testing

    open offices

    task boards

    burn charts

    version control

  • Time




    potentially shippable products

    rolling wave planning

    sustainable pace

    release planning

  • Value

    embracing change


    frequent delivery

    value streams

    value mapping prioritization


  • Process

    stand-up meetings

    planning poker



    collective code ownership


    sprint planning




  • Agile + ALM similarities information sharing better collaboration increased quality higher productivity

  • Agile vs. ALM: differences

    people vs. tools practices vs. techniques

  • Agile ALM

    the best of both, using complexity thinking

  • The typical project is a collection of ideas held in the minds of the people on the project. [] A project is not the sum of all of its documents or even its code. A great deal of the context of a project lies in its participants.

    - Matt Heusser

    Just-enough application lifecycle management (ALM),294698,sid92_gci1396258,00.html

  • 7 tips

    for Agile ALM

  • ALM tools should support high-bandwidth communication, and should not needlessly replace person-person communication with person-tool communication.

    Example: facilitation and storage of photos, audio, video.

    1. High-Bandwidth Communication

  • ALM tools must natively support all common Agile practices.

    Example: user stories, acceptance testing, iterative planning, continuous flow, unit testing, refactoring, automated builds, continuous integration, etc

    2. Agile Best Practices

  • The ALM infrastructure must be selected, built and maintained by the team(s) themselves. Nothing should be mandated by those who dont have to work with it.

    Example: a team can select its own favorite automatic build system or Agile planning tools.

    3. Bottom-Up Infrastructure

  • A healthy ALM strategy will allow for multiple vendors of tools. The benefits of specialization (of tools) often outweighs the cost of integration. There is no single truth.

    Example: use Visual Studio Team System except source control.

    4. Multi-Vendor Approach

  • ALM tools should aim for accessibility. The goal is collaboration, not centralization. Information should be radiated, not concentrated.

    Example: status updates on whiteboard and in task tracking tool.

    5. Distributed Information

  • Modeling of processes is a form of prediction, and thus unreliable. Allow for emergent design of the ALM infrastructure. Grow it in an Agile way.

    Example: use a continuous improvement backlog for the ALM infrastructure.

    6. Agile Improvement

  • ALM tools must be extensible, customizable and adaptable, so that they can grow together with the project.

    Example: open APIs, web services, plug-ins, widgets, macros, etc.

    7. Adaptable Tools

  • Agile ALM 1. High-Bandwidth Communication

    2. Agile Best Practices

    3. Bottom-up Infrastructure

    4. Multi-Vendor Approach

    5. Distributed Information

    6. Agile Improvement

    7. Adaptable Tools

  • Application lifecycle management (Wikipedia)

    Mea culpa, ALM toolmakers say (SD Times)

    ALM changing to meet development organizations' needs (SearchSoftwareQuality),289142,sid92_gci1259517_mem1,00.html

    Application Lifecycle Management Gets Agile (ITBusinessEdge)

    What is Agile ALM? (Ezine Articles)

    Agile ALM Opposites Attract (CM Crossroads)

    What is the definition of Application Lifecycle Management (ALM)? (IT Knowledge Exchange)


  • Just-enough application lifecycle management (ALM) (SearchSoftwareQuality),294698,sid92_gci1396258,00.html

    ALM and Agile (RedMonk)

    Top 7 Key Requirements of an Agile ALM Platform (Top7Business)

    Does Application Lifecycle Management (ALM) add Value or Hinder the Adoption of Agile-Lean Product Development? (AgileJournal)

    What exactly is an ALM tool (SearchSoftwareQuality),289625,sid92_gci1523524,00.html

    Getting Started with Agile ALM (Manning)


  • @jurgenappelo

    [email protected]


    This presentation was inspired by the works of many people, and I cannot possibly list them all. Though I did my very best to attribute all authors of texts and images, and to recognize any copyrights, if you think that anything in this presentation should be changed, added or removed, please contact me at [email protected]