The laws that enable agile software development
- 1. THE LAWS THAT ENABLE AGILE SOFTWARE DEVELOPMENT
- 2. THREE AUTHORS FOUND OUT SOUND, CONSISTENT CAUSE-EFFECT RELATIONSHIPS WHICH TURNED OUT TO BECOME “LAWS” OF SOFTWARE ENGINEERING. THESE “LAWS” HAVE BEEN AROUND FOR DECADES, BUT THEY APPLY PERFECTLY TO THE PRESENT DAY AND, MORE IMPORTANTLY, THEY PROVIDE RELIABLE GUIDELINES FOR ADOPTION OF AGILE TECHNIQUES. FINALLY, THESE “LAWS” AREN’T SUPPOSED TO BE UNBREAKABLE; THEY MUST INSTEAD BE REGARDED AS PATTERNS FOR VERY FREQUENT SITUATIONS IN SOFTWARE PROJECTS. THREE MAIN LAWS
- 3. The first one is Brooks’s Law, by Fred Brooks, Jr: “Adding manpower to a late software project makes it later.” *https://it.wikipedia.org/wiki/Legge_di_Brooks *https://en.wikipedia.org/wiki/Brooks's_law
- 4. The second law is Boehm’s Law, stated by Barry Boehm, and it’s about the well known fact that, during a software project, costs to find and fix bugs get higher as time goes by. Costs up as bugs take more time to find*https://en.wikipedia.org/wiki/Barry_Boehm
- 5. The third one is Conway’s Law, created by Melvin Conway: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” *https://en.wikipedia.org/wiki/Conway%27s_law
- 6. Other laws in agile Dude’s Law If you don't have a good reason for the project, it doesn't matter how well you do it. Project Value=Why/How Law of the Instrument If all you have is a hammer, everything looks like a nail Humpherey's Law "The Centipede's Dilemma"- short iterations and review meeting. (The user will never know what they want until after the system is in production, maybe not even then)
- 7. Parkinson's Law Work expands so as to fill the time available for its completion Goodhart's Law When a measure becomes a target, it ceases to be a good measure Low of the Propinquity The probability of two people communicating is inversely proportional to the distance between them Little's Law if you work on twice as many things in parallel, it'll take twice as long Cycle Time=Working in Progress/Troughput Other laws in agile