Skip to main content


Showing posts from 2007

The headaches of centralised data

The UK government's woes concerning the potential loss of personal data has received a lot of publicity in recent months. It calls into question the whole strategy adopted by governments to build ever larger centralised databases containing more and more integrated data from multiple applications such as passports, social security, driving licences and health service. An insurmountable security nightmare arises from developing such databases. Just who can you trust absolutely to control access to such universal data sources?

Here's a radical thought - instead of centralising the data and building multiple applications around the same centralised database, why not build applications that can safely access multiple data sources, allowing departmental control of the more localised data sources with full version control and audit of all data access. Interestingly when we built xProcess, the data architecture we adopted lends itself to just such an approach. We've since named …

Document-driven processes

Many processes are driven by documents. Documents are the resulting artifacts from tasks of the process, as well as being the inputs or informing artifacts for subsequent tasks. Examples of such processes range from drug administration, planning applications, legal processes of many kinds and financial control. Since many of these processes are also subject to regulatory control and audits it makes sense to define and monitor them within an environment like xProcess, which not only provides feedback on the forecasts and targets for task completion, but also can handle the version control of the document templates, and the documents themselves.

Modelling these processes requires understanding of what the key documents are, their format (which can be captured as document templates) and the transformation work which takes place through the process (which can be captured as task patterns). The quality control to be executed at each stage can be captured as gateways.

Here's a simple exa…

Midway through Sprint 01

Time to revisit our example Scrum Project started a couple of weeks back. How's our team doing? Here's the burndown as it was 2 weeks ago.

When we left it, the Sprint was red indicating an overcommitment based on current estimates. Either the team would need to negotiate a slight reduction in scope for the Sprint or risk disappointing the project stakeholders at the end of the period.

Here's the situation today (click for an enlarged view).

The status of the Sprint is now amber. Comparing the charts carefully one can tell from the reduced size of the work that there is a reduction in scope (also visible from the task lists) but there is good progress visible from the closed tasks to date. Other things to note in the screenshot are:
Alerts (showing where some open tasks have exceeded their "best-case" estimates - they are prompts that the 3-point estimates for these tasks may need review);
Closed tasks in the Explorer view (show with check mark); and
The task list for t…

Participating in the project

The key thing about defining processes and project in xProcess is that the participants on a project can interact with the plans day by day, making them not just a view of what someone once hoped might happen, but an up to date record of the most likely outcome given progress so far.

The easiest way for project members to update their estimates, progress and plans is to use the web client of xProcess. By installing the xProcess server, this becomes accessible to team members using just a browser. They log in using their Subversion password and can then see their task assignments and update time bookings, which tasks are active, task estimates and descriptions, and other aspects of the plan relevant to their work. Here's a typical screen shot taken from our Scrum Project example (click on the image to enlarge).

Different filters can be used to show either just tasks scheduled for this week or all tasks assigned to the participant. Clicking on a task bring the task details in to the l…

Adding structure, artifacts and gateways to task patterns

Task patterns can be very simple (just one task with no extras) or a quite complex template controlled by several parameters and providing the implementer of the task with template documents, quality checklists (gateways), variable estimates and a family of subtasks. It's important to note that often simplest is best! Or at least (following Einstein) "as simple as possible but no simpler". We already discussed this issue in the blog with regards patterns for FDD (see Comparing big patterns and small ones). In Scrum, we've shown that different patterns can be used in addition to or instead of the Backlog Item pattern (see previous posting). Now let's look at what additional features might be useful to add to our Enhancement and Defect patterns.

Depending on the size of Scrum team you may have specialist roles that go beyond those of
Product Owner ScrumMaster Team MemberFor example the specialist role of Tester is useful on nearly all but very small projects. Develop…

Different patterns for Backlog Items

