The Simplest Possible Way to Get a Project Plan?

I want some work done - so make a new project...

Ok. Here are the tasks that need doing (I can enter them as a comma separated list).

My task list forecasts that these tasks are never going to complete. I guess that's because I don't have anyone to work on them. So add myself as a resource to the project.

Good. They're now being scheduled but I don't think the most important things are being done first. I need to prioritise...

That's fine. They're in order and I can create a Timebox to show what will be done in the first two weeks. Let's have a look at the forecast Gantt and Burndown charts...


Seems ok but all the tasks have the default estimate of 2 days. Next job is to estimate those tasks properly. Oh and I also need to add in the other project resources, and when they're going to be available to the project. Once that's done I'll have a plan I can show my manager.

Mmmm... That didn't take too long!

FDD sub-processes in context

Like most agile processes FDD doesn't pretend to cover every aspect of the software development life-cycle. Just the essentials for establishing a common approach. In particular FDD doesn't explicitly state how and when releases of software occur during or following an FDD iteration.

Here's a diagram that attempts to put the releases in context and also shows the distinction between the first 3 sub-processes which define the project (or iteration), and the multiple instances of the 4th and 5th sub-processes which develop the project (iteration). There can be just one release at the end of an FDD iteration or (more normally?) several releases which deploy the developed software.

What's different about Folders?

When you're deciding on the structure of project patterns for a new process, often the first thing to consider is how to represent the different hierarchies of elements that make up projects.

In FDD for example there is the hierarchy of features, normally described as being Features, which are contained in Feature Sets, which are contained in Business Areas or Major Feature Sets. This logical grouping of functionality is independent of priority and time-ordering. It may well correspond to the structure of the user manual for example or the Functional Specification should such a document be required. It doesn't give us any time view. On the other hand the hierarchy from Releases -> containing Timeboxes -> containing Features is a time-based structure. Similarly the hierarchy based on the five subprocesses of FDD also will have a time correspondence: The Definition Stage -> containing FDD#1 Develop Overall Model, FDD#2 Build Feature List, and FDD#3 Plan by Feature; The Build Stage -> containing many instances (for each feature) of FDD#4 Design by Feature and FDD#5 Build by Feature; and the Release/Deployment Stage following completion of a release.

Each of these hierachies is an important view of the tasks and artifacts in the project. However when defining a process in xProcess you must decide which hierarchy will define where a task "lives". This is the parent-child hierarchy of tasks and is analogous to a directory structure which tells you where a file is located. All the other relevant hierachies can be represented with Folders which contain explicit or implicit (defined by rule) references to the tasks. This means that different features may appear in different Timeboxes and Releases, and indeed different subtasks of a feature may appear in different folders (design and build for example may appear in different timeboxes; build and certify a feature may appear in different stages). Since Folders may contain Folders in xProcess as many hierarchies can be provided as are required to understand the process, each to several containment layers if this helps understand the view.

So Folders provide an alternative hierarchy of tasks to the main parent-child structure. Their membership is defined either explicitly (because the process has put them there or the user has dragged them into the Folder) or implicitly (because the task has a matching category to the category of the Folder). In some methods it is sensible to use the parent-child hierarchy for time-based structure (Basic Scrum 3.0.1 follows this scheme for example). In others using a more static structure such as Business Areas/Feature Sets in FDD or a Work Breakdown Structure in traditional methods, gives the preferred structure for parents-children with more dynamic hierachies being represented with Folders.

Description of the xProcess product

xProcess allows projects to define their own processes... and make and monitor plans that conform to those processes.

Projects may start from predefined processes such as those for Scrum, FDD, Iconix, Unified Process or Prince 2, or define their own. Using their process definition, projects can be defined, resources added and tasks defined, estimated and prioritised. xProcess then provides forecasts for the project against which targets can be set.

Once a project is started the participants on the project can access the tasks they have been assigned and record hours worked against tasks, adjust estimates of time to complete, add artifacts (such as documents or links to managed files) and close tasks, including (if the process requires it) completing task "gateways" to show compliance with intermediate steps of the task.

Thus xProcess supports process definition (including several graphical views of the process patterns), project management (including defining and estimating tasks, forecasting, timeboxing, target definition and monitoring, gantt, pert and burndown charts) and project execution.

