Chapter 5 Motivation Flashcards
What’s the Facts of Change on Software Projects?
The Uncertainty Principle in software acknowledges that uncertainty is a fundamental and unavoidable aspect of software projects. Data from a significant study of software projects shows that development is highly susceptible to change, with medium-sized projects experiencing about a 25% rate of change in requirements, and very large projects seeing changes of 35% or more. These high rates of change underscore the need for agile and iterative development methods. This is supported by another study by Boehm and Papaccio, which found a typical software project undergoes a 25% change in requirements. Such data highlight that traditional processes and management practices assuming low change and stability, including detailed upfront specifications, estimates, and schedules, do not align with the dynamic nature of software projects.
What are some Key Motivations for Iterative Development ?
- Iterative development is lower risk; the waterfall is higher risk.
- Early risk mitigation and discovery.
- Accommodates and provokes early change; consistent with new product development.
- Manageable complexity.
- Confidence and satisfaction from early, repeated success.
- Early partial product.
- Relevant progress tracking; better predictability.
- Higher quality; less defects.
- Final product better matches true client desires
- Early and regular process improvement.
- Communication and engagement required.
- IKIWISI required.
Chapter 5 (Timeboxing Benefits)
Timeboxing, setting strict deadlines for tasks, boosts productivity mainly because it sharpens focus. Just like how people get a lot done right before a vacation, having a close deadline (like three weeks) makes teams more focused and productive compared to distant milestones (like three months). This approach counters Parkinson’s Law, which says work will stretch to fill the time given for its completion. Timeboxing also highlights that people tend to remember delays more than missing features; delivering on time with most important features is seen as a success. Additionally, short deadlines force teams to handle only what they can manage, make tough decisions early, and prioritize effectively, leading to more productive outcomes.
What are some of Problems with the Waterfall?
The waterfall model, commonly understood as a sequential approach to software development, involves detailed upfront planning, design, implementation, and testing. Originating in the 1970s as a response to disorganized coding practices of the 1960s, it was once seen as the ideal method. However, research has revealed its drawbacks, such as higher risk, failure rates, and lower productivity, especially because it struggles with complex or innovative projects. The model assumes conditions of low change, simplicity, and clear-cut tasks, which are rare in real-world software development. Winston Royce, often associated with the waterfall model, actually advocated for iterative development for most projects, highlighting a common misunderstanding of his work.
Waterfall’s main issue is postponing significant risks and challenges to later stages, in contrast to Iterative Development Methods (IID) that address these early on. The model also leads to complexity overload and delays in receiving feedback, which further decreases its effectiveness as projects grow in complexity and duration. Historically, even the Department of Defense, a former proponent of the waterfall model, shifted towards iterative methods in the mid-1990s due to the former’s limitations. Despite this, some senior executives, educated during the waterfall’s prominence, may still show resistance to adopting more modern, evidence-backed IID approaches.
Problem: “Complete” Up-front Specifications with Sign-off
The problem with trying to specify everything about a project in detail before starting is that it often doesn’t work out. Proponents of iterative development would like it if they could set perfect, unchanging plans at the beginning, but studies show this is rarely achievable. In fact, a significant study found that nearly half of the features planned early on were never used, and another good portion was barely used. This suggests a need for a flexible, evolving approach to project requirements rather than fixed, upfront specifications.
Problem: Late Integration and Test
In the mid-1990s, a big project involving more than 200 developers from different locations failed because when they tried to combine all their work at the end, it just didn’t fit together. Misunderstandings and incorrect assumptions about how the different parts were supposed to work together only became clear too late, leading to the project being cancelled.
Problem: “Reliable” Up-front Schedules and Estimates
Trying to make a detailed plan or estimate for the entire project before starting, especially in innovative and complex projects, often doesn’t work. Such detailed early planning is more suited to routine, low-change tasks, not creative projects where things change a lot. While having reliable early estimates would be ideal, it’s just not realistic when dealing with projects that involve a lot of unknowns and changes. Instead, focusing on flexible, adaptive planning that can adjust as the project progresses is more effective. This approach allows for better handling of unforeseen challenges and changes in priorities. Essentially, while it’s tempting to try and map everything out from the start, it’s like pretending to know how a story ends before you’ve even met all the characters. It’s better to adapt as you go, especially as complex issues become apparent, rather than sticking rigidly to an initial plan that’s likely to fall apart as the real work unfolds.
Problem: “Plan the Work, Work the Plan” Values
The idea of making a detailed plan and then strictly following it works well for predictable tasks like manufacturing but doesn’t fit the unpredictable nature of software development, where changes and new ideas frequently occur. This old approach matches the waterfall model, which doesn’t align with agile principles that favor flexible planning, allowing teams to organize themselves, and adapting as the project evolves. Agile methods don’t skip planning; they just keep plans flexible and give teams more control over decisions and tasks.
Meeting the Requirements Challenge Iteratively
Meeting the challenge of changing requirements in software projects means recognizing that requirements often change during a project. Studies have shown a significant portion of project challenges and defects are related to issues with requirements. Despite the desire for stable requirements, they tend to change by 25% or more, making early detailed analysis and freezing of requirements ineffective. In fact, a lot of specified features end up not being used at all. Traditional methods that try to lock down requirements early often lead to project failure. Instead, an iterative approach with evolutionary requirements is recommended. This method accepts and adapts to changes early on through feedback and iterative development, proving to be a more effective way to handle the inevitable changes in project requirements.
