CSC/ECE 517 Fall 2011/ch18 6d na

6d. The Agile landscape.

---

Overview

Traditional software development methodologies like waterfall methodology are notorious for their lack of flexibility and slowness. That’s why today traditional development methodologies are often replaced by agile development methodologies, which accelerate the process of software development and allow quicker project finalization. Agile software development methodologies give a chance to step away from bureaucracy and strike a balance between laissez-faire style and immersion into paper work.

Introduction to Agile Software Development

Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90's as an answer to the long-growing frustrations of the waterfall SDLC concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some deliverable.

After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990's in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the consitution and the Declaration of Independence. They then hijacked the term 'Agile' in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others' approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.

Agile Manifesto

Manifesto for Agile Software development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

working software over comprehensive documentation

customer collaboration over contract negotiation

responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile planning activities

In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.' Agile planning activities for large-scale development efforts should rely on these five levels.

Level 1 - Product Visioning The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

Level 2 - Product Roadmap The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps - into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

Level 3 - Release Planning In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

Level 4 - Iteration Planning For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

Level 5 - Daily Plan The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.

Agile Methodologies

Scrum

Scrum is a lightweight management framework with broad applicability for managing iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others contributed significantly to the evolution of Scrum over the last decade and a half. Over the last few years in particular, Scrum has garnered increasing popularity in the software community due to its simplicity, proven success and improved productivity, and its ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

Extreme Programming

XP, originally devised by Kent Beck, has emerged as one of the more popular and controversial agile methods. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks. The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices: Planning Game, Small Releases, Customer Acceptance Tests, Simple Design, Pair Programming, Test-Driven Development, Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Metaphor and Sustainable Pace.

Dynamic Systems Development Method

DSDM, dating back to 1994, grew out of the need to provide an industry standard project delivery framework for what was referred to as Rapid Application Development (RAD) at the time. While RAD was extremely popular in the early 1990’s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened in 1994, with the goal of devising and promoting a common industry framework for rapid software delivery. Since 1994, the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile and iterative software development projects. DSDM is based on nine key principles that primarily revolve around business needs/value, active user involvement, empowered teams, frequent delivery, integrated testing, and stakeholder collaboration. DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focusing on the useful 80% of the system that can be deployed in 20% of the time.

Crystal

The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of methodologies (Crystal Clear, Crystal Yellow, Crystal Orange, etc.) whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.

Learn Software Development

Lean Software Development is an iterative methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement and the practices of companies like Toyota. Lean Software Development focuses the team on delivering value to the customer, and on the efficiency of the "Value Stream," the mechanisms that deliver that value. The main principles of Lean include Eliminating Waste, Amplifying Learning, Deciding as Late as Possible, Delivering as Fast as Possible, Empowering the Team, Building Integrity In, and Seeing the Whole. Lean eliminates waste by selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

Feature Driven Development

FDD was originally developed by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnations of FDD occurred as a result of collaboration between De Luca and OOD thought-leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week "design by feature, build by feature" iterations. The features are small, "useful in the eyes of the client" results. FDD designs the rest of the development process around feature delivery using the following eight practices: Domain Object Modeling, Developing by Feature, Component/Class Ownership, Feature Teams, Inspections, Configuration Management, Regular Builds, Visibility of Progress and Results.

Other Methodologies

Kanban as applied to software development is a pull-based planning and execution method. Rather than planning work items up front and pushing them into the work queue of a team, the team signals when they are ready for more work and pulls it into their queue. Kanban historically uses cards to signal the need for an item. For software development teams, these cards are kept on a Kanban Board which is organized into columns and rows. The columns represent the different states of a work item, from initial planning through customer acceptance. The specific columns a team uses should meet the needs of the team and be tailored to their context. The rows on the Kanban Board represent work items. Work items are sometimes grouped within areas, such as feature sets and category types. Kanban focuses on maximizing the throughput of a team. One of the ways it achieves this goal is through the application of Work-in-Process (WIP) limits in each of the states of a work item. Under a Kanban (or Lean) approach, queues or inventories of work in any state are seen as waste. The WIP limits enable a team to focus on the optimal flow of work items through the system, minimizing any associated waste. Kanban allows teams to achieve process optimizations while respecting and maintaining a sustainable pace.

Comparison of different agile methodologies

Conclusion

Agile software development stresses rapid iterations, small and frequent releases, and evolving requirements facilitated by direct user involvement in the development process. Serena’s application lifecycle management tools provide a framework to visualize scope, orchestrate mundane and repetitive development tasks, and enforce process. Unlike agile-specific products offered by agile-only vendors, Serena products are methodologyneutral and can be applied equally well to agile as well as more traditional serial development processes, so they can support all the development activities within an enterprise.