big

NOOP.NL | The Creative Networker

The Big List of Agile Practices

06/04/2009

Noose
This post is probably going to be hated and loved at the same time. Because, when people talk about agile practices, they can sometimes become very religious. Which means I may be putting my head in a noose with this one.

But who cares. It's worth it. I like living dangerously.

You see, at different occasions I had wanted the availability of  a big list of agile practices. But I never found any. All common agile practices are spread out over different methods, and many different sites. That's why I decided to create my own list.

Disclaimer: the list below is definitely incomplete, and probably controversial!

I constructed the list below from practices found on eight different web sites. I ignored some well-known agile concepts like "keep it simple" and "remove waste" because I consider those to be principles, not practices. I also ignored some practices when I had the feeling that they were only listed on one site, and nobody else was using them. While on the other hand, I listed some practices here that some people do not consider to be truly agile. But I included them nonetheless, when I noticed that they are regularly being used in an agile context.

If you disagree with the list, or if you think some practices are missing, please let me know!

You see, I am considering to use this list for a poll on agile practices and how they are being applied. And I hope you're willing to help me in getting this list in order before conducting such a poll.

Thanks already!

Requirements                
Product Vision / Vision Statement  
SA
      JS    
Product Backlog  
SA

MG
         
User Stories Wiki
SA
  C2
AM
 
XP
 
Use Cases Wiki     C2
AM
 
XP
 
Usage Scenarios        
AM
     
Personas Wiki      
AM
     
Planning Poker Wiki              
Requirement Prioritization
Wiki
     
AM
     
Design                
Architectural Spikes / Spike Solutions       C2     XP  
Domain Driven Design Wiki             IXP
Emergent Design / Evolutionary Design Wiki     C2       IXP
CRC Cards
Wiki
     
AM
 
XP
 
Design by Contract Wiki              
System Metaphor            
XP
 
Construction                
Coding Style / Coding Guidelines / Coding Standard Wiki        
JS
  IXP
Test Driven Development
Wiki
    C2    
XP
 
Behavior Driven Development
Wiki
             
Pair-Programming / Pairing Wiki     C2  
JS
XP IXP
Refactoring Wiki     C2    
XP
IXP
Collective Code Ownership       C2  
JS

XP
IXP
Daily Builds / Automated Builds / Ten-Minute Builds Wiki        
JS
   
Continuous Integration
Wiki
    C2  
JS

XP
IXP
Code Reviews / Peer Reviews Wiki              
Software Metrics / Code Metrics & Analysis Wiki              
Source Control / Version Control Wiki        
JS
   
Issue Tracking / Bug Tracking Wiki              
Configuration Management
Wiki
             
Frequent Delivery / Frequent Releases       C2    
XP
IXP
Testing                
Unit Testing Wiki          
XP
 
Smoke Testing / Build Verification Test Wiki              
Integration Testing Wiki              
System Testing Wiki              
Exploratory Testing Wiki              
Test Automation Wiki
SA
           
Storytesting / Acceptance Criteria / Acceptance Testing Wiki     C2
AM
 
XP
IXP
Process                
Timeboxing / Fixed Sprints / Fixed Iteration Length Wiki          
XP
 
Release Planning       C2  
JS

XP
 
Iteration Planning / Planning Game / Sprint Planning
Wiki

SA

MG
C2  
JS

XP
IXP
Sprint Backlog  
SA
MG          
Task Board  
SA
MG          
Definition of Done / Done Done  
SA
      JS    
Daily Stand-up Meeting / Daily Scrum Wiki
SA
MG C2  
JS

XP
 
Velocity            
XP
 
Sprint Review / Iteration Demo  
SA

MG
   
JS
   
Value Stream Mapping Wiki              
Root Cause Analysis / 5 Whys Wiki        
JS
   
Burn Down Charts / Burn Up Charts Wiki
SA

MG
         
Big Visible Charts / Information Radiators          
JS
   
Retrospective / Reflection Workshop Wiki
SA
     
JS
  IXP
Organization                
Small Team               IXP
Cross-Functional Team Wiki              
Self-Organizing Team / Scrum Team     MG          
Colocated Team / Sitting Together / Common Workspace Wiki
SA
  C2   JS   IXP
On-Site Customer / Product Owner  
SA
MG C2  
JS
   
Scrum Master  
SA
MG          
Sustainable Pace               IXP
Move People Around            
XP
 
Scrum of Scrums  
SA
           

References
Wiki = Wikipedia
SA = Scrum Alliance
MG = Mountain Goat Software
C2 = Cunningham & Cunningham
AM = Agile Modeling
JS = James Shore
XP = Extreme Programming
IXP = Industrial XP

