Does methodology really make anything any better? I think it’s better to latch onto the principles that underpin Lean, Agile, Scrum et al. The principles are sound software engineering and project management ones. Ones that predate any of the current favourites. Iterative and incremental development, continuous integration, automated testing … these have been around for decades. If you need an analogy, think of true innovators in tech – it isn’t Apple, Microsoft, Facebook etc. They used what was already there, and commodotised them effectively. Who invented C, or the GUI, or the mouse? Does anyone care? Iterative and Incremental development has long history ….
[blue_box]IID [terative and Incremental Development] grew from the 1930s work of Walter Shewhart, a quality expert at Bell Labs who pro-posed a series of short “plan-do-study-act” (PDSA) cycles for quality improvement. Starting in the 1940s, quality guru W. Edwards Deming began vigorously promoting PDSA, which he laterdescribed in 1982 in “Out of the Crisis”. Tom Gilb and Richard Zultner also explored PDSA application to software development in later works.
Computer Iterative and Incremental Development:A Brief History[/blue_box]
I particularly like the fact it was a QA guy behind it – it makes total sense that evolutions of quality and efficiency in coding would come from QA. QA is another area that in fact does not care what badges people carry. We adapt, recommend but ultimately work to same goals of code quality and client satisfaction – and the two are not mutually exclusive. You don’t have to sell good coding, but showing actual coding. It often manifests in performance, usability and maintainability – words a client will understand. Whilst I am a little weary of the same circles that happen with the saleable methodologies, one approach rejuvenated my interest in newer development practices, which as you can tell from most posts over last year, is BDD – Behaviour Driven Development. It can be viewed as a strict Lean approach – the stripped-down development/client model. I like Lean – there is little room for “project wallflowers”.
Ironically, I have been on Lean projects, where management heavily outweigh the number of developers. Such is the pull of these buzzwords, management gravitates towards them like moths to a “another skill for the old cv” flame. I have said it many times, that fundamentally things don’t change that much – a strong team with good cross-functional skills will cut through any methodology bullshit and deliver. My opinion is that it is management that lagged behind, and is still area that can do far more damage than a bad developer ever could. But it is still not seen that way round. If all a manager is doing is acting as interface with a client, then they are simply an obstruction – by Agile or Lean philosophy. Empowering the team does not mean empowering their manager.