Cycle time and cashflow

Cycle time*, by which I mean the time to market for a feature, is not merely an academic concern. In times like these it may involve your job security, your project's viability and your company's future.

Clarke Ching amusingly points this out in his latest biztech parable "Rocks into Gold" with a tale of a back-from-the-brink project that found a simple way to justify its existence and solve the cashflow problem. It a quick read that's well worth the effort.

Graph's like the one above also bring home the message that even a small reduction in cycle time - specifically the time to external release of new features of a product - can result in major improvements in economic performance measured by return on investment (ROI), time to pay back, and profitability.

Agile processes - influenced for example by Goldratt's Theory of Constraints (TOC) - stress the need for rapid turn around and frequent releases, and the key drivers for this are the financial benefits from early release. The inhibitors to frequent and early release of new features are usually lack of automated testing and incomplete continuous integration. Using the financial arguments, particularly improving ROI, is the best way to justify and assess investment in this area. Automating acceptance tests in particular involves considerable effort and expense, but if it results in reduced cycle times and improved quality the financial justification is clear.

*Note: Unfortunately cycle time is an overloaded term that means different things to different people. I now trying to use a different term whenever I can. See "In search of unambiguous terminology for Flow systems" for further discussion of this issue.

Driven by priority - practical tips

Agile processes are designed to support changing activities when the business environment changes. This after all is the natural understanding of the word agile - the ability to change direction quickly. What this means in practice is the tasks in plans - backlog items in a release say - have to be prioritised and changed when priorities change. This has always been a feature of xProcess, but in the very earliest releases the priorities list was a single list. We soon found when we had up to 1000 stories, features requests and defects to prioritise against each other it was an almost impossible task to get your brain round it all. This led to the current model in the product where groups of tasks can be defined and prioritised relative to one another, and then the groups themselves can be given a "weight" relative to other groups so that the overall priority list can be derived. This allowed us for example to prioritize bugs relative to one another and then decide on the balance between bug-fixing and new features in any given release. It made the whole process much more manageable.

The screen shot below shows a single "Priority Group" being prioritised, either by dragging and dropping tasks or by giving them a priority number.

Recently a user of the xProcess "Basic Scrum" process raised the issue that the relative priorities of user stories get lost if stories are moved from one Sprint to another (for example if they are incomplete at the end of the Sprint). Here's my reply:

xProcess has a very flexible mechanism for defining priorities using "Priority Groups" which allows any Folder or Parent Task which has been "prioritised" to support ordering of tasks within it. Each Priority Group can be given a "weight" so that all the priorities can be combined into the ordered list that the scheduler uses. As with many of the very flexible mechanisms in the product, when you actually tailor the product for a given process (Basic Scrum in this case), you have to make some decisions about the normal way to use the features.

Basic Scrum defines Sprints as prioritised Parent Tasks with diminishing weight (later Sprints therefore have lower weight and are scheduled after the earlier ones). As you've observed when you move a task from one Sprint to the next the priorities they had in the previous Sprint gets lost. So if this is a normal part of your process - I can understand why it could be - why not define another prioritised group (say a Folder called Release Backlog) where you can give your stories a longer lasting relative priority. The weight for this group does not need to be high because it will just be the "tie-breaker" when stories have the same priority in Sprint. I think this should achieve what your aiming for.

There are many different way to use Priority Groups, some of which have been incorporated into the standard processes released with xProcess. For example the Simple Process has the facility to add "High", "Medium" and "Low" categories to the project so that just by categorising tasks they get prioritised appropriately.

Accessing xProcess via Web Services

Wouldn't it be great if you could build your own web interfaces which integrate project process and scheduling information from the xProcess model?

We thought so too. That's why we've started an inititative in the open source project to provide access to xProcess via Web Services. This will be a different server to the current xProcess web server (see screen shot) which uses Tapestry and has facilities for supporting participants on xProcess projects (booking hours to tasks, closing tasks with gateways, access artifacts and assigning tasks). There will be a considerable amount of common code however as the authentication, integration with Subversion, scheduling and multi-threading will all follow the same design. However the web services interface is intended to give full flexible access to the complete underlying data model of xProcess. The first services being defined allow you to access and update project data, but the mechanisms of data exchange and update are generic so almost anything is possible!

If you think this project might be of interest to your needs, or if you're interested in participating in it, please contact us. Your input will be most welcome. There are further details on the Wiki about how to use the source code once downloaded: http://sourceforge.net/apps/mediawiki/xprocess/index.php?title=WebServices

Precision and accuracy in estimating

The difference between precision and accuracy has always been important to engineers and it is vital to understand too in the context of estimating for software projects. One approach to estimating a project is to create a detailed work breakdown structure and estimate each task, say in person-hours. A friend told me recently she had consulted on a project which had estimated its size as 135,213 person-hours! The precision in this case is 6 significant figures. As to the accuracy however, previous projects had errors or between 10 and 200%. The precision actually gets in the way of understanding the estimate, particularly as crucial business decisions involving significant proportions of a company's revenue may be based on such numbers. While three-point estimating (3pe) provides one way of capturing risk estimates along with the estimate themselves, the main contribution of agile methods in this area is the tight feedback loop from measured velocity timebox by timebox. Check out some of the links below to see how xProcess supports these concepts.

Naked Objects

I recently received and re-read Dan Haywood's excellent "Domain-Driven Design Using Naked Objects" (I'd read a review copy some months ago). It's definitely worth the effort and I'm hoping to get some of the exercises done too as this means I can get up to speed with where the Naked Objects framework currently is these days.One of the first pieces of prototyping we did with xProcess (back in 2003) was to create a domain model (using TogetherSoft's "Together") and then connect it to Naked Objects so we could dynamically interact with those early models of Project, Task and Person. Naked Object effectively animates a domain model so you have an instant user interface to manipulate the domain objects. I believe the approach helped us then and I would certainly recommend projects consider doing the same - particularly in early stages of a project - as getting good domain models early pays off many times over at the end of the day.