Kallokain

Many companies use a standard response in troubled times, they appoint a new CEO. The new CEO takes measures. If the CEO is a former sales person, he focuses on improving sales. If the CEO is a former accountant, there will be a savings program. A CEO with a technical background will focus on developing new products. The outcome is usually one of the following: The company takes a nosedive, crashes and burns. Nothing happens. The gradual decline continues. Eventually yet another CEO is appointed. There is improvement. Sometimes the improvement is radical. after awhile, the rate of improvement abates. Then the company begins to backslide. Eventually another CEO is appointed. There is a sustained improvement in the company's financial health. This is rare though. The third alternative, initial success followed by backsliding, is in many ways the most interesting outcome. First of all it is a common outcome. Second, it often seems inexplicable. The CEO proved his management genius

This is part 2 in a series of articles. You can read the first part if you click here . In the previous article in this series, I discussed how to measure and visualize the Throughput part of the Return On Investment (ROI) equation. This time I'll focus on Inventory (I). As you may recall, Inventory is defined as "money tied up in the system". Inventory includes all the equipment you use in a development project, computers, software, chairs, tables, etc. In a manufacturing process, Inventory would also include the partially finished material being worked on in the process itself, the Work-In-Progress, or WIP. In a software development process there is no WIP, but there is an analog: partially finished software. This includes requirements, design specifications, and any code that is not fully finished, tested, and ready for release. Partially finished software is sometimes called Design-In-Progress, or DIP. The DIP has a monetary value. The value of the DIP is the amount o

Clash 1: Goals Traditional development methods set three goals: Keep within budget Implement all requirements (often specified before the project starts) Make the deadline Agile projects set the following goal: Maximize the Return On Investment (ROI) To maximize the ROI, an agile project changes the following variables: Cost Scope Time In other words, what traditional software development, and most companies, set as fixed goals, are just the things an agile project need to change to reach its goal. Clash 2: Push vs. Pull Another major difference is that most companies, and traditional development methods, are based on push systems, while agile is based on pull systems. : In a push system , each step in a production line does what the previous step tells it to do. In a pull system , each step in a production line does what the following step has to do. The situation when orders start travelling from both ends of the command chain can at best be described as chaotic. Clash 3: Cost Effi

As you may have noticed www.henrikmartensson.org has been down for some time. The site went down because some of the software broke when the host system was upgraded. Before putting the system up again, I will fix some broken links and other problems. My schedule is rather full these days, mostly with the joys of fatherhood, but also with a major writing project, and a few other things, so getting the site going again will take some time. I will spend time blogging again though. The past few months have been incredibly hectic, but the past few weeks my life has settled down to a somewhat saner pace. Besides, my writing addiction is stronger than ever.

Statistics may not be what floats your boat, but statistics can tell some important things about software development projects. In this article, I'll show how even a very simple analysis of some basic project measurements can be exceedingly useful. The data in the following analysis is fake, but the situations they describe are from real projects. A commercial software development project is a system that turns requirements into money. Therefore it makes sense to use economic measures, at least for a birds eye view of a project. If you have read my earlier postings, you will be familiar with the basic equation describing the state of a business system, the Return On Investment (ROI) equation: ROI = (T - OE) / I T = Throughput, the rate at which the project generates money. Because it is hard to put a monetary value on each unit of client valued functionality, this is commonly measured in Story Points, Function Points, or Feature Descriptions instead. I'll use Story Points, beca