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
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|
|My Nutshell definitions of Agile Development|
|Why Agility Works|
|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:
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".
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.
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?
Please ignore my question to you in my previous post, I read your reply in the wrong context. My apologies.
Nice post. I riffed on how business rules complements your view of agile over on my ebizQ blog.
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:
10 Good Reasons:
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)
When I started to develop software for my new company (infodoro.com), I started to work with a distributed team in eastern Europe and India and the daily scrum was not as practical. During that time, I realized that Agile is a lot more than the daily scrum. And it is quite practical and effective to do Agile development in the true sense.
From almost the beginning we made sure that we had
1. A central globally available source control system
2. A globally available bug tracking system
3. A globally available test case management system
4. Insistence on writing unit tests
5. An automated test suite and harness
6. A continuous code integration system with the unit tests and the automated test suite integrated in
7. A globally available wiki, task management and messaging system
The results of this upfront work have been very encouraging with the quality of code produced and the quick turn around on features.
Post a Comment