A Page of History: 1975 "Iterative Enhancements"

The dawn of Agile and Iterative Development comes in the 90s, and the "end of the beginning" was the 2001 Agile Manifesto. Anyway, as Kent Beck has recognized, his generation has, in fact, "rediscovered" some principles and practices that have been use by their predecessors.    

Alistair Cockburn has recently bring back in attention (tweet) a page of history for software development, the 1975 description explicit of Iterative Development: 

Iterative Enhancements: A Practical Technique for Software Development, by Victor R. Basili and Albert J. Turner  (IEEE Transactions on Software Engineering, Vol. SE-1, No. 4, December 1975)  

More, you can find here other "Agile" practices and principles: 

• "Refactoring" guidelines: redesign approach similar with XP - Extreme Programming
• "Active Stakeholder Participation": user reaction always required for feedback - similar with  Disciplined Agile "Active Stakeholder Participation"
• "Inspect and Adapt" - an review result-goals approach similar with Scrum Principle 
• Context count and tailor process to context principle, similar with Disciplined Agile approach
• "Proven Architecture Milestone" - Start with an initial skeletal sub-problem, that contains "key aspects of the problem" , "...whose implementation would make a usable and useful product available for the user". This approach is very similar with the en-to-end skeleton from the Discipline Agile "Proven Architecture Milestone".  ... and more: use of this milestone & the iterative approach to make progress toward a "Consumable Solution" and clearly suggest a "Risk-Value Lifecycle", such in Discipline Agile. It is interesting that the author clearly start the description of the method with this part. In my understanding, their approach is somewhere in the middle between "Proven Architecture Milestone" and "Do it twice" advice of Winston Royce from 1970, but applied in an iterative context.

Important: this 1975 paper was a report of their concrete work and experience with development of production compiler for SIMPL-T language.

References 

• Iterative Enhancements: A Practical Technique for Software Development, by Victor R. Basili and Albert J. Turner (IEEE Transactions on Software Engineering, Vol. SE-1, No. 4, December 1975)
• Extreme programming explained: embrace change, Kent Beck, Addison-Wesley Professional; US ed edition (October 5, 1999).
• Managing the development of large software systems , by Dr. Wiston W. Royce 
• Disciplined Agile, Prove Architecture Early - http://www.disciplinedagiledelivery.com/prove-architecture-early/
• Disciplined Agile, Produce a Potentially Consumable Solution http://www.disciplinedagiledelivery.com/produce-a-potentially-consumable-solution/
• Disciplined Agile, Risk-Value Lifecycle - http://www.disciplinedagiledelivery.com/process/risk-value-lifecycle/
• Discipline Agile, Active Stakeholders Participation - http://agilemodeling.com/essays/activeStakeholderParticipation.htm
• Scrum Guide 2016, US edition - http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf#zoom=100

 

Agile Manifesto - history page

The Manifesto - "Values" page - http://agilemanifesto.org/

The principles  - http://agilemanifesto.org/principles.html

and (!)

The history - http://agilemanifesto.org/history.html

• The "historian" - Jim Highsmith
• Agile term - Martin Fowler idea
• All - "delighted by the final phrasing" (Alistair Cockburn)
• Biggest debate .... the  location
• Purpose: "get all the lightweight method leaders in one room." (Robert C. Martin)
• Jim Highsmith: "The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology"

Why to read this history page? Values and principles are not enough?

In fact, you can find on this story of Jim Highsmith some very interesting stuff about Agile and directly from the source some motivations related to selection of these values and principles. Some examples below.

"We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes"

 Yes, you are a "traditionalist" and you like document, but ... you have a positive response to these questions:

• Do you keep your documentation updated, so its truth value it is true?
• How useful it is this documentation?
• The effort to keep the documentation update is too high?

 

"We plan, but recognize the limits of planning in a turbulent environment"

Read  first  (in the same page) the story of Kent Beck about a "Dilbertesque organization". You cannot make plans and then change the plan hypotheses and believe that will still work. The "turbulent environment" it is in fact the default for software development. The requirements will change? The solution are standardized?

Thank you Jim Highsmith for this page of history!

The Story of Agile Manifesto

You can find the full article here:

http://www.informit.com/articles/article.aspx?p=1743276

>>>
InformIT: You were a co-author of the Agile Manifesto in 2001. What drew you to the gathering?

Bob: In 2000 I asked Martin Fowler to lunch to talk about the idea of a "Lightweight Process Summit." We were both part of the Extreme Programming movement, but we had seen that there were several other similar processes, most notably SCRUM, FDD, DSDM, and Crystal. We thought it would be a good idea to get the advocates of all those processes together with other industry leaders to see if there wasn't some way to find and define common ground. I suggested to Martin at the time that we might be able to create some kind of manifesto. He and I put an invitation list together. I composed the invitation and sent it out. After that the process took on a life of its own.

>>> ("Ten Years Of Agile: An Interview with Robert C. "Uncle Bob" Martin")

The idea (and the initiative) of a "Lightweight Process Summit" and of the manifesto that could define the common ground of that kind of movement belong to Robert C. Martin. "Uncle Bob" and Martin Fowler have created also the invitation list... The resulted manifesto is quite outstanding, at least for the ones that have good experience with software development and could serve as guidance for every practitioner.

Yes, we can say that all those methods are "implementing" these principles, but the great thing is that it was first the demonstration: methods and practices resulted from experience and proven to be working. This "theory" (the values and associated principles) are just the abstraction of real experience.

Thank you, Uncle Bob! :)

Note: "The Manifesto of Softwarecraftsmanship" has the same creator.

Agile B.C.

Le Serment des Horaces-  painting by Jacques-Louis David

 Divide et impera!

~650 B.C. The military conflict between city of Rome and city of Alba Longa was decided by direct confrontation of some young soldiers: three Horatii (Romans) and three Curatii (Albans). After battle begins <<two of the Romans fell, fatally wounded, one upon the other, while all three of the Albans were wounded.[…] and though no match for his enemies together, was ready to fight them one at a time.>> (Titus Liviu) ... and the remaining  Horatius was able slay them one by one.