Time to Market
Business success factors
• Wrongly inspired by assembly-line
• Economics supported “measure twice, cut
once” leading to up-front planning and BDUF
• Single-pass, sequential process with hand-
offs and feedback loops between adjoining
• Transition to next phase only upon completion
of current phase
• Focus on Documentation
Waterfall Software Development
Limitations and Assumptions
1. Wrong analogy: Software development ≠ Production
2. Customers know EVERYTHING upfront and that requirement won’t change
3. Legacy: implicitly assumes CPU time is costly, so focuses on doing everything upfront to minimize ‘machine time’ for trial and error
4. “Wicked Problem”: Designers and developers know how exactly how to build
5. Very long feedback cycles not suitable for today’s pace of innovation
Preamble to Agile Movement
Software Crisis, 1965-85: The major cause of the software
crisis is that the machines have become several orders of
magnitude more powerful! To put it quite bluntly: as long as
there were no machines, programming was no problem at all;
when we had a few weak computers, programming became a mild
problem, and now we have gigantic computers, programming has
become an equally gigantic problem. — Edsger Dijkstra, The
The causes of the software crisis were linked to the overall complexity of
hardware and the software development process. The crisis manifested itself in
• Projects running over-budget.
• Projects running over-time.
• Software was very inefficient.
• Software was of low quality.
• Software often did not meet requirements.
• Projects were unmanageable and code difficult to maintain.
• Software was never delivered.
• Process: Long-lead development process ineffective in a
dynamic and global world
• Management: Command and control model unsuitable for
fostering collaboration required to solve complex problems
• Technology: Advancements in computers, compilers,
debugging and testing tools greatly altered the economics
of software development
• Innovation: in the age of hyper-innovation, old
processes were simply ineffective
• Incremental development
– is a scheduling and staging strategy
– in which the various parts of the system are developed at
different times or rates,
– and integrated as they are completed.
– It does not imply, require nor preclude iterative development or
waterfall development - both of those are rework strategies.
• The alternative to incremental development is to develop the entire
system with a "big bang" integration
• Iterative development
– is a rework scheduling strategy
– in which time is set aside to revise and improve parts of the system.
– It does not presuppose incremental development, but works very well with
it. A typical difference is that the output from an increment is not
necessarily subject to further refinement, and its' testing or user
feedback is not used as input for revising the plans or specifications of
the successive increments. On the contrary, the output from an iteration
is examined for modification, and especially for revising the targets of
the successive iterations.
Incremental vs. Iterative
Incremental and Iterative
Advent of Agile and Lean Methodologies
• 1970: Royce critiques Waterfall and offers improvement ideas
• 1986: Barry Boehm proposes Spiral Model
• 1971: Harlan Mills proposes Incremental Development
• 1987: Cleanroom Software engineering
• 1991: Sashimi Overlapping Waterfall Model
• 1992: Crystal family of methodologies
• 1994: DSDM
• 1995: Scrum
• 1996: Rational Unified Process framework
• 1997: Feature Driven Development
• 1999: Extreme Programming Explained
• 2001: Agile Manifesto is born
• 2003: Lean Software Development
• 2005: PM Declaration of Interdependence
• 2007: Kanban-based software engineering
• 2008: Lean Startup
• 2009: Scrumban
• 20xx: Something new !?! (hopefully!)
Our highest priority is to satisfy the customer through early and
continuous delivery of valuable software.
Working software is the primary measure of progress.
Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
Deliver working software frequently, from a
couple of weeks to a couple of months, with a preference to the shorter
Continuous attention to technical excellence and good design
Business people and developers must work
together daily throughout the project.
Simplicity--the art of maximizing the amount of work not done--is
Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job done.
The best architectures, requirements, and designs emerge from self-
The most efficient and effective method of
conveying information to and within a development team is face-to-
At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly.
Waterfall vs. Agile
Economies of software development continue to evolve & impact s/w development
Waterfall was (perhaps) the best we had back then, even if it was bad!
Agile reflects contemprary thinking in process, people and tools
Fundamental tenet is continuous feedback and improvement
Agile thinking is more important than specific methods and mechanics
Focus on getting the right talent and let them self-organize