In an article inside Crosstalk, the Air Force Journal of Software Engineering, Alistar Cockburn reviews a 1968 NATO software engineering conference. He observes that many of the core beliefs and techniques of the modern Agile software development movement aren't such recent developments after all. Both the 1968 conference and the Agile movement focus on the central effect of people over processes.
I understand that there is a strong temptation to develop processes with a mindset that success will result when all that is needed is to capture the collective history of all past processes within the current one. Over time, I believe that approach is guaranteed to be ineffective.
It's not that you don't want to develop processes, but if one focuses on the development of process before people, your process will build up unwieldyness, and the people applying it will either lose confidence in the process, or worse, may not recognize why the steps they are taking are going wrong. To capture knowledge of past projects, you need to allow time to writeup retrospectives. To transfer the knowledge, you want to encourage time for less-experienced engineers to talk and read about past projects. Then going forward, people are better informed to create and apply approaches to the problem at hand.
It takes people to figure out if things are working. For example, I don't think that most aerospace software development can blindly follow the iterate smaller / continuous flow focus of the current Agile software development. They need to consider that they're not purely software systems, and that costs of design-reversals can be much higher when hardware and physical environments are in play.
p.s. if you new to the term Agile Software development see the Agile Manifesto or search on "Agile Software", or "Lean Software" or post a comment.
