There's a discussion of sorts (as it always turns out on email) about "what is agile" on the Agile Management forum. One poster has suggested that "being agile" means adhering to three principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Deliver working software frequently, from a couple of weeks to a couple of months...
- Working software is the primary measure of progress.
And of course there is the agile manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
So starting with the Agile Principles and broadening the target projects to beyond just software in an XP-style environment (small team, onsite customer, two week iterations) what does this mean for Agile Project Management? Say the agile project management of a $30M ERP rollout, or a $4M product development effort based on software, firmware, and hardware in equal amounts? In an environment where the customer is no longer singular - HR, Procurement, Finance, Facilities, IT, Customer Service for the ERP system or a Product Marketing organization and the distribution channel partners for the resulting product?
Let's take the three principles one at a time using Capabilities Based Planning and our favorite IMP/IMS processes:
- Customer satisfaction through early and continuous delivery of valuable software - if we deliver incremental assessment points along the path to completion are we being agile? If at each maturity assessment point there is a collection of usable functions in the ERP system or testable capabilities in a product are we being agile?
- Frequent delivery of working software - frequent needs to be defined of course, but frequent would likely mean more than a few times across the project life. Every two weeks is frequent, every 6 months probably not, once a year certainly not. But what's a appropriate span of time for frequent.
- Measure progress through working software - if we only measure progress by the delivery of software, then there needs to be activities taking place prior to the start of the software project. Market assessment, business requirements, technical procurement decisions, service engagement agreements. Because the production of software may depend on these resources being in place - if we're only measuring progress by producing working code. How about if we measure progress by assessing the level of maturity of the project? Are we increasing our capabilities to do productive work in the business or use the product in a productive way? If we had some way to "test" the increasing maturity of the project, would that be agile or is only the appearance of code the test? What about software baas ed projects that don't produce code, say SAP rollout, can they be agile in the absence of code production?
The discussion of "what's an agile project look like?" seems to be important in light of the initiatives to change how we manage projects.
