CSC/ECE 517 Fall 2011/ch6 6e gm

Agile Debate

This page serves as the source of discussing the Agile debate.

Introduction

Software methodologies today can be broadly classified into two categories namely, heavyweight and lightweight methodologies.A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly. They try to plan out a large part of a project in great detail over a long span of time. Project managers tend to want to predict every conceivable project milestone because they want to see every technical detail. This leads managers to demand all sorts of specifications, plans, reports, checkpoints, and schedules. But this works well only until things start changing; therefore, project managers who use heavyweight methodologies will resist change. The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment. Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project. A lightweight (or Agile) methodology, on the other hand, has only a few rules and practices or ones which are easy to follow. Agile processes emphasize both the rapid and flexible adaptation to changes in the process, the product, and the development environment. Agile processes include three major attributes, they are:

• Incremental and Evolutionary – allowing adaptation to both internal and external events.
• Modular and Lean – allowing components of the process to come and go depending on specific needs if the participants and stake-holders.
• Time Based – built on iterative and concurrent work cycles, which contain feedback loops and progress checkpoints.

Review of some heavy weight and Agile methods

Before we further compare the heavy weight methodologies and the light weight methodologies, let us look at some of the examples of heavy weight methodologies and light weight methodologies in detail:

heavyweight methodology

Heavy Weight methodologies

A heavyweight methodology has many rules, practices, and documents. It requires discipline and time to follow correctly.The heavyweight development methodology is based on a sequential series of steps, such as requirements definition, solution build, testing and deployment. Heavyweight methodologies can be the better choice when you have multiple teams working at different locations and you need tighter control to formalize key parts of the project. Here is a brief overview of some heavyweight methodologies:

Waterfall

Waterfall model

In this model, each waterfall stage is assigned to a separate team to ensure greater project and deadline control, important for on-time project delivery. A linear approach means a stage by stage approach for product building.The project team first analyses, then determining and prioritizing business requirements / needs. In the design phase business requirements are translated into IT solutions, and a decision taken about which underlying technology i.e. COBOL,Java or Visual Basic,etc. is to be used. The design phase is followed by code implementation. The next stage of data conversion evolves into a fully tested solution for implementation and testing for evaluation by the end-user. The final phase is evaluation maintenance.

Unified Process

Unified Process model

In the Unified Process, the project is divided into four phases<ref>http://en.wikipedia.org/wiki/Unified_Process#Project_Lifecycle</ref> - Inception, Elaboration, Construction and Transition. By the end of the inception process a business case should have been made; feasibility of the project assessed; and the scope of the design should be set. In the elaboration phase, a basic architecture should have been produced and a plan of construction agreed. Furthermore, a risk analysis takes place and those risks considered to be major should have been addressed. The next phase is construction. This phase produces a beta-release system. A working system should be available and sufficient enough for preliminary testing under realistic conditions. The transition phase introduces the system to the stakeholders and intended users. It is crossed when the project team and the stakeholders agree that the objectives agreed in the inception phase have been met and the user is satisfied.

Spiral Model

Spiral model

In this model, the elements of both design and prototyping-in-stages are combined, in an effort to reap the advantages of top-down and bottom-up concepts. The spiral model also involves four main phases. The objecting setting stage, in which specific objectives for the project phase are identified. In the risk assessment and reduction stage, key risks are identified, analyzed and information is obtained to reduce these risks. The Development and Validation stage involves choosing an appropriate model for the next phase of development. In the final Planning stage, the project is reviewed and plans are drawn up for the next round of spiral.

Light Weight methodologies

lightweight methodology

Lightweight methodologies, developed as a reaction to the heavy methodologies.Agile methodologies embrace iterations. Small teams work together with stakeholders to define quick prototypes, proof of concepts, or other visual means to describe the problem to be solved. The team defines the requirements for the iteration, develops the code, and defines and runs integrated test scripts, and the users verify the results. Verification occurs much earlier in the development process than it would with waterfall, allowing stakeholders to fine-tune requirements while they’re still relatively easy to change.Here is a brief overview of some lightweight methodologies:

Extreme Programming

Steps in Extreme Programming

Extreme programming (XP) has evolved from the problems caused by the long development cycles of traditional development models. The XP process can be characterized by short development cycles, incremental planning, continuous feedback, reliance on communication, and evolutionary design. The life cycle of an XP project is divided into six phases<ref>http://en.wikipedia.org/wiki/Extreme_programming#Activities</ref>: Exploration, Planning, Iterations to release, Production, Maintenance and Death. In the Exploration phase, the customer writes out the story cards they wish to be included in their program. This leads to Planning phase where a priority order is set to each user story and a schedule of the first release is developed. Next in the Iterations to Release phase, the development team first iteration is to create a system with the architecture of the whole system then continuously integrating and testing their code. Extra testing and checking of the performance of the system before the system can be released to the customer is done in the Production phase. Postponed ideas and suggestions found at this phase are documented for later implementation in the updated releases made at the Maintenance phase. Finally the Death Phase is near when the customer have no more stories to be implemented and all the necessary documentation of the system is written as no more changes to the architecture, design or code is made.

