This is an interesting and thoughtful post. The term “business value” is often used in discussions of agile processes, but it can be hard to pin down what it really means.
AGILE IN ACTION: Agile2008: Converting business value into actual money
More research on that old chestnut about everyone being connected, this time based on data-mining of MSN instant messenger records.
Instant-Messagers Really Are About Six Degrees from Kevin Bacon – washingtonpost.com
A cute story about problem solving and lateral thinking beating big-budget programs, but without any sources cited it can only be assumed to be a mde-up parable.
I’ve certainly seen this in action. Confusion between the idea of a team, and the practice of a bunch of people “working together”. They are quite different things.
This is something I’m sure I need to read up on. Cost/earnings models in small businesses, particularly in venture-capital-funded startups, can be complex and easy to lose sight of the real issues. Does “Throughput Accounting” provide a different view on all this – one which might make any decisions clearer?
One strand of my continuing research is about the design of productised yet customisable web applications. It seems that most corporate web applications are developed as customer-specific projects, which in turn leads both to a very low level of reuse, and to expensive projects with little or no economies of scale.
I’m guessing that one way to cut through this is to build an application in two parts: a core platform providing generic data and services, together with a set of plugins, themes/skins and widgets. Several very successful web applications (such as the WordPress blog I am using to write this) use this model.
- Creating flexible user applications using widget technologies
I always kind of wondered how this was done. Nice to find an article with a simple way to do it.
In my experience of doing software development for non-developers, risk is one of the most difficult things to deal with. It’s so easy and tempting for customers to think and plan in terms of the definite “I will have feature X by date Y”, that the risk of X not being available by Y gets quietly ignored. Any such failures come as a complete surprise, even when the details of feature X were not even known at the time an estimate was made.
Several development project management methodologies try to cope with this, and Scrum is probably the most well known. Here’s an InfoQ article about risk and scrum.
For years Frank Carver has been paying attention to the strange world of convergent technology. During that time he has discussed and researched broad subject areas, come to some surprising conclusions, produced and distributed digital media, scattered ideas and opinions like sparks from a firework, and above all consulted for businesses both large and small to help develop and deploy successful systems, services, and products in this highly complex arena.
