I've always felt, and said, that agile is a means to an end, not the end in and of itself. So what is the end? That's a rhetorical question of course. The reason we build software systems is to deliver value to our customers or to the business. Even a CMMI level 5 agile implementation will fail if its not driven in a manner that is delivering value. I like to abstract the software value stream as follows:
Demand flows into the funnel in a variety of forms. If you have an existing product, application or service, it may be an enhancement request or defect reported by a customer or user. Or perhaps, a line of business you support may request a major new service in support of a new business initiative. The request needs to be evaluated and measured not only against other new requests, but its value should also be assessed against existing products/applications/services in the portfolio. It may make sense to eliminate or defer and existing investment in favor of the new request to optimize software value creation.
We can create and integrate the software value using traditional or modern (agile) approaches. A traditional approach if well executed will deliver the value in a "big-bang" release. There are some advantages with that. But with current macro-economic conditions, wouldn't it be wise to deliver software value early and often. With its proven models of incremental development, that's what agile promises.
We've must be persistent and rigorous in managing software value creation. For every new asset we create, there is typically an ongoing investment required to support its operation and maintenance. So if we're not diligent about managing the end of life of our assets, the aggregate maintenance cost will eventually dominate your budget and application development will be consume with keep-the-lights on activities rather than growing and transforming the business.
Comments