Agile ALM

Application Lifecycle Management

Dealing with Complexity

Jurgen Appelo

jurgen@noop.nl

Version 3 http://www.flickr.com/photos/poppacket/4290209522/

Jurgen Appelo writer, speaker, trainer, entrepreneur... www.jurgenappelo.com

Get my new book for FREE! m30.me/ss

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

http://www.flickr.com/photos/futureshape/4000128011/

Typical software development

One small change

http://www.flickr.com/photos/laszlo-photo/1899390628/

http://www.flickr.com/photos/schanlaub/5102055360/

http://www.flickr.com/photos/mcfarlandmo/3275420128/

http://www.flickr.com/photos/jngelvezon/3544740238/

http://www.flickr.com/photos/soamplified/4862757831/

Or to say STOP! We won’t change this.

The result is a big entangled mess

http://www.flickr.com/photos/hryckowian/2029393648/

http://www.flickr.com/photos/kevinkrejci/3065365140/

Quasimodo software

heart of gold, broken body

Image via Google Search

And it doesn’t get easier…

http://www.flickr.com/photos/steelmore/221737671/

http://www.flickr.com/photos/hinkelstone/2435823037/

Increasing number of technologies

http://www.flickr.com/photos/foxspain/3219577797/

Increasing levels of globalization

Increasing amount of customization

http://www.flickr.com/photos/pmiaki/4566582179/

Lehman’s Laws of Software Evolution

http://www.flickr.com/photos/pagedooley/1825685405/

Continuing Change Lehman’s 1st Law

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

http://www.flickr.com/photos/untitlism/2609684221/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Increasing Complexity Lehman’s 2nd Law

“As a system evolves its complexity increases unless work is done to reduce it.”

http://www.flickr.com/photos/hinkelstone/2765597758/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Self-Regulation Lehman’s 3rd Law

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

http://www.flickr.com/photos/jurvetson/2323537118/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Organizational Stability Lehman’s 4th Law

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

http://www.flickr.com/photos/zyllan/4880446208/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Conservation of Familiarity Lehman’s 5th Law

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

http://www.flickr.com/photos/kevinpoh/3586321697/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Continuing Growth Lehman’s 6th Law

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

http://www.flickr.com/photos/randysonofrobert/376221775/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Declining Quality Lehman’s 7th Law

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

http://www.flickr.com/photos/reinante/4413913423/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

Feedback System Lehman’s 8th Law

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

http://www.flickr.com/photos/pixel_addict/465394708/

http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution

How can we ever deal with all this change?

http://www.flickr.com/photos/pagedooley/2845763884/

Application Lifecycle Management (ALM)

http://www.flickr.com/photos/denisecarbonell/3923601326/

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

Definition(s)

Wikipedia http://en.wikipedia.org/wiki/Application_lifecycle_management

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

Definition(s)

“ALM changing to meet development organizations' needs” http://en.wikipedia.org/wiki/Application_lifecycle_management

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

Definition(s)

“Just-enough application lifecycle management (ALM)” http://searchsoftwarequality.techtarget.com/news/column/0,294698,sid92_gci1396258,00.html

http://en.wikipedia.org/wiki/File:ALM.svg

ALM visualized in models, from bad…

http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1259517_mem1,00.html

…to absolutely terrible.

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

Conway’s Law

http://www.flickr.com/photos/jeanlouis_zimmermann/570332025/

http://en.wikipedia.org/wiki/Conway's_Law

ALM 1.0

Separated disciplines Silos of information Fragile integration

http://www.flickr.com/photos/eirikref/727551264/

ALM 2.0

Single repository Roles and connections “One truth”

http://www.flickr.com/photos/sudhamshu/4379880762/

http://www.flickr.com/photos/f-oxymoron/5005673112/

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)

http://cfpm.org/pub/users/bruce/thesis/chap4.pdf

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 system’s goal)

Norbert Wiener (mathematician)

1894-1964

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)

1903-1957

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)

1917-2008

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

http://www.noop.nl/2010/09/simplicity-a-new-model.html

Complex and complicated seen as different dimensions

9 lessons from

complexity thinking

http://www.flickr.com/photos/stevon/3577915624/

http://www.flickr.com/photos/arcticpuppy/2943901683/

Focus on people

motivation competence

http://www.flickr.com/photos/linhngan/3101950593/

communication collaboration

Expect change

http://www.flickr.com/photos/jenny-pics/3602368875/

resilience robustness

Support self-organization

growth alignment

