CSC/ECE 517 Fall 2009/wiki3 7 dEaN

How can Agile complement other development methodologies?

In class, we talked about how it might not be possible to introduce all of the agile practices at the same time. Where this is not feasible, how can Agile complement other design methodologies? Give an overview of work on the topic. Look for research results and experience reports.

What are agile practices

The Agile practices can be best characterized by ? agile methodology could be described as "iterative" and "incremental".

development iterations, teamwork, collaboration, and process adaptability throughout the life-cycle of the project break tasks into small increments with minimal planning. This is achieved through regular cadences of work, known as sprints or iterations. Each iteration involves a team working through a full software development cycle iterative development An iteration may not warrant a market release goal is to have an available release (with minimal bugs) at the end of each iteration

Multiple iterations may be required to release a product or new features requirements and solutions evolve through collaboration between self-organizing cross-functional teams In a brief session, team members report to each other what they did yesterday, what they intend to do today, and what their roadblocks are Agile emphasizes working software as the primary measure of progress. five dimensions of a software project (duration, risk, novelty, effort, and interaction). rapid delivery of high-quality software Agile methods are adaptive as compared to predictive when constrasted with other plan-driven methodologies. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process.

principles behind the Agile Manifesto[5] are:

   * Customer satisfaction by rapid, continuous delivery of useful software
   * Working software is delivered frequently (weeks rather than months)
   * Working software is the principal measure of progress
   * Even late changes in requirements are welcomed
   * Close, daily cooperation between business people and developers
   * Face-to-face conversation is the best form of communication (co-location)
   * Projects are built around motivated individuals, who should be trusted
   * Continuous attention to technical excellence and good design
   * Simplicity
   * Self-organizing teams
   * Regular adaptation to changing circumstances

Agile methods - an adaptive approach

Reacting against the perceived strict regimentation of the Waterfall Model, the Agile model appeared in the 1990s. Its developers believed the Waterfall model was too slow and bureaucratic and did not comfortably accommodate the ways systems/software engineers actually work best. Agile, put simply, is where software is developed progressively with each new release adding more capabilities

It appeared under different names and flavours such as: Scrum (in management), Crystal Clear, Extreme Programming (XP), Adaptive Software Development, Feature Driven Development, and DSDM.

Agile aims to reduce risk by breaking projects into small, time-limited modules or timeboxes ("iterations") with each interation being approached like a small, self-contained mini-project, each lasting only a few weeks. Each iteration has it own self-contained stages of analysis, design, production, testing and documentation. In theory, a new software release could be done at the end of each iteration, but in practice the progress made in one iteration may not be worth a release and it will be carried over and incorporated into the next iteration. The project's priorities, direction and progress are re-evaluated at the end of each iteration.

Agile teams tend to work as a team in a bullpen - an open floor-plan work area that makes face-to-face communications easy. Agile, however, has been criticised for its lack of formal documentation.

(One wonder how well Agile development techniques would work for Virtual Teams.)

(after listing those characteristics)

Such flexibility is seen by some as a lack of discipline, but its ability to adapting quickly to change can make it a powerful method of tackling big projects - and ICT is a field where rapid and significant change is the rule rather than the exception! On the other hand, long-term (beyond a couple of months) planning is very hard to do with an Agile approach.

I guess an Agile project manager would be updating his Gantt chart daily :-)

Agile methods have features in common with RAD.

Example of agile practices

Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. One agile software solution is ScrumWorks Pro, a Scrum-specific project management tool. http://agilemethodology.org/agile-software/

Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

Agile methodology in pictures

http://www.reliablesoftware.com/weblog/uploaded_images/spiral-712085.bmp

http://www.ibm.com/developerworks/library/ar-apparch3/agile.jpg

http://leadinganswers.typepad.com/photos/uncategorized/2008/03/21/agile_lifecycle.jpg

http://www.aimtec.cz/foto/245_m2.gif

http://www.michaelnygard.com/images/blog/headlights/value_stream_agile.png

A brief overview on other methodologies

1. Waterfall model - this is the classic SDLC
2. RAD
3. Prototyping
4. Spiral

Scenarios where other methodologies are feasible but not complete

The waterfall model is the most structured of the methods, stepping through requirements-capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts: requirement specifications, design documents, test plans, code reviews and the like.

The main problem with the waterfall model is the inflexible division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change in the course of the project.

How can Agile complement other design methodologies in such scenarios

Agile development differs from other development models: in this model time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a timebox.

Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it and adding further functionality throughout the life of the project. If a project being delivered under the waterfall method is cancelled at any point up to the end, there is nothing to show for it beyond a huge resources bill. With the agile method, being cancelled at any point will still leave the customer with some worthwhile code that has likely already been put into live operation.

RAD = prototypes, reduced features. Agile = iterations.

Both are short iterative processes that deliver a reduced feature set. So what's the difference?

The only thing I can think of is RAD focuses on code reuse and frameworks for punching out code. Whereas Agile never puts emphisis in this area...

Traditionally the rapid application development approach involves compromises in usability, features, and/or execution speed.

Agile on the other hand doesn't aim to achieve that. The iterations aren't prototypes, rather, each iteration introduces changes and/or enhancements into the product and these are reviewed by all parties involved.

We use Agile methodologies but still use other processes around it, documentation, system and user acceptance testing, deployment processes.

The advantage of Agile based approach is modification of the requirements which is often applicable in a fast changing environment - one where the business needs to be reactive to the market conditions and/or competition.

Long term plans often fail at seams (in such environments) because once a product is released after the many months of development, it may be exactly as per specs but is no longer relevant in the market conditions of the day.

Another advantage of frequent iterations is that you expose the client to the new features gradually... they can provide feedback much quicker which can resolve any misconceptions that may have been harboured in the requiements...

The difference here between RAD and Agile is that in RAD you do not have immidiate feedback from the client between iterations. It is up to the developers to split the development into iterations that are useful and logical... For example, you'd probably split 1 into some more iterations, for example, add an advanced search, etc... same with Iteration 2, add validation, feedback, etc...

Current research

Large scale agile software development remains an active research area.

Conclusion

Agile home ground:

   * Low criticality[clarification needed]
   * Senior developers
   * Requirements change often
   * Small number of developers
   * Culture that thrives on chaos[clarification needed]

Plan-driven home ground:

   * High criticality[clarification needed]
   * Junior developers
   * Requirements do not change often
   * Large number of developers
   * Culture that demands order

References

en.wikipedia.org/wiki/Agile_software_development http://agilemethodology.org/ http://www.agilemanifesto.org/ http://www.agilemanifesto.org/principles.html http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/ http://www.mckinnonsc.vic.edu.au/vceit/models/index.htm#agile