If you've followed through the series of articles on Scrum (see Using the pre-defined Scrum Process) you'll know they've covered making a Scrum project in xProcess and setting up a backlog of tasks that you can prioritise, forecast and display in Burndown or other charts. Participants on the project can access their tasks in the plan and update progress or modify estimates to complete them. But the pre-defined "Basic Scrum" process is just that - basic. It doesn't take into account the type of project you are doing with Scrum (it may not even be a software development project), nor the specifics of your company's or your team's process. With a little process engineering we can make things much more specific, and sometimes that's very useful.

The types of things you might want to consider once you're up and running with the basic process include:
Adding different role types if there are areas of specialisation within the team
Adding artifact temp…

Agile 42 at the Scrum Gathering

It was great to get together last week with old friends and colleagues Alex Aptus and Andrea Tomasini, who were over in London for the Scrum Gathering 2007. They are both doing Scrum consulting and training in Germany. Andrea's company is called Agile42 and if you think about it the name has some logic to it - "agile" is the undisputed answer to all the major questions of software engineering (mmm...?) in the same way that 42 is the answer to that only slightly larger chestnut: life, the universe and everything. Actually I'd recommend Alex and Andrea's work precisely because they understand that the answers to large questions are not trite or formulaic. If you manage to engage them for your project you'll not only get excellent training in standard methods but thoughtful and experienced consultants that will help you solve the hard questions too.

Another highlight of our meeting was seeing the newly opened St Pancras station on the day that the first Eurostar …

Top-down or bottom up planning for Sprints

xProcess supports two ways to specify the required resources for a parent task: top-down or bottom-up.
The simpler approach is bottom-up. A parent task has subtasks with their own estimates of size and effort. The parent task size is therefore just the sum of subtasks' sizes.

What if you don't yet know what all the subtasks are? In this case - or if you want to specify some contingency or slack without inflating the estimates for the subtasks (Parkinson's Law would suggest this is a good idea) - then you can supply an independent estimate for the parent task by specifying it as top-down.A previous entry, Parent Tasks and Top-down Planning, has already discussed this feature and shows the user-interface for using top-down estimates. The question here (since this is part of the series on Using the pre-defined Scrum Process) is how to use it for Sprints in Scrum.

Let's take a look at the current state of "Sprint 01" in our example Scrum project. Although this is q…

Prioritising the backlog

The key point about priority-driven planning approaches like Scrum - common in fact to all agile processes - is that the set of tasks undertaken by the team are ordered by priority rather than by a pre-determined procedure. (Priority is usually assessed based on business benefit and risk.) This article focuses on this particular aspect of using Scrum with xProcess and it covers:
Adding backlog items to specific SprintsShowing a Sprint in Burndown and Gantt charts, and finally
Prioritising the backlogHaving created a Scrum project with resources and a set of backlog items (see the previous post in this series) our next step is to prioritise the backlog. Our starting point here is a project which has three Sprints defined and a number of backlog items that have been estimated for approximate size. For simplicity in this example I've created 26 backlog items (with single character names from 'a' to 'z') with sizes of between 1 and 5 "points" (points being nomi…

Using the pre-defined Scrum process

I've recently been asked for more guidance about using the pre-defined Scrum process in version 2.9 of xProcess. It uses some of the new features for process definition (like Composite tasks) and also has "top-down" estimating for projects built-in, which is useful for resource planning and financial reporting. So I'm planning to post a series of blog entries on the process and in this one I'll focus on getting started with this process "out of the box". Here's what it covers:
Creating a Scrum projectAdding resources to the project
Adding Sprints to the project (a Sprint in Scrum is like a "timebox" in other methods)Adding Backlog Items to the project (Backlog Items are the tasks the project must achieve)So step one is to select the Project Manager perspective (the default) and hit the "New" button so we can make a Scrum project. The New project dialog shows the processes that are available for import, so if you've not already …

xProcess Europe

