Software Value Creation

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 it’s 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

Post a Comment

Popular posts from this blog

Be agile about agile!

The democrats and republicans are doing a fine job of "fire-bombing" the centrists in both their parties (I grabbed that quote from an article "It's not easy being George" in this month’s Vanity Fair). And, as I scan the agile groups and blogosphere, it seems the methodologists are doing it as well. Some of us take the "extreme" in extreme programming too literally, and others are holding on to some of agile developments long disproved stigma for far too long. My approach always has been (and hopefully always will be, unless of course I turn out like my father, which all of us eventually do...) a pragmatic one. There are many things I love about Scrum and agile - driving elaboration and development off the backlog, test-driven development, burndown charts, and much more. And there are a some that I could do without (self-organizing teams, developers and testers are interchangeable, ... I blog on these later). An agile approach needs to be tailored to y...
Read more

When Do You Need Agile Product Portfolio Management?

Image
First, let’s define Agile Product Portfolio Management. Agile Product Portfolio Management is a dynamic approach to managing a company's suite of products. It involves continuously evaluating and prioritizing products based on shifting market demands, customer feedback, and business goals. It integrates principles of Agile methodology - such as flexibility, rapid iteration, and cross-functional collaboration - into portfolio management. The focus is on adapting quickly to changes, making swift decisions based on current data, and ensuring that resources are allocated efficiently to maximize product success and overall business value. It's about maintaining a balance between long-term strategic vision and short-term market realities, ensuring the product portfolio remains relevant and competitive.  Agile Portfolio Management is needed when your business and product line achieve a size, complexity, and maturity where decisions can no longer be locally optimized for individual pro...
Read more