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, http://www.sdtimes.com/fullcolumn/column-20060615-01.html |
| "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, http://pliantalliance.org/?p=31 |
| "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, http://www.jot.fm/issues/issue_2006_09/column2 |
| 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 (http://www.surgeworks.com/our-methodology) ... 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:
|
9 comments:
Brad,
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".
Norbert
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?
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.
PierG
http://pierg.wordpress.com
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?
Norbert
Hi PierG:
Please ignore my question to you in my previous post, I read your reply in the wrong context. My apologies.
Norbert
Nice post. I riffed on how business rules complements your view of agile over on my ebizQ blog.
Enjoy
JT
www.edmblog.com
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.
Maybe these 2 entries from my blog may be of some use?
10 Key Principles:
http://kw-agiledevelopment.blogspot.com/2007/02/10-things-you-need-to-know-about-agile.html
10 Good Reasons:
http://kw-agiledevelopment.blogspot.com/2007/06/10-good-reasons-to-do-agile-development.html
Kelly Waters
http://www.allaboutagile.com
Norbert,
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)
Post a Comment