On November 6th Ivis announced that it had demerged its European operation (see Press Release) . The new company is known as xProcess Europeand it's owned by former members of the UK team including Andy Carmichael and Paul Kuzan both seminal thinkers in the evolution of xProcess.
Andy Carmichael: "Paul Kuzan and I are both very pleased to be involved with the on-going evolution of the xProcess product and brand, and we believe xProcess Europe provides a great opportunity, particular for developing the services offering that customers adopting xProcess are often looking for. Providing better support and expertise for companies wanting to improve the processes behind their project and portfolio management will be one of the main focuses of the new company. While our product sales and support work will primarily be targeting the European market, we will continue to offer process improvement services world-wide, wherever the needs exist."xProcess Europe and Ivis Technologies …

The Simple Process... or is it?

The Simple Process in xProcess is the first one you are likely to use. It contains basic patterns for a project, a task a timebox and so on, and it also has some useful actions in there that can be used in your own patterns or even exposed as "User Actions" so they can be called on your projects.

The Simple Process has several elements that you cannot delete as for example xProcess assumes that even if no other Role Types exist (such as Project Manager, Developer, Tester and so on) at the very least the Participant role type will exist. When you define your own process it's likely that you will inherit Simple Process patterns (though you can hide them by defining your own hidden patterns with the same name. So it's definitely worth taking a snoop at all the elements in there. You might even want to cut and paste some bits into your own processes and modify their behaviour.

Latest patterns for Scrum

xProcess 2.8 is being released this week and among the exciting new capabilities are some new sample processes, including updates to the Scrum patterns. Here are some of the highlights.

