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.

Rescheduling tasks to the date you want

I was asked by someone recently to help them get their task to be scheduled on the date they wanted. One thing xProcess doesn't give you (except for overhead tasks whose size is defined by their duration rather than the estimated effort) is the ability to state when a task should start and stop. This is what the auto-scheduler does, based on your estimates, constraints (e.g. dependencies on other tasks or specific dates), your priorities and your available resources. So what if you have a task which is not being scheduled when you think it should?

Here's the checklist I gave my colleague:

1. If the task being scheduled too soon you can add a constraint to the task by opening its editor (double-click) and selecting the “Constraints” where you can add the constraint (e.g. a dependency on another task or a “start after < date >” constraint).
   
2. It may be though that the task is being scheduled too late and you want it scheduled sooner. A quick and easy way to achieve this is to make it “active” as then it will be scheduled immediately. (Just right-click on the task and select “Make active”. This can also be done from the web client too and it’s worth checking that the team always make the tasks they are working on active so that they are always scheduled immediately and not postponed when higher priority tasks are defined unless they make them inactive.)
3. If it’s not currently being worked on (so not “active”), but you want it scheduled earlier (for example as soon as current active tasks are complete) then increase it's priority. Here's how:

If the task is not in the current sprint (assuming you're using the Scrum process) it will be scheduled after this sprint, so drag it into the current sprint from its current location

If it is in the current sprint but still not being scheduled soon enough, use the “Priorities” button on the tool bar, which takes you to the “priority groups” tab for the project. Maximize the window so you can see it all and select the current sprint. In the lower list you can see the relative priorities of all the tasks in the sprint. Change them so your task is near the top.


Check in the first tab of this window “All tasks in Schedule Order” that your task is high enough. (You will see for example all the active tasks near the top of this list.)

Finally one more thing to check. Make sure the task doesn't have constraints on it's start or end, for example a dependency on another task that won't complete for some time. This will also cause it to be scheduled later.