SCRUM

Scrum Methodology

In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one week, two weeks, or three weeks in duration. Each day begins with a kick-off meeting to assure quality control At the end of each sprint, stakeholders and team members meet to assess the progress of a project and plan its next steps. This allows a project’s direction to be adjusted or reoriented based on completed work, not speculation or predictions. Scrum methodology has a set of roles, responsibilities, and meetings that never change. Scrum has three fundamental roles<ref>http://en.wikipedia.org/wiki/Scrum_(development)#Roles_2</ref>: Product Owner, Scrum Master, and team member.
Roles of Scrum
Product Owner : In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry. The tension between authority and responsibility means that it’s hard for Product Owners to strike the right balance of involvement. Because Scrum values self-organization among teams, a Product Owner must fight the urge to micro-manage. At the same time, Product Owners must be available to answer questions from the team.

Scrum Master : The Scrum Master acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.

Team Member : In the Scrum methodology, the team is responsible for completing work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. Each sprint, the team is responsible for determining how it will accomplish the work to be completed. This grants teams a great deal of autonomy, but, similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals of the sprint.<ref>http://scrummethodology.com/</ref>

RUP

RUP (rational unified process) is a framework that breaks software development into four gates; inception, elaboration, construction and transition. Each gate has a list of deliverables that must be accepted by stakeholders before advancing to the next stage. Its focus is quickly adding or removing large chunks of reusable software to solve common problems [Baltzan et al, 2010].

RAD

Rapid Application Development, or RAD, is a methodology based on broad user involvement in prototype development to hasten the software development process. It utilizes iteration to collect changing business requirements while proactively involving software users in analysis, design and development. This methodology is often known for prototypes turning into final solutions.

Limitations of heavy weight methodologies

The main difference between heavyweight and agile methodologies is the acceptance of change. It is the ability to respond to change that often determines the success or failure of a software project . Heavyweight methods freeze product functionality and disallow change. However one of the key, philosophical constructs making agile processes successful in today’s market is its response to change at any stage of the project. It makes it very difficult to implement a predictive process or to provide a set of stable requirements in this volatile and constantly changing environment. Another limitation of heavyweight methodologies is the handling of complexity. The approach to plan everything and then to follow the plan works smoothly for stable and less complex environment but for larger and more complex environments, this technique would fall apart.Another important criticism against heavyweight methodologies is their treatment of people involved in developing a process. Traditional methodologies treat people as predictable components similar to what they treat their processes.

Limitations of Agile methodologies

Although Agile has a lot of advantages over heavy weight methodologies, it has a few limitations:

• In case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

• There is lack of emphasis on necessary designing and documentation.

• The project can easily get taken off track if the customer representative is not clear what final outcome that they want.

• Only senior programmers are capable of taking the kind of decisions required during the development process. Hence it has no place for newbie programmers, unless combined with experienced resources.

Advantages of Agile methodologies over heavy weight methodologies

Agile Methodology

Agile methodology has an adaptive team which is able to respond to the changing requirements. The team does not have to invest time and effort and finally find that by the time they delivered the product, the requirement of the customer has changed. Face to face communication and continuous inputs from customer representative leaves no space for guesswork. The documentation is crisp and to the point to save time. The end result is the high quality software in least possible time duration and satisfied customer. Agile methodologies focus on the talents and skills of individuals and molds processes to specific people and teams, not like heavyweight methods where all tasks and roles are assigned to individuals and it is expected that the individuals will perform their tasks accordingly.Agilists measures project success by questioning if the customer got software that is more valuable to them than the cost put into it.agile development accelerates the delivery of initial business value, and through a process of continuous planning and feedback, is able to ensure that value is continuing to be maximized throughout the development process. As a result of this iterative planning and feedback loop, teams are able to continuously align the delivered software with desired business needs, easily adapting to changing requirements throughout the process.<ref>http://www.my-project-management-expert.com/the-advantages-and-disadvantages-of-agile-software-development.html</ref><ref>http://www.versionone.com/Agile101/Agile_Benefits.asp</ref><ref>http://blog.adsdevshop.com/2008/01/03/top-5-developer-benefits-of-agile-development/</ref>

Advantages of heavy methodologies over Agile Methods

More and more software and web development today takes place using Agile methodology but there are some places where heavy methodology wins. For example, heavy methodologies like waterfall model are, waterfall’s defined stages allow for thorough planning, especially for logical design, implementation and deployment which at some times agile lacks. But if one needs a sound and quick way of software development then agile development works fine. Hence agile methodology is a sound choice for software development and web design projects and, more and more firms are becoming Agile!

