There has been a lot of interest in Agile Project Management in recent years despite the fact that, at its core, Agile is more aligned with single product, team management than projects involving complex systems. Indeed, in Scrum (the most popular variant) there is not even a role for a Project Manager.
A key element missing from some of the popular support tools for Agile software development (eg Jira/Greenhopper, Rally, Basecamp et al) is dependency management. This, coupled with an approach to architecture that is often seen as an emergent element, creates a trap for those that might try to adopt Agile ‘Project Management’ without considering the higher levels of abstraction.
I am reading (or rather skimming) an excellent book that makes exactly this point and others [Agile Software Requirements – Lean Practices for Teams, Programs and the Enterprise - Dean Leffingwell, 2011 Addison-Wesley]. This text echoes my own thoughts as Dean takes a PPM view with a Portfolio being guided by overarching investment themes that drive “Epics” which are incrementally realised through a Program of “Releases”. Only below this Release level does the Kanban and common Agile processes (eg Scrum) come into play.
Someone needs to be managing the other levels to ensure the Release Train delivers the features, performance and architecture anticipated by the Epics. In a single-product world this is primarily the lot of the Product Manager. However, in a more complicated case integrating systems incorporating simultaneous hardware and software development from disparate vendors, this is not going to be enough. In this case there will need to be convergence on key architectural decisions and points of integration through a solid systems engineering process. This will necessarily happen at a level of abstraction above any individual product.
It is at this system level that the more traditional Program and Project Management paradigms retain their value: managing dependencies, managing interfaces and maintaining alignment with overarching business needs. An iterative, incremental and risk-driven approach is, of course, sound but it is how this is implemented that needs careful consideration. Agile is not a panacea but merely a component of one. Rolling-wave planning (supporting an incremental learning culture), milestones related to proven functionality or performance and incremental funding have all been parts of R&D programs in defence and aerospace industries for some time. The adoption of Agile vertically through the enterprise should be an adaptation rather than a whole-scale change.
Back at the lowest level, another cautionary element is that, whilst team empowerment should have obvious benefits, treating the team like cogs in a machine is likely to undermine this goal. Kanban systems work in Production operations where there is a high degree of repetition. Moreover, such systems are often reserved for low-cost, high-use components where the ROI from full inventory management is poor (eg gloves, pens, nuts & bolts). A recent blog post [by Brian de Haaff] compares the Kanban process in software development to a fad diet that is starving the engineers intellectually.
The potential fall-out from this is disconcerting.