Agile Development Process

Greane Tree Technology and the Agile Methodology

Greane Tree Technology adheres to the Agile methodology of project management and software development. We have found that the Agile development process allows us to reduce risk, boost quality, and accommodate change comfortably. Technical and business experts form a team that works closely to define and prioritize features so that working software can be delivered quickly. Refinements are made with each iteration of analysis, design, coding and testing. The completed system evolves from continuous collaboration between business and technical specialists. At Greane Tree Technology, we are both Agile practitioners and Agile mentors, and we credit the Agile methodology for our strong record of delivering working, useful software on time and on budget.

Introduction to Agile Techology

Based on incremental software development methods going back to the 1950s, the Agile methodology as such was proclaimed in the Agile Manifesto of 2001. The Agile methodology recognizes that change is inevitable and that it is impossible to predict at the beginning of a software project all the variables that will affect the project as it progresses. Instead of fighting against this reality, Agile development accepts it and relies on open communication, frequent releases of working software, and constant collaboration between customer and developer team to insure a successful project outcome.

Greane Tree Technology generally adheres to the Scrum framework for Agile development. The term “scrum” is borrowed from rugby, where it refers to the way to quickly restart play. As in rugby, in the Scrum framework, energetic, cross-functional teams work together to achieve a common goal. Scrum was first applied to manufacturing in the late 1980s, and, by Ken Schwaber and Jeff Sutherland, to software development in the 1990s. There are many websites devoted to the discussion of Scrum, of which two of our favorites are the Scrum Alliance and Mountain Goat Software, from whom, with permission, we borrowed our graphic representation of the Scrum process, below.

Scrum Roles and Daily Standup

The Scrum Team is made up of the Product Owner, who represents the voice of the customer, the Development Team, who have all the technical skills necessary to build the product, and the Scrum Master, who is characterized as a “servant-leader,” coaching the team and the organization so that they achieve the benefits of the Agile approach. The Scrum Team is nonhierarchical, cross-functional, and self-organizing. The team holds a short (15 minute), daily meeting called the Daily Scrum, or Standup. At this meeting, team members coordinate their efforts by reporting what they accomplished the day before, what they plan to do today, and what impediments stand in their way. The Daily Standup keeps progress and problems visible to the whole team, allowing them to keep their expectations in synch and address any issues quickly.

User Stories, Backlog Grooming, and Sprint Planning

At the beginning of an Agile development project, the team agrees to a high-level definition of project scope, stakeholders, features, and risks. This clarifies assumptions and helps to ensure that everyone is working toward a common goal. User roles are defined and system requirements are described in “user stories,” short narratives of what a specific user wants from the system. A typical user story might read, “In order to find customer information quickly, as a customer service representative, I need to be able to be able to search for the customer’s record by account number, phone number, or name.”

The collection of user stories is known as the product backlog. Once the user stories are written, they are prioritized so that the most important are addressed first. The effort to build the features documented in the user stories is estimated not in absolute terms, but in relative ones (“story points”), so that a complex feature might be assigned a “5” and a simple feature might be assigned a “1.” The team then agrees to a set of features that it can get working in a relatively short time frame, typically no more than two weeks. This time-boxed period is called a “sprint” and the user stories that form its focus are called the “sprint backlog.” Sometimes the entire process of prioritizing features and assigning story points will take place during the “sprint planning” meeting, but sometimes a special “backlog grooming” session is held to refine and estimate the user stories before the team decides exactly which ones it will take on during the sprint.

Agile Software Development: Building Quality In

With the addition of detailed testable scenarios, the user stories can be converted into automated unit tests that are written to fail before a feature is built, and then rerun after each iteration of development to make sure the feature is complete and the test remains successful. This “Test Driven Development,” or TDD, exercises the code to make sure it does exactly what it was supposed to and that adding new features doesn’t break old ones. “Behavior Driven Development,” or BDD, is an extension of TDD that expresses the testable scenarios in a language that humans can understand but which can also be converted into automated tests. It is designed to make sure not only that the code works as written, but that the code delivers what the user asked for in the user story. Testing is continuous throughout an Agile technology project so that development is constantly informed by quality assurance.

Sprint Review and Retrospective

At the end of the sprint, during a “sprint review” meeting, a software product increment with a set of working features is demonstrated and released for customer acceptance testing and potential deployment. The team measures its progress against sprint goals and tallies how many story points it completed in the sprint. A “burn-down chart” can help the team measure its “velocity” and roughly estimate the number of sprints it will take to complete the remaining product backlog. With real experience of how quickly they can work together, the Agile development team agrees upon the set of features for the next sprint, and begins to work on the next release.

“Inspect and adapt” is the basic mandate of the Agile development methodology and it applies not only to the work product but to the work process as well. “Sprint retrospective” meetings are held periodically to make sure technological tools, communication methods, meeting times, etc., are optimal for the team and project.In an incremental and iterative fashion, the Agile team works through the user stories, re-prioritizing or restating them as necessary, until the project is complete. Because the features in the product backlog are always addressed in priority order, and because the backlog can be reprioritized between sprints, the customer can be assured that the most important features will be delivered even if the “nice-to-haves” on the product backlog must be sacrificed to budget or time constraints.