CSC/ECE 517 Fall 2007/wiki3 10 tm

The Agile debate. Perhaps the most prominent controversy in o-o design today is whether it is possible to do a robust design with as little advance planning as agile methodologies recommend. Research this issue, on the Web and in the ACM DL, and report (fairly) on the major arguments of both sides, and on the evidence for both positions.

What is 'Agile Methodology'?

Agile Methodology was introduced as an iterative approach for developing software as a counter to waterfall approach. Where the five main phases of waterfall (requirement, design, coding, integration, testing) are practiced through every iteration. Moreover, it suggested several practices to enhance the software developments, see next figure from [http://txpug.editme.com/files/Lec2004Jul26/rupvagile.1.ppt "Finding Agility -�A comparison of RUP and Agile"], *.PPT .

Many Agile methodologies were introduced in the last decade (XP, Scrum, DSDM, FDD, Adaptive, Crystal). It would be difficult to introduce every aspect of these methodologies in this wiki. That is why, This wiki will concentrate in the most popular agile methodology, XP (eXtreme Programming).

Comparison Basis for Robust Design

A comparison between Agile methodologies and Waterfall methodology is found to be a little out of scope, as the advantages of iterative methodologies already recognized. That is why the current wiki will concentrate to compare with other iterative methods, such as RUP (Rational Unified Process). RUP share many of Agile's practices. Other practices can be immigrated from XP to RUP, or vise versa. Other features will still be unique to XP or in RUP. Next figure outline these practices, from "Finding Agility -A comparison of RUP and Agile", *.PPT .

In the current wiki we will try to test the Agile Manifesto and its related practices relative to design quality. These found to be the comprehensive basis for comparison as it provide the basis Agile methodologies trying to establish over other methodologies.

Individuals and Interactions Over processes and tools

Agile methodologies clearly state their believe that people is the main driver to the projects success, rather than the process and the tool. Agile Methodologies encourage individuals and their interaction through several practices and principles;

• Motivated individuals and Self organized team: Planning Game, Collective ownership.
• Face to Face Communication: Pair programming, Open space, On-site customer, Planning game.
• Sustainable Base.

Critique

• Requires too much cultural change to adopt.
  
• Go against "Human Psychology": many human factors goes against Agile methodologies, such as: People prefer to follow a process, No milestones, People self-interest, mini-dictatorships, Knowledge monopolies, Resource management vanish, customer dissatisfaction.
  
• The cost efficiency of pair programming is questionable.
  
• No Documentaion is acquired, just keep it minimal!
  

Working software Over comprehensive documentation

Agile Methodologies shows strong customer orientation by providing incremental delivery of an working software. This will also decrease the confusion while integrating at the end of the project and it become easier to zoom in the bug(s). Agile methodologies support this concept by:

• Continuous Releases: small releases and continuous integration.
• Face to Face Communication: Pair programming, Open space, On-site customer, Planning game.
• Executable Communication: Clear code (refactoring, simple design, standard code, metaphor), User stories.

Critique

• Deliver to whom: In many times the customer(s) is not interested enough to use the incremental releases.
• 2-8 weeks releases is too short to accommodate.
• Only works with senior-level developers. Developers need to gather requirements, test, code, refactor the code, integrate, release and plan
• Developers need to do all this without stopping to design nor to give a deep thought about it.
  
• Oral communication does not provide persistence and on-demand source of information.
• It is very difficult to keep the code clear to compensate the lack of necessary documentation.
  

Customer collaboration Over contract negotiation

While Agile methodology keep a broad meaning of the customer, which can be a member of the team, another part of the company or a contract customer. It is still acquire his/her existence with the team. Which create a strong communication between the customer and development team.

Critique

• Can lead to more difficult contractual negotiations
  
• This might make the customer controlling the development process, or in the other hand, not realizing what his/her business really need by being part of the development team.
  
• Place large responsibility in the customer, as he manage the process, identify and test the requirements, and negotiate. While no responsibility in the developers and management team.
• No obligation for the developer to learn more by themselves about the business case and its requirements.
  

Responding to change Over following a plan

Agile Methodologies incorporate the uncertainty existing in the project by creating an agile process that doesn't place planning further than existing iteration. This will reduce the cost of planning, and re-planning again. This principle is supported by many practices as incremental planning, <YAGNI principle>, <DTSTTCPW>, Refactoring and delaying decisions.

Critique

• Management and customer need to know an estimation for the time and resources needed.
  
• Incorporates insufficient software design and no front-end design.
  
• <YAGNI principle> You Aren't Going to Need It, and <DTSTTCPW> Do The Simplest Thing That Could Possibly Work would not make sense for experienced developers; They say You ARE Going to Need It.
  
• Don't use UML for design, and design session should be minimal.
  
• No up-front design nor "Pre-factoring".
  

Agile Methodologies' Paradox

XP/Agile's practices are introduced to achieve certain values (Communication, Feedback, Courage, Simplicity, Respect). It is true that these practices will help to provide the best environment for these values to grow. Nevertheless, many of these practices acquire the existence of these values in the project, the company, the management, the individuals, and moreover the customer. Certain enough these values represent moral and professional values that should exist in every social and individual system. Nevertheless, we recognize their variation in every system. Moreover, many of these values might be out of the control as simplicity of the project or the courage of the customer. The author think that is why Agile approach will give even a better results in different area such as R&D or education, see links.

The question will be "Which should exist first the values -the egg- or the Agile methodology -the chicken-."

Conclusion

Agile methodologies provided a framework for software development. These methodologies not meant to be for every project, company and/or person. To gain the promised savings in the documentations, architecture, tools and process, you need more than Agile practices; You will need its values (Communication, Feedback, Simplicity, Courage, Respect) existing in your company, project, individuals and in your customer. If you can't achieve these conditions, then you will need to be assisted with more documentations, design and process. Still Agile methodology will provide you with a lot of useful tools, you can pick and match what is suitable for your company, project, customer and personality.

External Links by Side

Arguments *Against* XP

• "Extreme Programming Refactored: The Case Against XP "
  
• "Questioning Extreme Programming"
  
• "Extreme Programming vs. Interaction Design"
  
• "Towards Extreme(ly) Usable Software"
  
• "The Case Against Extreme Programming"
  
• "The Agile Method and Other Fairly Tales", *.PDF
  
• "Kevin Brady Blog"
• "Opinion: Extreme Programming Is Evil"
  
• "Xp Critique"
  
• "The Case Against Extreme Programming"
  
• JC Lee and DS McCrickard, Towards Extreme(ly) Usable Software:Exploring Tensions Between Usability and Agile Software Development, Agile 2007, (2007), IEEE.
• MK Spayd, Evolving Agile in the Enterprise: Implementing XP on a Grand Scale, IEEE, Agile Development Conference (ADC '03), (2003): Give lesson learned why XP couldn't work in their case in large scale projetcs.
• George Mangalaraj, Challenges of Migrating to Agile Methodologies, Communications of the ACM, Vol 48, Issue 5, (May 2005).
• PS Grisham, DE Perry, Customer Relationships and Extreme Programming, ACM, Proceedings of the 2005 workshop on Human and social factors of software engineering, (2005): Show that Agile practices can be make the customer less satisfactory.
• MM Müller, F Padberg, On the economic evaluation of XP projects, Proceedings of the 9th European software engineering conference held jointly with 11th ACM SIGSOFT international symposium on Foundations of software engineering, (2003): Analysis shows that the economic value of, XP strongly depends on how large the XP speed and defect advantage really are. Also find that the market pressure is an important factor when assessing the business value of XP.
• J. Smith and T. Menzies. Should NASA embrace agile processes, 2002. preprint, West Virginia University, Morgantown, USA: The answer was most of the time NO.

Arguments *Support* XP

• "Are agile methods good for design?", Give how architecture can interact with XP environment, and how XP can be beneficial to design.
  
• "Agile Software Development: Evaluating The Methods For Your Organization"
  
• "Extreme Programming (XP), Six Sigma and CMMI" Place some metrics about why extreme programming and pair programming are good, i.e. errors, time, etc. Also give an approach how XP can be integrated in CMMI.
  
• TCN Kazman et all, Agility and Experimentation: Practical Techniques for Resolving Architectural Tradeoffs, Software Engineering, 2007. ICSE 2007.: This paper has tried to show that up-front architectural design is difficult, particularly when working in an environment in which there are many variables.
• S Beecham et all, Does the XP environment meet the motivational needs of the software developer?, AGILE 2007: Show that XP teams ihad processes in place that supported many of the motivational needs voiced by developers coming from a traditional, heavyweight software development environment. However, the XP environment is at odds with developer self, and carrer needs.
• "Process Agility and Software Usability": Address Agile methodology benefits to design, although address as well neccessary Up-front design need in agile.
• CA Wellington , et all, Examining Team Cohesion as an Effect of Software Engineering Methodology, Proceedings of the 2005 workshop on Human and social factors of software engineering, (2005): Show how Agile methodologies increase team cohesion.
• H Hulkko, P Abrahamsson, A Multiple Case Study on the Impact of Pair Programming on Product Quality, ACM, Proceedings of the 27th international conference on Software engineering, (2005): Show pair programming impact in software quality.
• "Interview: Jim Johnson of the Standish Group": Sate that Agile Methodologies is one of the most important reasons for project success. And more important than the formal methodologies, tools and infrastructure.
• "http://agilemanifesto.org/"
  
• "http://agilesoftwaredevelopment.com/"

Success Stories

• "Breaking the Ice for Agile Development of Embedded Software: An Industry Experience Report"
  
• "Agile enterprise software development using domain-driven design and test first"
  

External Links by Field

Programming

• "XP over Eclipse"
• "Agile Web Development with Rails"

Education

• "Extreme Learning"
• "A cross-program investigation of students' perceptions of agile methods"
• "eXtreme Programming at universities: an educational perspective"
  

Project Management

• "Developments in Agile Project Management"

R&D

• "agile practices for R&D projects"