What brought us to Agile?

The most common software management technique in the past and today is called “waterfall” Software Development. As defined by Wikipedia, the definition for Waterfall development is a sequential development process, in which development is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. With this approach, all requirements are gathered up front. Gathering of requirements in this fashion can take many months to complete.

The waterfall model is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible, for any non-trivial project, to get one phase of a software product’s lifecycle perfected before moving on to the next phases and learning from them. For example, clients may not be aware of exactly what requirements they want before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested in Big Design Up Front.

Designers may not be aware of future implementation difficulties when writing a design for an unimplemented software product. That is, it may become clear in the implementation phase that a particular area of program functionality is extraordinarily difficult to implement. If this is the case, it is better to revise the design than to persist in using a design that was made based on faulty predictions and that does not account for the newly discovered problem areas.

One of the major pitfalls in this approach is the fact that so much time and effort must be exerted before the team is able to identify potential problems, such as a design issue. Frequently issues found at implementation have a ripple effect back into previously completed phases, which require the team to revisit requirements specs and or design documentation. When this ripple occurs, the impact to the project schedule and cost estimates is often dramatically impacted, almost always in a negative way. And most unfortunate of all is the lateness of this information in the development lifecycle.
Historically, waterfall forecasts are notoriously wrong; no one is shocked by projects forecast to release in 18 months that took 36 months. Companies can achieve bankruptcy this way; developers can lose their jobs and careers. There is an alternative…

General Observations

To solve this common problem, reconsider some assumptions. If project requirements obtained upfront are likely to radically change over the course of the project, a system that adapts rapidly to change would likely work better. If developer work estimates are unreliable, find a way to map developer work estimates into actual developer time to fine-tune the estimates. If expensive advance planning results in marginally better or worse results than no planning at all, then plan over shorter horizons rather than longer.

Object Partner’s agile approach is a software management, planning and implementation guideline that balances these goals:

• Communication with team-members is emphasized. The spoken word is valued over the written documentation,
• Outsiders can experiment with partial implementations first hand periodically, for example monthly,
• Stakeholders can re-prioritize developer efforts periodically,
• Developers can measure their productivity empirically,
• Stakeholders can forecast release dates based on feature set,
• Developers can refine their processes and work activities through feedback loops and self-organization.

People (or at least roles)

A Project Team comprises a Product Owner, a Project Manager, a Technical Lead/Architect and between three and seven Developers. The Project Team is jointly responsible for the product, not only functionality, but architecture, quality, releasability, documentation, etc. Keep in mind that the roles described in this section may be performed by many team members in a one-to-one manner or several roles may be performed by a single team member. For instance, the Project Manager and the Technical Lead role may be performed by the same individual on a small project.

OPI Base Guideline

OPI has done many agile projects successfully over the past years. Each of these projects has differed slightly in their implementations, while at the same time followed similar steps to success. Many of these steps are common sense approaches to software development. This document describes those common steps that almost every project can follow to help ensure success. As with past projects, this document puts the ultimate flexibility into the hands of the Project Team with regard to how to put this guideline into practice on individual projects.

Guideline Overview

In summary, the OPI agile process focuses on developers attempting to produce a Feasibly Testable Product in a fixed time-period, called an Increment. Each Increment contains a number of work cycles called Iterations. Iterations are 2-4 weeks in duration, and each Increment is approximately 6 weeks in duration. Using the same duration for successive Increments provides for easier planning and more reliable release forecasting. Using the same duration for Iterations improves predictability of achievable work and a shorter window into project progress which increases project transparency. The following section will breakdown the different activities recommended in our OPI Base Agile Process.

Please note this is a high level overview. If you want more details, contact us.