Home › SI Blogs › Joe's Blog › Agile Methods

Agile Methods

by Joe Friedman on March 13, 2009

At Soft Illuminations, we never let the opportunity to teach customers pass us by. We employ Agile methodologies and practices in developing software. It is absolutely necessary we educate our clients about how we innovate for them. It is my hope that this article serves as a solid reference for those unfamiliar with Agile Methods.

Agile

Agile, when used in reference to software development, is a group of methods and practices that are based on common principles. Agile methodologies foster a team’s constant inspection and adaptation during the life cycle of a project. Leadership in Agile, as opposed to traditional project management styles, is based on the encouragement of teamwork, self-organization and accountability. Self-organizing teams and a leadership style that is focused on facilitation rather than delegation results in the rapid delivery of high-quality software, and a business approach that aligns development with customer needs. The core values of Agile Development are:

-Individual interactions over processes and tools

-Working software over comprehensive documentation

-Customer collaboration over contract negotiation

-Responding to change over following a plan

Agile Methods

Agile Methods are a family of distinct development processes, not a single approach to software development. All of the Methods contain at least some if not all of the main characteristics of Agile. Face-to-face communication is required, regular adaptation to change is to be expected, and working software is the principal measure of progress. To some, Agile methods are sometimes characterized as being the opposite of “plan-driven” or “disciplined” methods. This distinction is misleading, as it implies that agile methods are “unplanned” or “undisciplined”. It is more appropriate to view Agile Methods as iterative and adaptive. Here are some core Methods of Agile Development worth noting:

Agile Modeling

Agile Modeling is a practice-based methodology for modeling and documenting software systems. It is a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods.

Dynamic Systems Development Method

DSDM addresses the most common failures of information systems projects, including exceeding budgets, missing deadlines, and lack of user involvement and top-management commitment. DSDM is an iterative and incremental approach to software development that emphasizes continuous user involvement throughout the lifecycle of a project.

Agile Unified Process

The Agile Unified process describes a simple, easily understood approach to developing business application software while using agile methodologies. The AUP applies methods such as Agile Modeling, test driven development (TDD), agile change management, and database refactoring to improve the productivity of development teams.

Extreme Programming

The objective of Extreme Programming, commonly referred to as XP, is to reduce the monetary cost that change adds to a project. In traditional systems development methods such as Waterfall, the requirements for the system are determined at the beginning of the development project and are fixed from that point on. This results in costly changes in the later stages of the project. XP aims to reduce the cost of these changes by introducing basic values, principles and practices to the development of a project. By applying XP, a development team will be more flexible with respect to change. The core values of XP are frequent communication, simplicity of functionality, continuous feedback, courageous development, and a team that fosters mutual respectful of the individuals involved.

Feature Driven Development

Feature Driven Development aims to deliver tangible, working software repeatedly in a timely manner. This iterative and incremental method of development focuses on client-valued functionality. FDD blends some of the best practices from software engineering to create a cohesive method of development. FDD consists of the use of the following best practices:

Domain Object Modeling-is the practice of exploring and explaining the domain of the problem to be solved. The resulting model provides an overall framework in which to add features.

Developing by Feature-Any function deemed too complex to be implemented within two weeks is decomposed into a set of smaller functions until each sub-problem is small enough to be called a feature. This simplification makes it easier for teams to deliver customer-valued functions to a system.

Individual Class(Code) Ownership-Distinct pieces or groupings of code are assigned to a single owner. The owner becomes responsible for the consistency, performance, and conceptual integrity of the class.

Feature Teams-A feature team is a small, dynamically formed team that develops a specific set of functionality. In doing so, teams are able to evaluate multiple design options before development begins.

Inspections-are carried out regularly to ensure good quality design and code, primarily by the detection of defects.

Configuration Management-aids teams in identifying the source code for all features that have been developed up to a certain point. This tracking and maintaining of code provides a history of changes a team has made to features during development.

Regular Builds-Regular builds of the system are done to ensure there is always an up to date version of the system ready to be demonstrated to the client.

Visibility of progress and results. Managers easily track the progress of a project through frequent and accurate progress reports. It is essential these reports be visible to all members inside and outside the project.

Scrum

Scrum is an iterative, incremental process of software development that involves a distinct set of practices and predefined roles. The main roles in Scrum are the “Scrum Master” who guides the process and enforces the rules of Scrum, the “Product Owner” who represents the stakeholders, and the “Team” which is comprised of developers. Scrum teams develop in “sprints” (typically a 2–4 week period) in which the team creates an increment of usable software. The set of features that go into a sprint come from the “product backlog”; a prioritized set of high-level functionality. The Product Owner, along with the team, determines which set of features will be developed during the sprint at the Sprint Planning meeting, before the sprint begins. During this meeting, the team also determines how many features they can commit to complete during the next sprint. This select of features makes up the “sprint-backlog”. During a sprint, no one is able to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software. When the Product Owner agrees that all functionality performs to their standards, the team moves forward and the Scrum process is repeated until the project is complete. One of the major principles of Scrum is the recognition that during a project, customers will change their minds about what they want and need. Scrum seeks to address these changes in an easily predictive and adaptive manner. For a more detailed article, read my blog, “Scrum Illuminated”