Agile and Iterative Contrasted with Waterfall

By -
In his book Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design and Iterative Development Craig Larman provides this contrasting view of Agile, Iterative development with the sequential or Waterfall approach:
We rely on short quick development steps, feedback, and adaptation to clarify the requirements and design. To contrast, waterfall values promoted big up-front speculative requirements and design steps before programming. Consistently, success/failure studies show that the waterfall is strongly associated with the highest failure rates for software projects and was historically promoted due to belief or hearsay rather than statistically significant evidence. Research demonstrates that
iterative methods are associated with higher success and productivity rates and lower defect levels.

I especially like his description of the up-front requirements and designs as "speculative." In the interest of keeping a project on schedule, the project manager following a waterfall approach will press the user group and business sponsor to sign off on a set of requirements and designs so developers can begin coding. Once the requirements and designs have the sponsor's sign off, all changes are managed through change orders with cost implications. This has the negative effect of penalizing the sponsor and treating the business users as if they don't really understand their business processes very well. In reality, the business users understand the de facto process very well, but usually are not adept at describing it at the level of detail that a final set of requirements demands. They are more likely to "know it when they see it." That is, when the business users can see prototypes or the first pieces of working code delivered and can put their hands on the keyboard to begin using it, then they can speak more authoritatively about what works and doesn't work for them in support of their business processes.

An agile, iterative develpment approach allows all stakeholders to act with greater honesty and integrity about the software development process and therefore has a greater chance of succeeding.

For an more thoughts along these lines, see The Challenge of Requirements by Abhijit Nadgouda and Software Requirements are Elusive: 6 Reasons Why Customers Cannot Get Them Right.

Comments

Post a Comment

Popular posts from this blog

Severity, Priority, Impact and Likelihood - Managing Defects and Risks

By -
Defects and Risks are often dealt with in a subjective, emotional way.  That's unfortunate, because among all the things a software development team deals with, those are two that can be handled in a more constructive and empirical way. First, a couple definitions. Defect Severity: the degree of impact a defect has on system operation. A defect is something observed, so impact can be empirically quantified. Risk Severity: the degree to which a hypothetical event, should it occur, would impact system operation. A risk event is something that has not occurred, so impact must be estimated or extrapolated. The common element in both Risk Severity Assessment and Defect Severity is Impact on Revenue.  The FMEA framework that AKF recommends uses 1 = Low, 3 = Med, and 9 = High, to represent the exponential effect of a high impact risk or defect Impact on Revenue No payments being collected and/or payment data security compromised (Critical) Payment collection being de
Read more

Enterprise Agile Framework: The Entrepreneurial Operating System (EOS)

By -
Image
Brian Rabon introduced me to the Entrepreneurial Operating System (EOS) as the framework he uses to manage his company, The Braintrust Consulting Group (TBCG). EOS is the missing element in organizations that are having some success with Agile at the team level, but not succeeding with change at higher levels or outside software development. As Charlie Rudd points out in his post The Third Wave of Agile , there is broad consensus on the value of Agile practices at the team level, but all types and sizes of businesses are struggling to scale Agile and to increase agility across their organization.  I think EOS addresses those challenges. EOS is comprised of the EOS Model : Having a model like this in place allows teams to function optimally as self-organized units that share the vision and goals of the organization.  Teams are able to align themselves with the organization's objectives, and can see how their outcomes affect the organization's performance. The EO
Read more

Chatbot Code of Ethics

By -
A  NYTimes article  describes efforts by a consortium of the largest technology companies to create ethical standards for AI. A related article in MIT Technology Review is titled  AI Wants to Be Your Bro, Not Your Foe . Artificial Intelligence has reached a level of sophistication, and is on the brink of being so pervasive, that we can have these serious conversations. In my work developing AI-powered chatbots to assist with learning, I work within the bounds of these 7 precepts: Right View - our chatbots honor humanity, human dignity, and the human quest for knowledge, understanding and technological innovation Right Intention - our chatbots promote human progress in the areas of intellectual pursuits and personal ethical development Right Speech - our chatbots use encouraging, prudent, and situationally appropriate language Right Action - our chatbots perform with integrity toward the aforementioned right view and intention Right Live
Read more