Agile 1 – On the beginnings of agile
Copyright Graham Berrisford. One of several hundred papers at http://avancier.website. Last updated 29/05/2019 14:47
This is the first in a series of mostly short papers.
2. On agile software development
3. On agile businesses and systems
4. On systems thinking ideas used in agile
5. What is agile architecture?
6. EA in the world of agile architecture
In the last decade, almost every
architect in my classes says their organisation use agile methods
Most use SCRUM or similar, and many
say Kanban as well.
Few realise agile
development principles are older than programming.
In 1943, agile design and development
principles were promoted in the “Skunk Works” division of Lockheed Aircraft
Corporation.
Kelly’s rules for Skunk Works say nothing about what is
being designed (aircraft); they are about engineering project management.
1. The Skunk Works® manager
must be delegated practically complete control of his program in all aspects.
He should report to a division president or higher.
2. Strong but small project
offices must be provided both by the military and industry.
3. The number of people having
any connection with the project must be restricted in an almost vicious manner.
Use a small number of good people (10% to 25% compared to the so-called
normal).
4. A very simple drawing and
drawing release system with great flexibility for making changes must be
provided.
5. There must be a minimum
number of reports required, but important work must be recorded thoroughly.
6. There must be a monthly cost
review covering not only what has been spent and committed but also projected
costs to the conclusion of the program.
7. The contractor must be
delegated and must assume more than normal responsibility to get good vendor
bids for subcontract on the project..
8. The inspection system...
should be used on new projects. Push more basic inspection responsibility back
to subcontractors and vendors. Don't duplicate so much inspection.
9. The contractor must be
delegated the authority to test his final product in flight. He can and must
test it in the initial stages. If he doesn't, he rapidly loses his competency
to design other vehicles.
10. The specifications applying to
the hardware must be agreed to well in advance of contracting. The Skunk Works
practice of having a specification section stating clearly which important
military specification items will not knowingly be complied with and reasons
therefore is highly recommended.
11. Funding a program must be
timely so that the contractor doesn't have to keep running to the bank to
support government projects.
12. There must be mutual trust
between the military project organization and the contractor, the very close
cooperation and liaison on a day-to-day basis. This cuts down misunderstanding
and correspondence to an absolute minimum.
13. Access by outsiders to the
project and its personnel must be strictly controlled by appropriate security
measures.
14. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.
Kanban (often associated with agile methods) is a scheduling system for lean and just-in-time manufacturing developed by Taiichi Ohno at Toyota.
Wikipedia says it “originates from the simplest visual stock replenishment signaling system, an empty box.”
This was “first developed in the UK Spitfire factories
during the Second World War the late 1940s.”
In the 1950s and 60s, other iterative
and incremental development methods emerged.
The 1970s saw more evolutionary
project management and adaptive development approaches.
IBM promoted Joint Application
Development (JAD) workshops.
By 1990, James Martin’s Information
Engineering approach presumed Rapid Application Development (RAD).
The Dynamic System Development Method
(DSDM) was published in 1994.
In 2001, the Agile Manifesto was
published. Compare it with Kelly’s rules
Kelly’s rules for Skunk Works - 1943 |
The
Agile manifesto – 2001 |
(3) Use a small
number of good people. |
We value
individuals and interactions - over processes
and tools |
(9) The
contractor must test his final product in flight [and] in the initial stages. (5) A minimum
number of reports required, but important work must be recorded thoroughly. |
We value working
software - over
comprehensive documentation |
(12) There must
be mutual trust between the [customer] and the contractor [and] very close
cooperation and liaison on a day-to-day basis |
We value customer
collaboration - over contract
negotiation |
(4) A very
simple... release system with great flexibility for making
changes must be provided. |
We value
responding to change - over following
a plan |
So, agile methods have been around
for decades.
The values in the manifesto reflect those used in engineering and software projects from the 1940s onwards.
The first rapid/dynamic application development
conferences and methods were primarily a reaction against waterfall projects.
Mostly no; they were more a reaction
to earlier approaches.
Royce had defined a "waterfall"
software development method in 1970.
But the failures of large waterfall projects in the 1980s led people to look for more "rapid", "iterative" and "dynamic" development methods.
This coincided with the introduction
of graphical user interfaces and OO programming languages (OOPLs).
Naturally, the development of user
interfaces proceeds best in a collaborative, incremental and agile way.
For this and other good reasons, OO
programmers adopted, developed and promoted agile practices.
Agile development methods do include
particular software engineering practices.
However, practices like pair
programming and test-driven design (in extreme programming (XP) are not
specific to OO programming.
Yes.
Kelly’s rule 10 (below) was that
“the specifications of hardware must be agreed to well in advance of
contracting”.
Similarly, agile
development methods recommend stabilising the “infrastructure” in advance of
software development.
Where
the infrastructure can include not only platform technologies but also any
persistent data structure that must be populated and maintained.