Traditional (waterfall) approach to software development
Some clients demand firm fixed-price (FFP) contracts, payments tied to milestones, and guaranteed functional requirements delivered at the end of the project. Agile development is not conducive to rigid contract requirements like this. The only effective methodology to deal with rigid contracts is the waterfall method of web development because in order to fix the price, payments, and deliverables; a contractor must require a fixed scope of work and absolute clarity with regard to requirements specifications, timing, and standards of acceptance.
To manage the risk of a fixed price contract, it is important to invest time up front analyzing the requirements, documenting the precise scope of work, and developing clear use cases and acceptance test plans prior to moving forward. With fixed-price contracting, we cannot move forward into design until all discovery documents have been clarified and approved. Likewise, we cannot move out of design and into development until all of the designs have been approved, because it is very costly to change design after we are in development. We cannot deploy a project into the live environment until development has been thoroughly tested and approved.
Because these distinct milestones must be approved at each stage, and work on the next phase does not being until work on the previous stage has been completed, the project plan takes on a waterfall-like appearance. For this reason, we call this approach the classical Waterfall Development Methodology.
For this approach, we will agree on a firm-fixed price not-to-exceed (NTE) limit. At the end of every month, we will receive progress payments against this NTE limit but also tied to the performance milestones defined in the project planning chart. We may need to have two task orders; one for discovery, needs analysis, and user acceptance test planning. Then, once we have defined the scope of work and verified the estimate, we would exercise a second task order to actually perform the scope of work according to the acceptance criteria.
Traditional waterfall model versus agile development
With the traditional waterfall model of software development, you typically spend months specifying requirements, then months defining the user acceptance test plan, then months developing the code, then months designing the user interface, then months testing the code, and then months debugging the code, etc. By the time you are done, if you the project hasn’t run out of cash, the finished product is often obsolete or fails to meet expectations because end users were not involved in the process and didn’t give their feedback along the way.
Agile development, on the other hand, performs these tasks in parallel. With agile we plan, analyze, design, develop, document, and test simultaneously and iteratively. Agile avoids excessive documentation and requirements specifications up front, preferring instead to specify and analyze only enough details to plan the next 2-3 week sprint, while keeping the ultimate road map and wish list set off to the side. A common misunderstanding about agile is that we don’t document or plan when in fact we tend to invest more time and energy in planning and documenting because the plan is always evolving. We are always revisiting and revising the plan based on the continuous feedback loop we get from our client and the ultimate web visitors.
Agile development emphasizes customer collaboration over contract negotiation. Being agile means providing a flexible process that anticipates and embraces change, allowing the team to adapt to evolving requirements and unexpected developments or priorities.
Government contracting and the waterfall methodology
Back in the day, some of us remember working a couple of years defining, specifying, and analyzing requirements for huge, 200 million dollar, command and control, information systems for the Department of Defense (DoD). By the time we actually got to coding, the requirements were often already obsolete. But, we had to keep moving forward because of contract requirements. By the time we actually delivered the system, if it actually got delivered, it was millions of dollars over budget, years past due, and was no longer what the customer needed.
Contemporary agile method of web applications development
The problem is that many people say they want Agile but don’t really understand how it works. Even worse, they don’t have the financial system, procurement system, contract system, or trust required to allow it to work. But, the worst problem is that in order to have a firm-fixed price contract, which only the traditional waterfall methodology can support, you need to be an expert estimate, a psychic, and have a crystal ball. In truth is, nobody knows exactly how long it’s going to take to develop any piece of software. It’s always an estimate, it’s never an exact science. Estimating web development is an art.
Agile development has a rub (drawbacks)
For most organizations, they want a guarantee that a laundry list of items and functionality WILL BE DELIVERED as part of the contract and there will be a Firm Fixed Price (FFP) associated with this contract. They want to make sure that everything, including the kitchen sink will be delivered – even if they don’t need a kitchen sink – and that there will be an absolute ceiling in place for costs. Agile doesn’t work this way. It takes a huge amount of trust, faith, and an open mind on the side of the client to allow agile to work properly.
The thing about Agile is that its purpose is to get a minimum viable product out there working, tested, and being used by people. Then, you get feedback on its usage. Based on how people use it and that feedback loop, the things on your wish list might change. You could re-prioritize, add new things, get rid of things, or change course completely. If the project fails, it will fail fast. You don’t need to waste 3 years and a million dollars to see it fail. You can expedite that process. Most organizations that hire web development companies simply cannot conform their contracts, culture, and way of thinking to accommodate a true agile approach.
