Don't burn out... Burn Down!

Following in the tradition of you heard it here first, here's another sneak preview of soon to be released functionality on xProcess. The burndown chart is a key visualisation that was developed in Scrum and now used with a number of agile methods. Currently you can use the reporting feature in xProcess to generate a burndown chart for your project or timebox. However there's a new feature in the wings that shows you the burndown instantly (history and forecast) on any project, parent task or folder. Here's an example:


This timebox (Timebox 01) runs for about 3 weeks and the scope of work targeted is forecast to complete right at the end of the timebox -- indeed a couple of the tasks are alread critical. (This diagram is looking forward, predicting when tasks will close, and thus when the work in each task will burn down). Look at the same time box a couple of days later.

Now -- perhaps because tasks have been re-estimated or resources changed -- we can see some tasks are forecast to finish beyound the end of the timebox. The chart is consequently shown as "red" status. Even at this early stage in the timebox we can predict that some deliverables are at risk and so take appropriate action. In this case some additional resources have been found and the some tasks excluded from the targets. Once the changes have been made, the effect can be seen and assessed immediately...

The timebox is "green" and all systems are go! Day by day as the timebox progresses we can monitor our progress and ensure the whole team stays on track!

When we visit the team half way through the timebox we can see from the burn down chart that they are still very much on track and confidence will be high that this team will deliver on its promises.

New project Pattern for FDD

The project pattern for the Basic FDD process, which is delivered with xProcess is changing in version 2.7.2. Here's a preview.


This puts the emphasis back on the familiar 5 stages of FDD at the top level (Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature and Design by Feature). The first 3 stages are included in Timebox 00 which covers the start up period of the project and Features and Feature Sets are created as subtasks of combined final stages: Design by Feature - Design by Feature. Major Feature Sets are modeled as Folders with membership defined by Category.

3 Types of Requirement

Priority-driven processes only work if you can model the process around task patterns for a single requirement. There is little point in prioritizing say, coding over testing, or design over specification, since all these activities must take place at some stage, even if they happen inside an activity that is called something else. But are all requirements the same (in the sense of using the same processes) or are some requirements more the same than others?!

Recently I was asked to advise on the requirements capture process for an organization wanting to apply agile techniques in a controlled environment. I came up with some slightly different names for types of requirement, though I think the concepts will be familiar to you if you've analyzed other software development methods. The requirements types (shortened to PCF) are as follows:

• Business problem statements (Problems)
• Solution contraint statements (Constraints)
• Solution feature statements (Features)

I've written elsewhere about FDD, which provides a very good process for managing and prioritizing features. However often projects applying processes like FDD do not pay enough attention to the other types of requirement that precede features.

Problems, for example, should identify issues in terms of a measurable aspect of the current solution and the degree to which a performance improvement would overcome it. Constraints express aspects of the solution that the current designers are not expected to change (though they should also state the rationale behind the constraint, and how and by whom it may be changed if justification exists). Only by considering all of these three types of requirement can the essential requirements of a system be captured.

Action stations

One of the most powerful aspects of xProcess is its flexibility and configurability. Processes are defined in terms of patterns: for example project patterns, task patterns and artifact patterns. Configurable enough. However you can do much more to enhance these and make them easier to use, by using xProcess Actions. These are bits of "OGNL" code that do things when xProcess is working. They can be triggered by user actions, by instantiating a pattern, by workflow or a number of other events.

For example Sam DerKazaryan of Isobar Global asked me recently for an Instantiation Action to increment the issue number on newly created issues. For those of you who like a spot of programming with their process engineering, here's the code snippet that does it...

#root = getPersistenceHelper().getRootExchangeElementContainer(),
#counter = #root.getIntProperty("currentCounterValue"),
#counter = #counter + 1,
setName("Issue " + #counter),
#root.setIntProperty("currentCounterValue", #counter)

Note: you need version 2.7.2 of xProcess or later to run this code.

Finalist for Eclipse Community Awards 2007

Just received great news - xProcess has been shortlisted (1 of 2) for the prestigious Eclipse Technology Awards in the category Best Commercial RCP Application. The two Technology Awards aim to recognize the best Eclipse-based commercial and open source products in the world.

"Finalists were selected from a pool of 63 nominations by a panel of judges from the Eclipse community". Way to go!

New white paper on priority-driven processes

Are your teams working on the most important issues to your business? If not you are losing potential earned value every day that goes by!

I've just finished a paper on this topic called Priority-Driven Processes, which you can download from the Ivis website. Such processes use the priority of deliverables as a key management control, enabling teams to focus on what provides greatest payback soonest. The paper is designed to help people to model and implement processes with priority, and draws on examples from FDD, XP and other agile methods.

If you do download, be sure to send us your feedback!

Do What You Do, But Better...

A recent discussion with Dave Garrett of Gantthead on the essentials of process improvement provoked some very interesting questions and answers. Please check it out on his blog under this title: Do What You Do, But Better...