Wednesday, August 06, 2008
There is no silver bullet for achieving economies of scale in the development or the integration of software. As difficult as it may seem to predict the costs of development, the true way to realize on that goal is to deliver often. The frequency of delivering a product is the key to eliminating most of the risk we typically associate with projects that deliver software products to market.
A regular and predictable product deliverable [I'd recommend every 2 weeks or 4 weeks] is critical to creating business value. In the software development business, so much focus is on cost measurement and this distracts from the real objective of creating value. There is an adage that a cynic knows the cost of everything and the value of nothing. Measuring costs isn't nearly as critical as measuring value.
If our customers can regularly, and predictably, see and touch the results of their investment, then we’ll generally know in an instant how well we've done. And if we are off the mark, we know where we stand and what we need to do satisfy our customer. Like President Eisenhower said, "Preparing for a battle, plans are useless: planning is indispensable."
The traditional, or waterfall, development paradigm typically measures results based on progress to plan. While it is helpful for business customers to know what their costs are at a point in time, I don't know anyone who wouldn't want to see, touch and test the deliverables for themselves. Value becomes a tangible thing once the customer can see for themselves the results of their investment.
Feedback drives planning and incremental development closes the gap between what developers think the customer wants and what they really mean. It is very important to create as many working prototypes as necessary to narrow the difference between expressed needs and confirmed needs.
Article written by: Joseph Butson, Project Manager
I've seen the good and the bad of this model. The bad comes when the goals for each development iteration are planned out way in advance and/or by people that are not directly related to development.
If the iteration goals are planned so far in advance then there is no room to move when the inevitable setback comes along. There is also no room to move ahead when the developer thinks they can get MORE done in an iteration than was scheduled. Ideally, management, development and the testing staff need to reach an agreement for every iteration. Once on that kind of schedule, it only takes a few minutes and you'll find that the process much smoother because you'll have buy-in from all the participants.
Posted by Doug Halsted on Tuesday, August 05, 2008
Reply to this Comment »
One cost that is rarely addressed is the opportunity cost incurred by not delivering a solution. The longer we delay improvements, the greater the cost of the implementation. If we add value quickly and incrementally, we greatly reduce the overall opportunity costs incurred by the business. Further, if we deliver the greatest value first, the cost benefit decisions made by the stakeholders will prevent wasted efforts on unproductive features.
Posted by Shane P. Schulte on Wednesday, August 06, 2008
Reply to this Comment »
One of the biggest benefits of the Iterative (RUP) development for my team has been the ability to give demonstrations within our pilot environment and getting direct feedback from our stakeholders early in the process. In the past we would do this close to the time we went into production only to find that once the stakeholders were given a visual presentation of the application they would change their mind or want something added(can you say change management!). Catching this earlier in the process with Iterative development has saved us a lot of time and money, so I agree with your comments! I know we have discussed the concern with the prototypes leading the development instead of the requirements, but wanted to make that clarification!
Posted by Mike on Monday, August 25, 2008
Reply to this Comment »
Nice site, thanks for information!
Posted by YahooBot on Tuesday, November 11, 2008
Reply to this Comment »
Not bad... Not bad.
Posted by HairyMan on Tuesday, November 11, 2008
Reply to this Comment »
Please keep your comments relevant to this blog entry. Email addresses are never displayed, but they are required to confirm your comments.