The main client for accessing xProcess information is an Eclipse RCP application. There is also a web server which provides browser access for project participants. The RCP client has 3 perspectives for: Process Engineers (defining processes); Project Managers (defining and monitoring projects); Participants (reviewing and recoding their work on the project).

xProcess project on Source Forge

With various announcements, activities and releases in the pipeline, you may be interested to know that there is now an xProcess projects on SourceForge. The site is http://xprocess.sourceforge.net and althought as of this moment there are no downloads available there, the forums, announcements, wikis, etc. of the project will all be moving up there soon. Why not post a message there now?!

Calling Software Development Process experts!

Did you know that from January 2009 the xProcess project is going open source?

This means that projects worldwide will be able to download and use free process definition and project management software and, if they are so inclined, configure and improve it for their own use. At the same time we are launching a new services company OpenXprocess. This company will incorporate xProcess Europe (and xProcess US), and manage the ongoing enhancement of the product, while offering services to users of xProcess such as: training in Scrum, FDD, Agile, Iconix Process, Unified Process, Prince and other configured processes of xProcess; configuration of the product to companies’ own development processes; and a support package which includes the web server for access to project data from browsers.

This is where the software process experts come in. Would you be interested in learning about xProcess and potentially offering services to configure processes or consult with clients using existing configurations? The Scrum configuration in xProcess for example provides a number of unique features which are not available in other Scrum tools (task matching, forecasting, three-point estimating, target management, multi-dimensional prioritisation) as well as familiar Scrum tools such as burndown charts (including burndown forecasts), Gantt charts (auto-generated) and backlog management. If you would like to be involved I’d very much like to hear from you.

The process configuration capabilities of xProcess, particularly now it’s an open source product, offer important innovations for the industry, and I’m particularly keen to involve experienced software consultants in this area. In the past process definitions have been of only passing interest to project managers, useful guidance but completely separate from the plans they work on day by day. xProcess changes this relationship since it is now possible to define processes that instantiate directly into project plans and aid conformance with the process (or highlight differences) as plans are implemented.

Project processes are often described with Activity diagrams or similar notations. But these are notoriously difficult to map to the actual activities of a project. With xProcess the process is described in terms of task patterns which, when instantiated within the initial project pattern, show the trackable tasks that are required to complete that part of the process. Where aspects of the process involve activities that are below the level of trackable tasks – for example a development task may involve say, coding, testing, integrating and building – these steps may also be captured in the process definition through xProcess’s Gateways, which are defined in task patterns and are completed as questions and answers on closing a trackable task. And because task patterns may themselves contain task patterns the process definition language gives as much flexibility to define optional, repeating or iterating structures as activity diagrams do, but with the important difference that they map directly into the plan structure that projects implement.

If you’ve read this far I hope that means I’ve at least aroused your curiosity to investigate further. You can download the product from www.ivis.com (soon to be www.openxprocess.com) and I very much hope you’ll do this and encourage colleagues and clients to do likewise. But you might also be interested in getting directly involved. In Q1 2009 I’ll be conducting some training workshops for potential xProcess consultants or process engineers (probably in Denver and London). Please let me know if this might be of interest. The training will last 2 days with the opportunity for a further 3 days collaborative work on a process of your choosing – this can be carried out either immediately following the training event or remotely at your convenience, with access to me via phone, skype or teleconference. Following completion of this we will offer certification as “Certified xProcess Consultant” so that you can offer services to clients directly or through OpenXprocess. OpenXprocess will only use certified personnel for training and consulting services and will support certified consultants in the field to help ensure your success.

If you know of others who may be interested in this, or companies who you feel might want to adopt xProcess, please let me know.

Wishing you all the best for 2009.

Andy Carmichael.

Folders are changing

There's a new spec for Folders in xProcess that should be released shortly in the v3 programme. The new feature let's you define a hierarchy of Folders and it clarifies the difference between folders with "explicit" members (the tasks are in the folder because someone put them there) and "implicit" members (the tasks are there because they fulfil the criteria for the folder - usually that they are in the appropriate category.

Email me or post a comment below if you would like a preview of this spec.