Firstly the project pattern for the "Basic Scrum" process is now built from composite tasks so that there is a standard structure that is provided for all its projects. The Hierarchy diagram shows the structure, having top-level tasks for: General and Scrum administration overheads (overheads are unplanned or unplannable tasks that take up a proportion of everyone's time); the Sprints (a composite task which contains an iteration of Sprint instances); and the Unscheduled Backlog (a composite which contains a collection of Backlog Items).

You can also see from this diagram the structure of the Sprint and Backlog Item patterns. Sprint is a collection of the Backlog Items to be scheduled over the period, and consists of a single task. The beuty of xProcess of course is that these patterns can…

Latest patterns for FDD

The release of 2.8 this week sees some interesting updates to the FDD patterns. Like the Scrum updates for xProcess, the new FDD process uses "composite tasks" to define the structure of FDD projects, allowing them to be expanded top down as the details of feature sets and features are defined.

This hierarchy diagram shows the structure of the FDD project pattern. For those familiar with the method, the 5 stage process is visible in the top-level tasks:
Develop an Overall ModelBuild a Features ListPlan by Feature and
combined with 5. Design by Feature - Build by Feature. Note that the darker blue nodes are patterns, so these can be further expanded in the hierarchy diagram or viewed in the graphical pattern editor.

Here for example is the hierarchy view of the Feature Set pattern, which groups together a set of related features into a deliverable package which can be scheduled for a particular release. Note that here the "Features" composite task, as well as containing…

Set size to match effort

I explained in another entry that size and effort are distinct metrics for tasks. However it's useful to keep the overhead of estimating two closely related items to an absolute minimum. This is why the patterns in the "Simple Process" uses the user's input of a size metric (in "ideal days") to automatically complete the effort estimates (usually displayed in person-hours or person-days). They can be changed subsequently though and if you want to re-synchronize them at some point - say when you a re baselining a plan - a utility for doing so is useful.

Here's a simple Action that you can define in your process (make it a "UI Action" by setting this field to True).

Action Name: Set size to match effort
Expression: setSize(getEffortIncludingChildren()/480.0)
Applicable to: Task
UI Action: True

Having done this you can expand your task hierarchy in the explorer, select the tasks you wish to set siz…

ITIL We Meet Again

I was talking with Charlie Betz recently about ITIL, the best practices framework for delivery of IT services, and how xProcess might be used to support service delivery applying these practices. xProcess is well suited to "case management" type projects because of its ability to handle relatively small task patterns and create composite patterns of collections, iterations or selections of smaller patterns. With v3 of ITIL taking a more "lifecycle" approach, it brings a greater emphasis on process and stronger motivation to understand and improve underlying process models. That's why I'm particularly interested to find ITIL professionals wanting to model their processes with xProcess.

Any way I've been browsing Charlie's blog which has some interesting observations, and not just on ITIL. This entry highlights some frustrations with ITIL from an SDLC perspective: My first ITIL v3 presentation. It brought a smile to my face at least.

(Apologies to Dian…

xProcess wins in the "Tools and Environments" category of the SD Times 100 Awards

The 5th annual SD Times 100 recognizes the leaders and innovators of the software development industry. The 2007 SD Times 100 was posted on the Web site today, and it names Ivis's xProcess as a winner in the Tools and Environments category. The award citation reads:
xProcess changes those lovely best practices into die-cast working frameworks for your developers. The easiest way to push some sanity into the development process.David Rubinstein, Editor-in-Chief of SD Times, said "The winners of this year's SD Times 100 awards have demonstrated their leadership in shaping the software development industry. We took into account each nominee's products and services, its reputation among development managers, and the new ideas it brought out. These select individuals and organizations are the ones we've identified as helping to move the art of development forward."

The team at Ivis are proud to be a part of this select band creating the new breed of too…

Parent Tasks and Top-Down Planning

A key aspect of agile planning is that you expect the plan to change. That doesn't make it a bad plan, it's just the baseline from which you can judge whether to accept certain changes and what impact can be expected. To help you build flexible plans xProcess supports a very important feature - top-down planning. Parent or composite tasks can have their own effort and size estimates which are independent from the size of their children. Alternatively you can select Bottom-Up planning of the parent task and its size will be defined entirely by its children.The above screenshot is part of a task editor that is defined as a top-down parent task. It displays the size (15 points) and effort estimate (120 hours) but also shows how much of this is already allocated to subtasks and how much remains in the REST of the parent task.

The advantage of this approach is that parent tasks can be defined and estimated before the details of their subtasks have been defined. This works for both p…

Outsourcing for quality

Some people think that outsourcing is about minimizing the costs by moving work to wherever rates happen to be lowest at the time. The costs of distributing software teams can be high however and such a strategy may fail to reduce costs at all, and worst of all it can impact quality and agility.

There are good reasons to distribute teams however - for example to maximize quality by picking the best available expertise.
Ivis found such a partner in SwiftTeams who are based in St Petersburg. Their expertise in graphical editors for development tools is second to none, and the xProcess product has benefited enormously as a result.

How then do you overcome the difficulties of planning and coordinating teams that are geographically distributed? This is one of the key motivations of course for deploying xProcess. It provides the key visibility and communication layer and minimizes the negative impact of having a few thousand miles between the sponsors, planners and specifiers and the implemen…

Have you earned value today?

There are many ways to track progress on projects - see "Don't burn out - burndown" for example. Burndown is particularly useful in agile projects with timeboxes where the targets are set at quite short notice - month by month for example. Earned Value (EV) analysis on the other hand is a great technique for tracking progress against a stable plan (ultra-agile teams go and read that burndown article instead of this one - stable plans are a luxury you rarely see!).

With EV tracking the value of completing tasks is calculated from its originally planned cost. There are some disadvantages of this - not least that the whole method relies on having the well-estimated plan to start from - however its advantage is that efficiency of execution can be measured day by day on the project.There are two relevant measures of efficiency that EV analysis provide: cost efficiency (how much better or worse you are doing than the baseline plan with regards the cost of the tasks you have del…

Great resources for estimating

There are two new books on estimating that I've been finding very useful recently, and one older one. The older one first; and here you understand I'm not referring to Larry Putnam Senior himself! It's his book, co-authored with Ware Myers, "Measures for Excelence: Reliable software on time on budget" that remains a classic, full of helpful advice and packed with actual measures from real projects. I met Larry in 1992 just after his book came out, when I was in Washington with Ed Yourdon presenting some research on software reuse from Japan. He kindly gave me a signed copy and it has been in frequent use since that time, and was a key source for my own book "Better Software Faster" published in 2002. Putnam and Myers' latest book "Five Core Metrics" is another excellent resource which highlights the essentials that all software projects should measure, with practical information about how to do it. In case you're wondering the five are…

Hierachy Diagrams

Hierarchy diagrams in xProcess are a good way to see an overview of a project or of process patterns. The diagram on the left is a project that is following a Prince2 style project - actually using a process defined by the WPM Group, leading project management consultants and a company I've been doing some work with recently.

The Hierachy Diagram is a good way to show Work Breakdown Structures for projects, and they are also useful editor views, where you can expand/collapse regions of the hierarchy and edit tasks via their right-click menu.

One more thing to try with Hierachy Diagrams... turn on the constraints on the diagram via the filter button and (as in this example) you'll see all the dependencies between the various tasks. Very useful for understanding the constraints imposed on the ordering of tasks.

Estimating size and effort - Why are they different?

A common question I get asked about estimating in xProcess (after three-point estimating of course, which is another popular question!) is: "What's the difference between a task's estimate for size and its (three-point) estimate for effort... and why do I need both?".

There are several ways to answer this, but perhaps a starting point is to ask why we think they're the same. If I ask you the size of your swimming pool you're more like to give me an answer in feet or metres that to reply with the number of person days it took to build the pool. (Building swimming pools is an xProcess application by the way - but that's another story!) When we are discussing the planning of a project the first thing to consider is the size (in whatever units are appropriate) of the deliverables of that project. Then we need a function (based on previous experience) to map from size to the estimate of the effort and consumables required to provide those deliverables.

Because t…

Project Challenge! On your bike...

The National Motorcycle Museum in Birmingham was the setting for last week's Project Challenge exhibition. It was the first opprotunity to see the new Executive Dashboard for xProcess in action, as well as to hear yours truly speaking about process modeling as a route to improve project performance. Needless to say the Executive Dashboard was clearly the highlight!

Guy's interest in the dashboard in this photo is not merely a pose for the camera. The show was also the first opportunity for the sales team to see this feature, which was turning a lot of heads (not just ours!). The ability to create additional views of interesting project data "on-the-fly" is a particularly impressive aspect of the facility.

Don't burn out... Burn Down!

Following in the tradition of you heard it here first, here's another sneak preview of soon to be released functionality on xProcess. The burndown chart is a key visualisation that was developed in Scrum and now used with a number of agile methods. Currently you can use the reporting feature in xProcess to generate a burndown chart for your project or timebox. However there's a new feature in the wings that shows you the burndown instantly (history and forecast) on any project, parent task or folder. Here's an example:

This timebox (Timebox 01) runs for about 3 weeks and the scope of work targeted is forecast to complete right at the end of the timebox -- indeed a couple of the tasks are alread critical. (This diagram is looking forward, predicting when tasks will close, and thus when the work in each task will burn down). Look at the same time box a couple of days later.

Now -- perhaps because tasks have been re-estimated or resources changed -- we can see some tasks are f…

New project Pattern for FDD

The project pattern for the Basic FDD process, which is delivered with xProcess is changing in version 2.7.2. Here's a preview.

This puts the emphasis back on the familiar 5 stages of FDD at the top level (Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature and Design by Feature). The first 3 stages are included in Timebox 00 which covers the start up period of the project and Features and Feature Sets are created as subtasks of combined final stages: Design by Feature - Design by Feature. Major Feature Sets are modeled as Folders with membership defined by Category.

3 Types of Requirement

Priority-driven processes only work if you can model the process around task patterns for a single requirement. There is little point in prioritizing say, coding over testing, or design over specification, since all these activities must take place at some stage, even if they happen inside an activity that is called something else. But are all requirements the same (in the sense of using the same processes) or are some requirements more the same than others?!

Recently I was asked to advise on the requirements capture process for an organization wanting to apply agile techniques in a controlled environment. I came up with some slightly different names for types of requirement, though I think the concepts will be familiar to you if you've analyzed other software development methods. The requirements types (shortened to PCF) are as follows:
Business problem statements (Problems)Solution contraint statements (Constraints)Solution feature statements (Features) I've written elsewhe…

Action stations

One of the most powerful aspects of xProcess is its flexibility and configurability. Processes are defined in terms of patterns: for example project patterns, task patterns and artifact patterns. Configurable enough. However you can do much more to enhance these and make them easier to use, by using xProcess Actions. These are bits of "OGNL" code that do things when xProcess is working. They can be triggered by user actions, by instantiating a pattern, by workflow or a number of other events.

For example Sam DerKazaryan of Isobar Global asked me recently for an Instantiation Action to increment the issue number on newly created issues. For those of you who like a spot of programming with their process engineering, here's the code snippet that does it...

#root = getPersistenceHelper().getRootExchangeElementContainer(),
#counter = #root.getIntProperty("currentCounterValue"),
#counter = #counter + 1,
setName("Issue " + #counter),

Finalist for Eclipse Community Awards 2007

Just received great news - xProcess has been shortlisted (1 of 2) for the prestigious Eclipse Technology Awards in the category Best Commercial RCP Application. The two Technology Awards aim to recognize the best Eclipse-based commercial and open source products in the world.

"Finalists were selected from a pool of 63 nominations by a panel of judges from the Eclipse community". Way to go!

New white paper on priority-driven processes

Are your teams working on the most important issues to your business? If not you are losing potential earned value every day that goes by!

I've just finished a paper on this topic called Priority-Driven Processes, which you can download from the Ivis website. Such processes use the priority of deliverables as a key management control, enabling teams to focus on what provides greatest payback soonest. The paper is designed to help people to model and implement processes with priority, and draws on examples from FDD, XP and other agile methods.

If you do download, be sure to send us your feedback!

Do What You Do, But Better...

A recent discussion with Dave Garrett of Gantthead on the essentials of process improvement provoked some very interesting questions and answers. Please check it out on his blog under this title: Do What You Do, But Better...

Sugar-coating BigDecimal syntax

An aside for Java programmers... BigDecimal...
Don't you just love it! Love it and hate it that is.

Benoit Xhenseval recently emailed me about a proposal from within IBM to address the nastiness of BigDecimal syntax by supporting operator overloading in Java. It seems to me a very good way to make the elegance of BigDecimal's fully controlled rounding, with a reasonably readable way of using it. xProcess increasingly uses BigDecimals and I know readers and writers of its code would find this very helpful. If you're interested in supporting the proposal, see Glyn Normington's blog for more details.

Project Patterns

Creating project patterns in xProcess requires you to think about what are the framework parts of youroverall process. The diagram above shows a project pattern for a variant of Feature-Driven Development (FDD) and it's interesting to see how much of the process has been modeled here and how much elsewhere.

If you read the books on FDD - for example the one by Steve Palmer and Mac Felsing is a good one - you'll see that FDD is classicly drawn as 5 stages: Build a Domain Model; Build a Features List; Plan by Feature; Design By Feature; Buld by Feature. You can see from our pattern diagram that 2 of these stages did not make it into the project pattern. Why is that? There's a simple explanation: the last 2 stages in this description are repeated for each and every feature. These 2 stages are modeled within the Feature pattern so that their activities occur each time a feature is instantiated.

You can also see the project pattern contains the first 2 Timeboxes of the project (s…

Can we define custom fields for our tasks?

This a question that is often asked, and one that's important for many reasons but particularly where you are integrating the use of xProcess within an existing landscape of defined tools and processes.

Happily the answer is yes and there are a number of different ways to address the issue for different purposes. Firstly you can use the parameters available in pattern definitions, and use the values given to these parameters when user apply the patterns to set your own fields on elements of the pattern. You can also attach a UserDefinedSchema to a Task (or any other element) which enables editors to know what fields to expect even if they have not yet been set. The Task editor will show these fields in a separate tab entitled with the name you provide. Incidentally elements may hold data even it does not correspond to any current schema so you will not lose data even if UserDefinedSchemas change. You can use the fields you've defined in forms, reports, workflow and other defini…