Skip to content

1.3 Development Process

← 1.2 Teamwork | Home | Next: 1.4 Problem-Solving Skills →

Agile Software Development Principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Additionally: - Be comfortable with iterative and incremental development. - Have self-organizing capabilities. - Focus on priorities and business value.

Why Asking for Time Estimates Is a Terrible Idea

The core problem: There is a near-total inability of developers to predict how long a project will take.

  • The Standish Group CHAOS Report shows that only 29% of software projects are successful (on-time, on-budget, with a satisfactory result). Agile approaches show a 39% ratio of successful projects, while Waterfall only 11%.
  • Root causes: writing fully detailed specifications is essentially writing the software in advance; software projects are unique and unpredictable; developers often effectively "lie" when giving estimates due to management pressure.
  • It has become an industry standard for management to add a load factor of 2-5x to developer estimates.
  • Fixed-everything contracts (fixed scope, fixed price, fixed deadline) are the root of all evil.

Alternative Solution (Scrum + Story Points)

  1. Create a Product Backlog with user stories describing functionality.
  2. Replace time estimates with Story Points using the Fibonacci scale (1, 2, 3, 5, 8, 13, 21). Find the easiest user story and give it a 1; find the hardest and give it a 13 or 21. Estimate the rest relative to these baselines.
  3. Key principle: Never link Story Points to time equivalents—doing so ruins the entire system and causes everyone to revert to time estimates.
  4. After a few cycles, Team Velocity (the number of story points completed per cycle) stabilizes.
  5. Based on velocity and the backlog's story point rankings, you can automatically forecast when a particular story will likely be completed.
  6. Avoid the term "sprint"—it implies a burst of effort followed by rest, which goes against sustainable development. Use "cycle" instead.

Sources

  • Agile Manifesto — Principles behind the Agile Manifesto: https://agilemanifesto.org/principles.html
  • Romen Rodriguez-Gil — Why Asking for Time Estimates Is a Terrible Idea: https://www.romenrg.com/blog/2015/09/28/why-asking-developers-for-time-estimates-in-software-projects-is-a-terrible-idea-and-how-to-bypass-it-with-scrum/
  • Standish Group — CHAOS Reports (referenced within)

← 1.2 Teamwork | Home | Next: 1.4 Problem-Solving Skills →