Randomness

It seems that nearly everything that we are formally "taught" turns out to be useless. Yet a few of the so-called "useless" things we do turn out to be invaluable - incredibly useful. And without the "useless" things we do, that do indeed turn out to be useless, we would never have found those incredibly useful ones!

I was struck by Nassim Taleb's story in The Black Swan about the inventor of the laser. Far from having eyesight correction, compact disks, fibre optics, data storage or microsurgery in mind when he invented it, he was just satisfying his desire to split light beams. As Taleb observed "We build toys. Some toys change the world."

The moral of the story to me is simple: learn play! Rather than seeing education as the process of acquiring knowledge, we should see it as the first steps in learning to think. The knowledge we acquired may be dangerous, particularly as it displaces the unacquired knowledge that may turn out to be more useful in a particular real-life situation. Where it is useful it can often be acquired when needed, provided our education gave us the means to learn and to inquire.

What is an "overhead" task?

When starting to use xProcess there are a number of terms that may be unfamiliar. What for example is an "overhead" task?

In general terms an overhead task is one which does not directly result in the modification or qualification of a required project deliverable. Under this definition most management activities, meetings, planning and monitoring are overheads, while specifying, designing, coding, documenting and testing are "payload" activities.

In xProcess there are 2 ways of specifying how a task will be scheduled: date-based or effort based.

Date-based tasks are generally more applicable to overheads. They run from a date to a date (the date may be derived from other dates such as project start and end or target dates) and have a specified time (or percentage of available time) to determine the effort required per day. If there are no resources available to carry out the task the start and end date are not changed - they will just consume less time in the schedule.

Effort-based tasks are the more normal type of task in xProcess. They have a specified size and required effort (see this link for the difference between size and effort). Their start and end dates are derived from the effort required and the availability of suitable resources (people who have matching role types and skills).

You don't have to use overhead tasks in your process - for example you could include in your estimates the time that will be required for these other activities. However it is useful to get a view from the time booked to overheads of the efficiency of your process and where improvements might be made.

Nominate xProcess for the Source Forge Community Choice Awards

Source Forge today opened nominations for its Community Choice Awards. Why not nominate xProcess now in any or all of these categories:

• Best New Project
• Best Project
• Best Project for the Enterprise
• Best Tool or Utility for Developers
• Best Commercial Open Source Project
• Most Likely to Change the Way You Do Everything

Vote now - it only takes a click!

Resourcing your Scrum Project

In a previous article I explained how to set up a Scrum project in xProcess and the steps to go through to set up a Scrum project in xProcess:

1. Import the Scrum process into your data source.
2. Create a project (setting the various parameters in the New Project dialog)
3. Add project resources and give people the appropriate Scrum role (e.g. Product Owner, Scrum Master or Team Member)
4. Create the first Sprint
5. Create backlog items
6. Create a Delivery
7. Ensure Team Members update their tasks regularly.

Here I want to look in a bit more detail at adding project resources.

Clicking the Resources icon on the Project Toolbar (see image above) takes you to the resources tab for the project where you can add people to the project and also change their roles. There are 3 roles defined in the Basic Scrum process: Product Owner, Scrum Master and Team Member. Adding in people with these role types is the next step.

The tasks for Product Owner and Scrum Master are defined under "Administration and overheads" in the task hierarchy and they are date-based tasks. This means they run between specific dates (in this case the dates of the project) and are assumed to take a fixed amount or proportion of time each day. You can change these amounts by double-clicking on the task and adjusting the Required Resources. Some teams don't need to track time spent on Product Owner tasks and only wish to record work on stories and technical tasks in Sprints. If so you can can remove this task from the plan and leave the Product Owner out of the resources. It just depends what information you need, or might use later to improve your process.

Once you've defined your resources, here's what the "Available Resources" tab of the project might look like:
You can see the hours available for each person on the project and also the roles. If you need to change availability either at the company level, an individual level or for the project you can do this by opening the Availability tab of the organization or person, or by using the "Manage Project Availability for..." button on the project's "Available Resources" tab.

The Scrum configuration has one other field which uses the resource levels on the project. It's on the "Set up" tab which is found at the bottom of the project window. The field is called "Number in team member role" and it is used to size Sprints correctly when they are first created. You should enter the number of teams members (assuming they are all full time). If some are part-time, or some like the Scrum Master working on other tasks as well, remember to allow for the "Overheads level", which by default is 80%.

The next task then is to define Sprints. More later...

Using the Workflow Server

A number of people have enquired about the xProcess Workflow Server recently and whether they can download it from SourceForge and run it. Though you can download and build the source code (see instructions on the Wiki to find out how to do this - and which projects here), we’ve not included the Workflow Server in the pre-built packages for download. Instead we are supplying it as part of a support package for clients in order to ensure that we can put all the components in place for any specific implementation of workflow.

The xProcess Workflow Server runs on Tomcat and is designed to respond to events that occur within the xProcess Data Source (detected by the DataSourceMonitor) or in external systems (detected by custom Monitors). Typical uses for the Workflow Server are

• to integrate with other systems, such as bug tracking systems, that are running in your environment
• to notify users by email of changes to plans or processes
• to update external systems with changes that have occurred in xProcess.

There are some useful blog articles (referenced below) that help understand more about the Workflow Server:

• Developing your own workflow monitor
• Discussion of a typical tracking system integration
• Example State-transition-diagram (STD)

The last article in the list discusses the use of the in-built STD for definition the actions triggered by internal changes (e.g. sending notifications when the state of tasks, targets or resources change). Only this mechanism allows workflow mechanisms to be changed without writing Java code. However even this mechanism requires a significant amount of set up, for example to include email servers and to define OGNL actions, which are triggered on state changes. This is why it is best to download the source code itself if you want to really unleash the full potential of this feature of xProcess. You can build the Workflow Server directly, set up email servers and other configurations, and integrate with your own code for external system monitors.

Also included in the source code are a number of examples of workflow usage, including and integration with the “Flyspray” bug tracking system. When running, this automatically creates tasks to correspond with confirmed bugs in Flyspray, and also updates the status of the issues when the xProcess tasks are closed for example.

Open Source Announcement for OpenXprocess

This press release is hot off the press. You read it here first!

Date: 1st May, 2009
Location: SOUTHAMPTON, UK.

Ivis Technologies and xProcess Europe announced today that xProcess will now be available under an open source license, expanding its already substantial user base to a much wider community.

Also announced today was the setting up of a new company, OpenXprocess Ltd, to own, manage and support xProcess and supply training mentoring and maintenance services to users worldwide.

xProcess allows users to define project management processes (for example task patterns, artifacts, gateways and workflows) and then run live projects while monitoring targets, deliveries and process compliance. Agile methods for software development such as Scrum, FDD and variants of Unified Process are particularly well supported by the technology, which provides priority-driven ordering of activities and resource balancing. The free download of the product includes pre-configured processes for Scrum and other methods. Read more…