Tag: Waterfall

Introduction

Over the course of my career in software development, I have had the fortune of working in a wide variety of companies employing radically different approaches to the software development life-cycle (SDLC). Some strictly stuck to traditional Water Fall. Others called themselves “agile” but never actually bothered to adopt any agile framework, and were thus a blend of Water Fall and Agile—and all too often, not a successful blend either. Another strictly adopted a true agile methodology and decided that there was no need for a PMO since, as they put it, “we’re SCRUM.” Other companies used the same Scrum methodology but saw the value of having a PMO as well.

As I have closely followed discussions on Project Times (and other blog sites), I have noticed some discussions around Project Management methodologies that are fine in theory, but often seem divorced from real-world applications. You can often find arguments prefaced by statements such as “good project managers do X,” or “the PMBOK methods require Y,” or even “any experienced Scrum Master knows…”

After working in so many different environments, the most important lesson I learned was that a dash of humility goes a long way. In other words, no matter what framework is employed, most companies will adapt the theoretical suggestions of the framework to make it work for their needs. Project Managers who suffer from what I call “theoretical myopia” may fail to see the value in the adaptations the company has chosen. A strict enforcement of a theoretical framework, without regard to results, is sometimes just as harmful as not enforcing any framework or process at all.

Target audience

There are several types of readers for whom this article is intended. Some readers may currently work in Water Fall environments and may not have any experience with agile. Others may work in companies that claim to be agile, but really are not. And a few others may work in true agile environments that strictly follow the guidelines provided by whoever trained them in that framework, and don’t realize that there are “many ways to skin a cat.”

Let’s answer the question: “What is agile?”

The simplest explanation is that it is an approach to development based on iterative and incremental development. It is characterized by “adaptive planning,” “evolutionary development and delivery,” “time-boxed” iterations that result in incremental releases of functional product, and must provide rapid and flexible response to changes and discovery.

What exactly does this mean in the real world? One must remember that in the traditional “Water Fall” approach, the project flows through a series of steps or gates, and does not progress to the next step until the current one is complete. As an example, Requirements Gathering only begins once the Project Charter and Statement of Work (SOW) have been approved and signed off. Development begins only once the full set of requirements for the entire solution are gathered and approved by all stakeholders. A testing phase begins when the entire platform is developed. Because the development phase can last for many months, even years, before code is released, Project Managers may struggle to differentiate accurately between perceived progress (often reported as developers’ guesses of “percent complete”) and actual progress. This, in turn, results in unpleasant surprises when the delivery date looms two weeks away and the developers unexpectedly report that they still have eight weeks of work to perform!

What is the unsurprising response from senior management and the client? “Why didn’t we know we were behind schedule earlier?”

As a concrete example, let’s look at a real-world application, first for a Water Fall approach.

Think about developing a Web page, especially one designed to handle flight reservations. In a Water Fall approach, many weeks would be spent gathering comprehensive requirements for the entire page and every field on the page. This would include not just a list of fields but all the validation rules for every data point. Development would not begin until this comprehensive document was completed and then agreed upon by stakeholders.

Once the requirements were gathered and approved, development begins. The entire page (or even the entire website with all functionality) would then be created and tested. The page or site would then be released to the customer. This same process might be performed not only for the initial home page, but for every subsequent page in the site.

In many cases, the very first time the customer saw the direction the team had gone is when the page, or entire site even, is unveiled for the first time in a customer demo. This is when many customers balk in frustration because the released product did not accurately represent what they thought they had described. A crisis ensues because the client is very unhappy that functionality is unsatisfactory. From the development company’s perspective, changes to the design and implementation are quite difficult and very expensive.

I will make the comparison by examining the Agile framework I know best, which is Scrum. In Agile development, high-level ‘requirements’ are gathered during the project estimation phase, often when the project charter (or SOW) is being written. This information is gathered in “user stories” (or other equivalent) that describe how the major components are expected to behave, in terms of user experience. “As a customer, I want to be able to book a flight from one destination to another, for a range of dates.” Additional functionality may be captured in other stories, such as “Flight Cancellation,” “Reservation changes,” or “Choosing seating.”

Experienced teams are able to size the anticipated work by a measurement of complexity, rather than guessing how long it will take as a measure of time. Once work begins, refinement of requirements and behavior often occur with direct client involvement while development is underway, in an iterative process.

The Scrum approach breaks up the whole page into discreet areas of functionality and plans to work on each piece. The “Flight Reservation” page is broken into “Select an origination Airport,” “Select a Destination Airport,” “Select a range of origination dates,” “Indicate seating preferences,” etc. These become the User Stories, which are given acceptance criteria. The stories are then sized by complexity, tasked (with estimated hours for each small task), and planned out across short iterations. The stories and iteration plans are reviewed with direct client input. As development progresses, the customer sees the result every couple of weeks as each iteration (or “Sprint”) is completed. The customer then approves the output, or suggests changes that, being found early in the process, require minor “tweaks” instead of large architectural changes.

The frequency of these “demos” helps the customer participate in constant revision and modification, so each delivered piece of product is much more likely to satisfy the customer’s needs. Rework and associated cost is thus reduced. Client satisfaction is increased.

The benefits to Agile are quite simple to comprehend. The agile development cycle is designed to provide valuable functionality that accurately represents customer wishes on frequent deliveries, contrasting with the Water Fall approach, which often leaves customers waiting for long periods of time before they see the first benefit from their investments.

What agile is not

An Agile team is flexible, agile, and adaptable. The Agile team proactively elicits and documents the desired function with direct and frequent client involvement. It also frequently reviews the developed product with the client to verify that functionality meets client wishes. The talented development team is encouraged to meet those needs creatively. The project manager (Scrum Master) vigilantly monitors a daily “burn down chart” that allows the team to change direction swiftly in order to get the development back on track, in the case where circumstances have caused deviation from the plan or to quickly react to new information received.

Having laid out this basic understanding of what Agile is, and contrasting it with Water Fall, it is important to reiterate that the core concept of Agile is not a lack of process or a “watering down” of documentation! In my experience, this misunderstanding has been propagated by some managers who believe that Agile frameworks translate to nothing more than a loosening of control and reduction of analysis and planning. Improper implementation of an ill-defined concept of “Agile” can result in even graver problems arising. It has been my experience that “the cure was worse than the disease” in those cases.

I will dive into specific problematic areas in subsequent articles.