Basic Waterfall . . .
My background in software development started in the early 1980s, so the waterfall development approach was fully ingrained in my psyche. I had always been interested in new approaches and collaborative concepts for iterative improvement and collaboration.
Quality Circles . . .
Starting in my being “volunteered” to become my department’s Quality Circle guru (Japanese Quality Circles were defined by Professor Kaoru Ishikawa in his handbook, “What is Total Quality Control? The Japanese Way”, Prentice Hall, 1985). Remember those? Few people do and I am not sure they got far outside of the manufacturing realm into the core software mindset. But they were the first time many of us experienced the concepts of Brainstorming, Fishbone Diagrams, and other team based idea generation methods.
JAD Sessions . . .
Now back to waterfall and agile. My first experience in moving from the “throw requirements over the wall” approach to collaborative software requirements was the JAD (Joint Application Development) session. While the overall project still followed the waterfall methodology, at least the up-front specifications were done in a team setting, and with participation from all parties across the software life cycle, from customer through to the QA and Deployment engineers.
Nightly Builds . . .
The next major step was on a very large project with multiple development sub-teams (I had the one handling integrations and communication protocols), where the outrageous idea of an automated nightly build was instituted. Radical, and fought against, it actually worked!
Developer Demos, Pair Programming, Shorter Iterations . . .
Then the changes just kept coming. By now I was up the management chain. I switched to smaller companies and had more control over what the full software and QA teams did, and new concepts were attempted. Resistance seemed to always be the biggest issue, but I’ll talk about that another time. For me, each attempt brought some new insight (and much hindsight) into options other than the traditional release schedule and documentation requirements.
Extreme Programming and Agile Life Cycle . . .
Now I am deep into the concepts around Agile development, and focusing more on how to contract and specify customer needs rather than implement. One last thought here, is that I strongly believe that there is never 1 right way, and there is still a place for pieces of each concept I learned along the way. The challenge (and fun) is fitting the best approach to the problem and project at hand.
This was my experience, I would love to hear yours so please comment.