http://www.flickr.com/photos/oth313/2084783266/

Embrace emergence

no constructionism no predictions

http://www.flickr.com/photos/hamed/428063513/

Embrace diversity

adaptability innovation

http://www.flickr.com/photos/meanestindian/478935037/

Support decentralization

delegation empowerment

http://www.flickr.com/photos/zooboing/4743616313/

unpredictability, unknowns

http://www.flickr.com/photos/pagedooley/4099585916/in/photostream/

Heed “incompressibility” All models are wrong, some are useful

http://www.flickr.com/photos/speckham/3885641714/

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

One approach to bind them all… http://www.flickr.com/photos/gladius/2332020850/

Agile Software Development http://www.flickr.com/photos/sidelong/2909952599/

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

Definition

Agile Modeling http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

Let’s 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)

http://www.ambysoft.com/essays/brokenTriangle.html http://alistair.cockburn.us/index.php/Process:_the_fourth_dimension http://blog.cutter.com/2009/08/10/beyond-scope-schedule-and-cost-measuring-agile-performance/

1. People

2. Functionality

3. Quality

4. Tools

5. Time

6. Value

7. Process

And we get...

the 7 dimensions of software projects

People

interaction

collaboration small teams

cross-functional

colocation

self-organization trust

accountability

respect

Functionality

customer involvement

backlogs

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

simplicity

Tools

daily builds

continuous integration

automated testing

open offices

task boards

burn charts

version control

Time

timeboxes

iterations

sprints

potentially shippable products

rolling wave planning

sustainable pace

release planning

Value

embracing change

feedback

frequent delivery

value streams

value mapping prioritization

increments

Process

stand-up meetings

planning poker

velocity

spikes

collective code ownership

retrospectives

sprint planning

http://www.versionone.com/state_of_agile_development_survey/10/

http://www.versionone.com/state_of_agile_development_survey/10/

http://www.versionone.com/state_of_agile_development_survey/10/

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

http://www.flickr.com/photos/ananth/279721111/

Agile vs. ALM: differences

people vs. tools practices vs. techniques

http://www.flickr.com/photos/thebusybrain/2492945625/

Agile ALM

the best of both, using complexity thinking

http://www.flickr.com/photos/batega/1865482908/

“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)” http://searchsoftwarequality.techtarget.com/news/column/0,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 don’t 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 API’s, 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

http://www.flickr.com/photos/untitlism/2603959306/

Application lifecycle management (Wikipedia)

http://en.wikipedia.org/wiki/Application_lifecycle_management

Mea culpa, ALM toolmakers say (SD Times)

http://www.sdtimes.com/link/31952

ALM changing to meet development organizations' needs (SearchSoftwareQuality)

http://searchsoftwarequality.techtarget.com/news/article/0,289142,sid92_gci1259517_mem1,00.html

Application Lifecycle Management Gets Agile (ITBusinessEdge)

http://www.itbusinessedge.com/cm/blogs/vizard/application-lifecycle-management-gets-agile/?cs=39865

What is Agile ALM? (Ezine Articles)

http://ezinearticles.com/?What-is-Agile-ALM?&id=3948403

Agile ALM – Opposites Attract (CM Crossroads)

http://www.cmcrossroads.com/cm-journal-articles/13601-agile-alm-opposites-attract

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

http://itknowledgeexchange.techtarget.com/software-quality/what-is-the-definition-of-application-lifecycle-management-alm/

Sources

Just-enough application lifecycle management (ALM) (SearchSoftwareQuality)

http://searchsoftwarequality.techtarget.com/news/column/0,294698,sid92_gci1396258,00.html

ALM and Agile (RedMonk)

http://www.redmonk.com/cote/2006/12/04/alm-and-agile/

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

http://top7business.com/?id=15513

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

http://www.agilejournal.com/articles/columns/column-articles/3326-does-application-lifecycle-management-alm-add-value-or-hinder-the-adoption-of-agile-lean-product-development

What exactly is an ALM tool (SearchSoftwareQuality)

http://searchsoftwarequality.techtarget.com/expert/KnowledgebaseAnswer/0,289625,sid92_gci1523524,00.html

Getting Started with Agile ALM (Manning)

http://www.manning.com/huettermann/

Sources

@jurgenappelo

slideshare.net/jurgenappelo

noop.nl

linkedin.com/in/jurgenappelo

jurgen@noop.nl

http://creativecommons.org/licenses/by-nd/3.0/

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 jurgen@noop.nl.