Recently I gave a talk to a group of CTOs about Agile development, something the development shops I’ve worked in have been doing one way or another since before Agile got labeled and got its own Manifesto. It was going to be difficult to bring something to this group that they didn’t already know, so I did a lot of research beforehand.
The literature review dusted off some real gems. For one, the term “Scrum” was first used by a couple of Japanese authors to describe the way Toyota designed cars – circa 1986. But before that was Frederick Brooks’ The Mythical Man-Month which contains a wealth of best practices (1975), and before that Kelly Johnson’s 14 Rules and Practices from the Lockheed Skunkworks. That’s how they iterated supersonic hardware in the 1950’s.
Turning to the “classics” of software development I went back over the Microsoft crowd from the early 80’s – Jim McCarthy’s Dynamics of Software Development and Steve McConnell’s Code Complete, and in general the Microsoft Solutions Framework development processes – which are actually surprisingly modern, almost 30 years later. There were numerous other texts (Kent Beck’s XP from 1999) and a huge raft of post-Agile Manifesto publications, but they seemed to add less and less to the best practices in the earlier books.
When I described this progression to the CTO group they said of course, Agile development (specifically Scrum) is not about engineering best practices, it’s a project management discipline. You need to get your best practices elsewhere and bring them to Agile. Once you do that it’s a really powerful combination. This should have been obvious to me, but it wasn’t until it was spoken out loud. It also explains some of the worst “Agile failures” I’ve seen – where process overwhelmed problem solving.
So Agile development is not software engineering best practice and vise versa. With this perspective it was easy to see the difference between most of the pre-manifesto and post-manifesto books; the earlier books were mostly about software development / engineering best practices, and the latter books about Agile as a process. Perhaps the best mix was Beck’s XP, where he talks about both. I left that meeting feeling wiser.