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!

What's in a process?

This is an interesting question - particularly when you're involved in building tools to support them!

In fact the processes behind most projects boil down to

• what is to be done (tasks, activities, actions),
• what it is done with (resources, artifacts, tools) and
• what it is done for or to (products, artifacts and changed status).

Processes can be modularized and if you want to support priority-driven planning - an essential benefit provided by xProcess - you need to build modules of your process - task patterns - around single units of stake-holder benefit (that is around single requirements).

A process need not just address task planning but also aspects such as

• quality control,
• artifact management and templates (e.g. for requirements, issues, design and user documentation),
  
• workflow (for notification of team participants and for integration with other tools in the environment such as accounting and tracker packages) and
  
• human resources concerns such as the definitions of role and skill types.
  

As organizations grow the libraries of processes behind their projects they can share best practices, evaluate the effectiveness of process changes and optimize their standard approaches to a wide variety of project types. In the mean time, all the projects applying the processes are able to dynamically report status changes, target changes and scope changes achieving both improved agility, and demonstrable compliance and auditability.

If you're defining a process in xProcess here's a list of elements you should be considering:

• Project patterns - what's the essential structure of projects
• Task patterns - are their different patterns for things like features, defects , releases
• Folder patterns - what are the groupings of activities you want to support for planning and prioritising
• Artifact types - what documents and other artifacts are produced and to what template
• Role types - what roles do people play
• Gateway types - are there tasks that need a auditable quality checks applied?
• Category types - how are tasks and other elements categorised?
• Expense types - any expenses to build into the process?
• Actions - are they actions you want triggered by users or events?

'Killing development projects early and often...'

Esther Schindler's recent post what Gartner is telling your boss makes for interesting reading.

Gartner urges managers to consider better process control and governance, managing 'application portfolios' much as they do stock portfolios. Part of this discipline is 'killing development projects early and often'. While no doubt some managers will want to respond to this by applying for the "Ghegis Khan training course for mangers" what it really means is that managers need much better information than many currently have about the status and delivered benefits of their projects.

Now where might they begin to get that kind of information from? Not only does it need to be part of the process of managing a portfoio of projects, the information needs to immediately accessible through the process support environment.

Exactly.

Who needs what?

One of the key ideas in xProcess is that it puts planning and process control in everyone’s hands - at the level they need it. For example...

Project Participants can:

• see their tasks and priorities (potentially across multiple projects)
• update estimates and progress
• update their availability and overhead activities
• update their active tasks and close their tasks when complete
• see changes to priorities and target dates

Project Managers and Planners can:

• create project tasks and prioritize them
• change available resources for the project and assign them to roles or tasks
• set the scope and target dates for timeboxes and releases
• see immediately if tasks are forecast to miss targets and why
• view burndown or Gantt charts of the whole project or timeboxes
• select and/or customize the processes their projects use

Project Executives and Stakeholders can:

• overview the goals and progress of multiple projects
• monitor and improve the processes adopted by projects
• compare and contrast processes if they are different
• examine “what-if” scenarios by varying resource deployment
• redeploy resources between projects
• monitor financials spend and earned value of projects
• generate different format reports for projects and resources.

Process Improvement Managers can:

• monitor and compare the progress of projects applying different processes
• capture process improvement strategies from different projects
• define and improve company standard processes
• monitor process and quality compliance.

The new UI in version 2.5 will reflect the different emphasis required by different roles with tailored perspectives for Project Managers, Project Participants and Process Definers. Expect this to be developed further in future releases.