From tracking to planning ... and back

xProcess provides many of the facilities of an issue tracking tool alongside its project planning/execution and process improvement functionality. Particularly with the new web client access, it's quite possible to use xProcess as your issue tracking server as well as your project execution environment. However many projects and organisation already have issue tracking systems in place and would like to integrate the two systems, allowing issues to transform into tasks in project plans - when they have been classified in the tracker system - and the status of issues to change when progress is reported by the project.

The mechanism xProcess provides for implementing such integrations is the Workflow Server. This can monitor the tracker system as well as changes within the xProcess data source and trigger actions when specific changes are detected. How does this work out in practice? Here's a brief summary of a current integration with a leading tracking tool.

• The tracker is used to create, modify and review issues
• xProcess is used for planning and executing the confirmed issues
• When issues are confirmed, work is planned by instantiating the correspondingpattern (say for a bug-fix) in the appropriate xProcess project. It is the user setting the status to “confirmed” that triggers the transfer into the plan.
• Updates made to the data in the tracker may cause an alert or update in xProcess and vice versa.
• When sub-tasks close in xProcess, the plan status in tracker is updated by the Workflow Server. For example states like: Specified, Code complete, and Accepted correspond to particular subtasks being completed and closed in the project.
• If an issue is deleted or closed in the tracker, data is transferred to xProcess and may cause an alert to the project manager or other flags to be set in the data.
• Viewing the task in xProcess allows data from the tracker screens to be viewed (and updated) directly. Reverse links also possible.
• The issue in tracker and its corresponding task or tasks in xProcess are independent objects but with linked lifecycles that are controlled and synchronized through the Workflow Server.

Much of this integration is independent of the particular tool you are using for tracking, so you may find providing your tracker integration can build directly on this work.

Comparing big patterns and small ones

When defining your processes in xProcess you need to decide on the level of granularity at which to define task patterns and the degree of complexity to build in. Compare these two examples of feature pattern.

This first one is nice and simple. Two people will work on the feature using and/or modifying the three associated artifacts (Word documents in this case) Specification, Design and Test Spec. It's simplicity is its greatest advantage since this allows a lot of flexibility when such features are planned in a real project.

The next pattern is more complex and goes to a finer level of granularity. It defines 5 subtasks, using 4 specific role types and having different artifacts for each of the tasks. The artifacts are a mix of Word documents Wiki pages and xProcess Forms (user-defined data held in internal XML format). The result is a more complex patterns which breaks down the work into more speciifc packages and provides more guidance in terms of the work to be done.

There are dependencies defined on this pattern and there is also a gateway ("Feature complete") which defines the QA requirements for its completion.

This more detailed view of the same pattern shows the allocation of tasks to role types and the specifics of the artifacts.

Which of these two patterns is most appropriate for your projects? I can only recommend you try them and see... and most importantly let me know what you find!

What makes processes agile?

The key thing that makes processes agile is "reduction of work in progress". Traditionally, projects' processes view and partition the whole project: for example software development processes that divide the life-cycle into phases like Requirements, High-level Design, Detailed Design, Code and Build, Integration and Testing, Maintenance. Each phase of the project transforms the whole output from the previous phase into the relevant output products for that phase. You could represent such a lifecycle in this way, where each step, T, takes the artifacts, A, from the previous step and delivers them to the next step.


The major problem with this model is that every step must be completed for every part of the project before any delivery (the so-called "big-bang" delivery). There's a lot of work in progress in this model, and that means a lot of risk and a high level of required investment.

In contrast, an agile lifecycle defines the necessary transformations in the process, not for the whole project, but for a single requirement (“features” in FDD, “user stories” in XP, or “use cases” in UP). The release cycle, which is built around the process for delivering single requirements, ensures that benefits can be delivered sooner and in priority order. Should requirements change it no longer involves the loss of such significant amounts of work. At each release there is much less work in progress and value is delivered continually, rather in the single - and very risky - big-bang.

New diagram in xProcess

A recent development in xProcess is the support for State Transition Diagrams to define the workflow that is triggered by changes to elements of xProcess data. The diagram attached to this entry is a sneak preview.

You can define states of the elements you are interested in (Tasks, Projects, Peoiple, etc.) by defining a rule in OGNL. When these objects change from one of the pre-defined states to another the Workflow Server will inspect the defined triggers and call the actions defined therein.

More later!