Monday, April 6, 2009

My Custom Agile Flashcards

In a previous post I mentioned how impressed I was by the concept of Agile Flashcards, I started to put together some of my own flashcards to reflect on some of the best practices that I use on my projects. Here they are below:

Domain Driven Design

by Eric Evans

  • Articulate and encapsulate the business logic of the system into one or more software models

  • Organize and abstract the knowledge of multiple business SMEs, partitioning business logic into:

    • Entities

    • Value Objects

    • Aggregates

    • Repositories

    • Factories

    • Services

    • Specifications

  • Refactor the model to reflect the realities and limitations of the target technical platform (avoid ivory tower models)

  • Build a model that both technology and business can understand, providing a Ubiquitous Language for the project

Agile Documentation

by Scott Ambler


When the Business Asks you to

For Clarity Across Teams working in different locations

To establish appropriate business and technical Context for the solution

To define Interfaces across systems

To Enable your Next Effort


To Understan

To Communicate

Don’t Document...

To Specify

Because your Process Says So

Unproven ideas (prototype it first)

Without obtaining the structure from your Intended Audience

Without Considering Maintenance and cost of ownership

Implementation and Design Details that can be just as easily expressed in the solution itself

Essential Documents

Operations and Support

Developer Setup & Manuals

User Manuals

Delivery Plan

Phases of a Product Based Lifecycle

Lightly apply the concepts of a product based SDLC lifecycle on large-scale, enterprise projects...

  • Inception generate a vision, build the business case and obtain funding

  • Elaboration address technical risks, clarify on certain requirements, experiment and prototype, and build the foundation

  • Construction expand the team, run the assembly line, and manufacture the complete solution

  • Transition train users, transition to operations, and hand over the solution

Remember that contributions from a combination of disciplines (requirements, design, build, test, etc.) are required in some shape or form through all phases of the lifecycle

Enterprise Stakeholders

On large projects extend the typical agile definition of a product owner to include the following stakeholders:

  • Operations Manager

  • Enterprise Architects

  • Developer Teams dependent on code you are building

Be sure to solicit their input when defining requirements for the system.

Agile Modeling

by Scott Ambler

Software modeling can be incredibly useful, but models are expensive to create, and incredibly expensive to maintain.To maximize ROI,


  • To communicate an idea

  • To understand the concept

  • Using Collaborative Techniques like CRC Cards

Don’t Model...

  • Without an audience in mind

  • Just because your process says so

Focus Modeling on...

  • Integration interfaces between teams and systems

  • Complex business logic

  • Code being reused across multiple teams


  1. On the product life cycle, you left out the final one, "litigation". ;-D

  2. Maybe I could put one also called the "real waterfall" pattern


  3. Useful list of Flashcards. Thanks for putting this together.