Saturday, April 14, 2007

Agile Development Distilled

Lately I've been spending some time thinking about how to distill Agile development within my company on a single powerpoint slide for a top-level Executive. I keep going back and forth between something that shamelessly steals (and modifies) something used to describe RUP, and something that shamelessly steals (and slightly modifies) something from Dan Rawsthorne.

Dan Rawsthorne writes that the "essence of agility is: iteration, validation, feedback." I think something along those lines is ...
Agility comes from rapid feedback & learning in short-cycles using:
  • Close Collaboration
  • Continuous Validation
  • Frequent Iteration
  • Dynamic Adaptation

RUP talks about 6 Key Principles For Business-Driven Development:
1. Adapt The Process
2. Balance Stakeholder Priorities
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate The Level Of Abstraction
6. Focus Continuously On Quality

I think an "Agile slant" on that would be:
1. Adapt to Change
2. Prioritize Scope
3. Collaborate Across Teams
4. Demonstrate Value Iteratively
5. Elevate the Level of Automation
6. Continuously Validate Quality

Of course much of this just seems like Steven Covey’s Seven Habits of Highly Effective People. And maybe that is true.

Other sources and quotes ...

Alistair Cockburn writes of Seven Properties of Agile Projects:
1. Frequent Delivery
2. Reflective Improvement
3. Osmotic Communication
4. Personal Safety
5. Focus
6. Easy Access to Expert Users
7. A Technical Environment with Automated Tests, Configuration Management, and Frequent Integration

David Anderson's Agile Recipe for Success is: Focus on Quality, Reduce Work-in-Progress, Balance Demand against Throughput, Prioritize. He also writes "Trust is the essence of Agile"

Jim Highsmith adds that: "Agile Organizations don’t just respond to change; they generate it!"

“Agile development uses feedback to make constant adjustments in a highly collaborative environment."
-- Andy Hunt,

"Short Cycles and Customer Involvement" -- 3rd eWorkshop on Agile Methods

"an inclusive, people-centred approach to doing iterative, incremental software development. It uses a combination of technical and social practices to increase collaboration and reduce feedback cycles"

-- Steve Hayes,

"The essence of Agile evolution is to gradually transform a typically conservative, risky and unattractive activity into a positive and proactive development activity."

--Dave Thomas, Agile Evolution,

See table of "Key Characteristics of Agile" at (Towards an Agile Systems Engineering process)

See Agile Axioms and Seven Core Practices of Agile Development

DSDM in a Nutshell

Getting Real

My Nutshell definitions of Agile Development

Why Agility Works

Scrum Primer

Agile EVM

Allan Shalloway's Agile Explained

Dean Leffingwell with Ryan Martens, Scaling Software Agility, Ch 7 on The Essence of Agile

Not so Agile aspects of Agile Development

The Agile-Oriented Paradigm

More take-offs on Covey's Seven habits are ...
Five Habits of Highly Visionary Companies
Six Habits of Highly Effective CIOs
Seven Habits of Highly Effective Programmers
Seven Habits of Highly Effective User Interface Designers
Seven Habits of Highly Effective IT Managers
The Seven Habits of Effective Iterative Development

From SurgeWorks ( ...
In a nutshell, Agile Methodologies are focused on delivering maximum business value in minimal time. There are several different Agile approaches, but all of them focus on a similar set of core practices. They are:
  • Iterative development
  • Business prioritization
  • Adaptive to changing/evolving requirements
  • Active user involvement


Anonymous said...


Thank you for this. However, after understanding David Anderson's post,
Kanban in Action
I now view iteration as an optional practice and not a principle of Agile. As such, "Frequent Iteration" should be "Frequent Delivery of Value" and "Demonstrate Value Iteratively" should be "Release Value Frequently".


Brad Appleton said...

Hi Norbert!

In this context, I was assuming that the meaning of "iterate" and "iteration" is multi-scale, meaning it applies all throughout the release-cycle. The "fixed length iteration" that is used as a the smallest unit of planning+delivery would be just one type of "iterating" (and probably the largest one). Developers iterate by working in fine-grained tasks and using both continuous integration and test-driven development to validate after each cycle. If developers pair, there is another cycle. Team integration frequency may be yet another cycle, as might be the daily standup.

Does that make sense? DO you feel your comment still applies?

Anonymous said...

I'm sad to see that we still need to explain to top Executives agility, why we probably not need to explain other methodologies.
Anyway, I'd really love to see you powerpoint if you want to share it with us.
By the way, GREAT blog: I read it always with pleasure.

Anonymous said...

Hi Brad:

Thank you for the clarification. Yes I still think that my comment applies. To me, you list practices and some of them are identical to practices that non-Agile methodologies use. All projects have mini-cycles in them, so how do you differentiate between an Agile cycle and a non-Agile cycle?

Setting that aside, assuming that iteration is a defining principle of Agile, then an organization that continually improves how they deliver value and the speed in which they do, but does so without using an all encompasing iterative approach but in all other respects follows the Agile Manifesto principles, for example Toyota or Corbis, then they are by this definition not Agile; so what do we call them? Personally, this is not a road I want to go down and hence my attempt to formulate a principle that focused on outcomes, which let people use/create/evolve the practices that best implements the principle in their environment. An aside, in my judgement iterations are a best practice, not the best practice or a principle, which was the judgement I used to hold.

To PierG, why does changing my judgement from iterations are a defining principle of Agile to frequently releasing value, imply that I do not understand Agile and it needs to be explained to me? I don't understand this reasoning, please explain it to me?


Anonymous said...

Hi PierG:

Please ignore my question to you in my previous post, I read your reply in the wrong context. My apologies.


James Taylor said...

Nice post. I riffed on how business rules complements your view of agile over on my ebizQ blog.

Anonymous said...

I think c-suite folks are probably less interested in "what is agile?" vs. "what does it get me?" I beleive that all post waterfall methodologies, especially Agile, XP et al., all try to address or mitigate the risk of delivering something the users don't need when it's delivered. Iterative development probably does this well - deliver the application and find out from the users/stakeholders if what was delivered is what they were looking for - makes course corrections in the next iteration. Feedback loops are absolutely key.

Being agile means being able to respond to change effectively.

Kelly Waters said...

Maybe these 2 entries from my blog may be of some use?

10 Key Principles:

10 Good Reasons:

Kelly Waters

Brad Appleton said...

where are the "practices" being listed in my distillment? Regardless of whether or not other methodologies are doing them, they are still essential for Agility (particularly iteration). You tell the difference between Agile and non-Agile cycles, in part, by their duration & frequency.

Can you give an example of a company that is not employing iteration that would meet your definition? Because as far as I can see, both Lean & Corbis are definitely employing iteration. One-piece flow is iterative in nature, so is set-based development as applied to software (according to Mary Poppendieck), so are the Kan-Ban events (which I believe also qualify as a form of set-based development), and there are other "staples" of Lean which are inherently iterative in their nature.

The remark about "iterations" and best-practices doesnt seem to apply here because 1.) nothing here describes them as "the" best-practice; and 2.) again, "iteration" is not limited to the context of a release, but to repeated successive iterative activity that provides frequent and regular feedback (which is, again, definitely what Lean and Corbis are both doing)