I think that the Agile practice of having Team doing collaborative work provides the most benefit, since in the traditional process we have teams divided into different modules, and mostly they interact very late in the project leading to issues where a team might have been working in some assumption that the team working in a particular module might have already covered it.
I am not an Agile expert but I do believe that Practicing Agile can simplify software development.
Below PPT provides the 10 key principles of Agile:- 10 key principles of agile software development --- allaboutagile.com | by kelly.waters
It's amazing to see the 10 practices listed here : 1. Active user involvement is imperative 2. The team must be empowered to make decisions 3. Requirements evolve but the timescale is fixed 4. Capture requirements at a high level; lightweight & visual 5. Develop small, incremental releases and iterate 6. Focus on frequent delivery of products 7. Complete each feature before moving on to the next 8. Apply the 80/20 rule 9. Testing is integrated throughout the project lifecycle � test early and often 10. A collaborative & cooperative approach between all stakeholders is essential
... are similar to the practices listed here * Adapt the Process * Balance Competing Stakeholder Priorities * Collaborate Across Teams * Demonstrate Value Iteratively * Elevate Level of Abstraction * Focus Continuously On Quality
Btw, list #2 is extracted from RUP, that the initial website does not even mention :-)
/ JeanLouis<br /><i>"software development has been, is, and will remain fundamentally hard" (Grady Booch)</i><br /> <br />Take a look at <a href="http://www.epfwiki.net/wikis/openup/" target="_blank" rel="nofollow">Agile OpenUP</a> in the Eclipse community
Originally posted by JeanLouis Marechaux: Btw, list #2 is extracted from RUP, that the initial website does not even mention :-)
Yeah, too bad that I never saw a RUP consultant who could tailor a sensible process from RUP. It's also too bad how Rational turned Philippe Kruchten's good ideas and turned them into a process tool with a primary purpose being to sell the rest of the Rational tool set.
Originally posted by Jeremy Anderson: If you had to pick one agile practice, which one would you say usually has the biggest impact on a team that is not familiar with agile practices?
I think the nice thing is that you should never have to pick only one agile practice. Most of them are easy to take on, given that the team is willing to try, and most will provide some benefit if done properly. I do think there are some practices that introduce risk when done in the absence of other practices.
The most important would have to be getting frequent customer feedback (at least in every one of the many many projects I've been on). All of the other practices matter not if we're not building what the customer is asking for. Thus I believe the agile practice of delivering demonstrable business value to the customer on a regular basis is the most important.
From there, I think you need technical practices to sustain such intense customer demand. Automating as much as possible of the tests is essential to sustaining this pace; keeping the code base clean through continual refactoring (and through other mechanisms, including pairing or other review form) is also essential.
The most important would have to be getting frequent customer feedback (at least in every one of the many many projects I've been on).
While I agree with this, I've sometimes found it difficult for the customer to commit to such a frequent feedback cycle, though I don't know why. From a developer's perspective though have you seen a bigger impact in quality from simply practicing continuous integration, or does that not have much impact unless of course you are also practicing test first?
Originally posted by Jeremy Anderson: I've sometimes found it difficult for the customer to commit to such a frequent feedback cycle, though I don't know why.
Yeah, good point; it seems we're willing to spend lots of money on developers and expensive tools, but when it comes down to finding someone who can tell us whether or not we're building the right thing...
From a developer's perspective though have you seen a bigger impact in quality from simply practicing continuous integration, or does that not have much impact unless of course you are also practicing test first?
I've come to view rapid build feedback as an essential in any environment. It doesn't seem to me to significantly impact quality, at least not directly, but the lack of it (or even just a solid build process) does seem to point to a screwed up project and lots of wasted time.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus