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.
Review of some heavy weight and light weight 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:
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.
Light Weight methodologies
A lightweight methodology, on the other hand, has only a few rules and practices or ones which are easy to follow.
Here are some brief overviews of heavyweight methodologies
Waterfall
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. 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
In the Unified Process, the project is divided into four phases - 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
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.
Agile methodologies
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: 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
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: Product Owner, Scrum Master, and team member.
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.
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.
Advantages of Agile methodologies over heavy weight methodologies
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.
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.
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.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:
| Agile Methods | Heavy Methods | |
|---|---|---|
| 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. |
Agile Development
<references/>