Comparison between Heavy weight and Agile methodologies

Heavy weight methodologies involve detailed up-to-date documentations and models whereas in agile methods,communication is given emphasis rather than documentation, which mainly consists of cards and abstract hand-drawn models. While heavy methodologies make use of high-fidelity prototypes, agile methodologies use abstract prototypes which implement the simplest of tools. Heavy methods iterate the process of developing and proving concepts with user feedback. On the other hand, agile methods design for needs rather than user expectations. They retrieve the design from models rather than continuous user feedback. This makes the heavy methods spends a lot of time over usability evaluations as compared to the agile methods, which do not even need to evaluate if the models are right.

Examples/Scenarios

It should be noted that, in software industry there is a very thin line of separation when it comes to heavy weight vs Agile methodologies. So the question is when to use heavy weight and when to use Agile methodologies<ref>http://pm.stackexchange.com/questions/389/when-to-use-waterfall-when-to-use-scrum</ref>. This can be explained using following scenario -

1. One may want to use heavy methodologies when:
   • One work's for a big client and they enforces their very formal approach on vendors.
   • One work's on fixed-scope, fixed-price contracts and client doesn't expect (for any reasons) rapid change in the scope
   • One's project team is experienced with specific heavy-weight approach - they know how to deal with it, they know how to use it to deliver high-quality project
2. One should consider agile approach when:
   • One work's on in-house projects or projects for more flexible clients where you don't have to adjust to client's processes.
   • One work's on a project where scope is changing rapidly (for whatever reason) and you tend to accept the fact.
   • One's team isn't fluent with any specific project management approach as generally agile methods make learning curve pretty smooth in terms of introducing best practices.

Differences

Some of the differences between the heavy weight methodologies and light weight methodologies, which we discussed in the previous sections, are summarized in the table below

Comparison of Agile vs Heavy Methodology

Metric	Agile Methodology	Heavy Methodology
Approach	Adaptive	Predictive
Success Management	Business value.	Conformation to plan.
Project Size	Small.	Large.
Management Style	Decentralized.	Autocratic.
Perspective to Change	Change Adaptability.	Change Sustainability.
Culture	Leadership-Collaboration.	Command-Control.
Documentation	Low.	Heavy.
Emphasis	People-Oriented.	Process-Oriented.
Cycles	Numerous.	Limited.
Domain	Unpredictable/Exploratory.	Predictable.
Team Size	Small/Creative.	Large.
Upfront Planning	Minimal.	Comprehensive.
Return on Investment	Early in the project.	End of the project.

Conclusion

Agile methods can be used when the objective of a project is rapid value. When a customer expects high assurance, heavy weight methodologies are a better choice. Agile methods would be the ideal choice when a project is subject to continuous change and the requirements of the project are unknown or uncertain. Heavy methodologies require that the requirements of the project are well known and largely stable. Heavy methodologies also require that there is sufficient budget for the project beforehand. Agile methodologies allow for ambiguity with respect to the budget required for the project. If the project involves a new technology and unknown risks, heavy methodologies would be a risk choice, because they demand that the milestones must be clear and defined. Agile Software Development methods can help organizations deal with situations qualified as highly uncertain and unknown. On the contrary, predictability and well-defined milestones speak for heavy methods, if one tries to group in scope, resources, time and risks matrix. Moreover, agile methods focalize on rapid value by designing for current needs.

Heavy methods centralize on high assurance by designing for both current and future needs. In case of agile methods, both developers and customers have to be extremely agile and well versed in their area of expertise. Heavy methods demand more compliance and discipline when it comes to customers and developers. Plan execution and plan adherence is what counts most in heavy methods. Similarly, if the cost of change is trivial, then it makes sense to employ agile techniques, as agile methods welcome change throughout the project’s life. If refactoring and change adaptability comes at a heavy price, then management is better off using heavy methods.<ref>http://ausweb.scu.edu.au/aw04/papers/edited/balbo/</ref>

Agilists believe the yardstick of measuring success is not man-hours; it is results. According to Agilists, expecting to solve people issues through technological or process solutions is totally flawed. On the other hand, proponents of heavyweight methodologies advocate that it is not improvisation, rather it is carefully articulated processes, which are the key to success. It is detailed planning, extensive documentation, and thorough design, which produce quality products. They maintain that we need the same structure, vigor, and repeatability, in software development, that paved the way for Industrial Revolution. Heavyweight processes use scientific approaches to narrow complexity by thriving to provide certainty in face of uncertainty, objectivity in face of subjectivity, uniformity in the face of multiplicity, designed process in the face of evolving process. <ref> http://ausweb.scu.edu.au/aw05/papers/edited/khan/paper.html </ref>

References

<references/>