(picture by the toe stubber)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
OK, Maybe Prince2 Sucks Less Than I Thought
Team Members, Be Predictable!
How to Handle Many Simultaneous Projects

This article is written by on in Top Lists. Jurgen Appelo is at Happy Melly. Connect with Jurgen Appelo on .

This article was posted in:

  • http://www.davenicolette.net/agile Dave Nicolette

    Nice list. I especially like the links.
    Possible additions to consider:
    Requirements
    ————
    Real Options
    Executable Requirements (cross ref with Storytesting under “testing”)
    Construction
    ————
    Software Craftsmanship
    Process
    ——-
    Kanban
    Organization
    ————
    Generalizing Specialist
    Integration of app dev/support with business units
    Cheers,
    Dave

  • http://www.betterprojects.net Craig

    My comment is on sources. Cockburns website is a great source of info across many methods.

  • http://tomekdab.blogspot.com/ Tomek Dabrowski

    I like this list :) I’m aware of most of them but I haven’t realized this since I read your post :)

  • http://profile.typepad.com/mcherm Michael Chermside

    Another practice I have seen frequently is one I would title “Story Points“. This is the practice of doing effort estimates in an arbitrary units rather than in hours or person-days. Typically a certain reference story will be used to define one particular size, and this is often used in conjunction with “Planning Poker” (which you already listed) for obtaining rapid estimates.
    Proponents claim that one advantage is that developers are less likely to underestimate (by assuming nothing unexpected will arise) when they compare one task to another than when they estimate how long it will take them. And customers have an easier time realizing that estimates may be imprecise if they are expressed in an unfamiliar unit.

  • Calin Pop

    http://www.abetterteam.org/ – a cool site that has a quiz where you can measure your team “agility”

  • Mattias Forsberg

    Really interesting list.
    Please consider adding Tracer Bullet Development, more in detail described in “Ship It!” by Jared Richardson and William Gwaltney Jr.

  • http://adfg.com adfg

    When I read posts like this I just see a bunch of fluff that isn’t helping me get my project done in a timely fashion, only serving as a distraction.

  • http://www.tomaszlasica.net/it Tomasz Łasica

    I would suggest adding peer code reviews as an alternative to xp pair programming.

  • http://pm-software.org Bjoern Linder

    Thanks for that list. That’s what I looked for.
    My next thougths are about how to use this practices in “my specific project”. Which practicecs adding value to my project and which not? How can I tailor the list as a project manager? What do I have to consider in the pre-game phase? Any ideas or references?

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Hi Bjoern,
    I don’t know how to answer your question.
    It seems like you’re asking for a reference to all agile books and all web sites available. The info you’re looking for is all over the place!
    Maybe here’s a good place to start…
    http://www.noop.nl/2008/06/top-20-best-agile-development-books-ever.html

  • http://www.xing.com/profile/Bjoern_Linder Bjoern Linder

    Hi Jurgen,
    thanks for your answer. I think I need to describe the topic in more detail. My starting point is a question you’ve asked yourself: Hot Issues – Scrum vs.. RUP, XP, Kanban, etc. in “The Zen of Scrum”.
    I have this problem in my company, where we get many different influences through our customers, so we have many different approaches in our projects (Waterfall, RUP, SCRUM, Lean). I think that in general “Practices” are an appropriate means to compare the different approaches to identify commonalities e.g. Timeboxing -> SCRUM, RUP.
    I’m not sure how a company should deal with many diffenrent approaches. Either I commit to only one approach (eg SCRUM) and try to map it to all project types and situations, or I create a set of loose-coupled “Practices”. The set of “Practices” then must be tailored to the particular project context (size, contract type, project type, etc.) in the pre-game phase. For example, should I use Use Cases (formal projects) or user stories (internal product development)?
    I found only a little to this subjecton on the Internet. Maybe someone is more in this topic. Maybe a direct question: What do you use in your business? Only scrum, or a mixture of different approaches?

  • http://profile.typepad.com/jurgenappelo Jurgen Appelo

    Bjoern, I believe there is no easy answer to your question. It is like asking “what is the best species to survive in this environment”? You’ll just have to experiment and see.
    In my current project we use a bit of Scrum, a bit of Kanban, and some XP practices. We keep tweaking and figure out what works for us as we go.

  • http://www.xing.com/profile/Bjoern_Linder Bjoern Linder

    Hi Jurgen,
    thats actually what I am doing right now. In my opinion it makes no sense to stick with just Scrum. My goal is to enable project managers to select the right practices for their specific project from a broad range. In the future it would be nice to have a single website containing all available practices. Thanks for your response!

  • Anon

    I suggest Story Trees and Story Mapping.

  • http://blog.abalmasov.com/ Artem Abalmasov

    Thank you for the list. You’ve done a great job.