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
Parameters: (none)

Having done this you can expand your task hierarchy in the explorer, select the tasks you wish to set size on, and then right-click and select UI Action -> Set size to match effort .

Note: From version 2.9 of xProcess this action is included in the Simple Process.

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 Diana Ross for the title of this entry.)

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 sdtimes.com 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 tools that will equip organizations and projects to deliver more, faster with less!

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 parent tasks and composite tasks which are collections, iteration or selections of task patterns. As Project Manager you can plan near-term activities in fine detail while leaving tasks that are further into the future as larger activities that will be planned in more detail as time progresses.

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 implementers. A number of key enhancements to xProcess in recent months have been motivated by improving our application of the Scrum process with SwiftTeams. We'll be looking for more in the coming months too.

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 delivered so far); and schedule efficiency (how much more or less value you have delivered at this point in time compared to the baseline plan).


xProcess supports EV analysis in the Executive Dashboards client (see screenshot). The Executive Dashboards provide an overview of multiple projects (or just one project if you like) so it's an ideal place to look at these efficiency levels in different projects. We may revisit how to use the views provided in later blog entries so watch this space.

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:

• Time
• Effort
• Quality
• Productivity
• Size

While Putnam and Myers experience covers projects ranging from the small to the truly massive, using a wide range of methodologies and covering five decades of software projects, Mike Cohn's book "Agile Estimating and Planning" is focused very much on the agile development processes of more recent history. It is similarly an excellent read with a mass of very practical advice for project managers of agile projects. I particularly liked the "Planning Poker" variant of the Wideband Delphi approach (!) but there are many other practical suggestions and insights, including discussions of burndown charts, velocity and prioritisation.

The challenge for me, working as I am on the product direction of xProcess, is to ensure that the full range of techniques and processes represented in these books is well supported by the underlying model and user interface of the product. xProcess has always been about agility, and in particular bringing powerful techniques from established project management methods and making them available to managers and participants of agile projects in such a way that they remain agile. These books similarly contribute to that drive to achieve controlled, productive and agile software projects.