ZDS

Kintana Information

Enough of generalities. How do you actually, practically, go about setting up your first Kintana Demand workflow?

Let's try to automate the classic 'Bug tracking' process.

Since this is your first effort you're likely to try to do too much at once. Simultaneously trying to make sense of your bug tracking process and to learn enough about Kintana to figure out how to map your process into the tool is a sure recipe for going crazy.

The technical implementation, and the messy details of how to click though all those dialogs to set the workflow up in the tool can wait until later!

Trust me for the moment that getting the business process clearly defined, and collecting a fairly small amount of information about it is all that you need to deal with first.

What you need to come up with is:

A miniature railroad map of the process flow.

Plain English names that state what happens at each step in the process.

For each step, a list of the people with authority to perform it.

For each step, a list of the people who need to know that the request has reached or left the step.

Let's try and define the bug handling process as practised by the Quality Assurance and Developer Teams. Sounds simple enough. After all this is well understood process. Is'nt it?

As you will soon discover, if there are ten people involved in the process, there are twenty opinions on how it actually works. Morover each person involved is likely to consider some detail to be a critical part of the process that must be implemented. If you try and cater to everyone's requirements you're likely to end up with a workflow that looks something like this:

Whoa!

All the extra steps centered on the development team lead are non-essential and while he may want to keep track of them the workflow shouldn't have to.

The path to the left tracks cases where the developer's implemented what the specification called for, which as frequently happens is not what was wanted (or intended). Essentially it's doing book-keeping of 'not-our-fault' cases. This may be very useful protection for the development team lead, but from an organizational perspective a bug-is-a-bug-is-a-bug and all we want to know is how many and how long bugs sit on the Team Lead's door step waiting for a resource to be available to fix them.

The path to the right tracks cases where the development team lead is bundling bugs for fixes on the next interim release, or in effect dumping it by assigning to to be fixed on the next major release. Again this is local housekeeping that would have been better handled by adding interim/major release numbers to the request.

Now I freely admit this was my first workflow. Still, this is not what you want to end up with. Let's learn from my mistakes!

To ensure that your workflow will not get infested with all the pet elaborations that the participants 'need' you must identify a manager who can call the shots on this project. If you don't do this then you'll find that every user invested in the workflow is 'management'.

After the initial all inclusive kickoff meeting, chaired by the manager,keep the initial working group small. The people you want are the ones who know the process from soup to nuts, and they're usually not the section heads. They will be your focus group for your working model, and the test group when you have your first implementation. If you explain the KISS strategy to them properly, they will become your missionaries and strongest allies in defending your workflow from over-engineering.

The key to success here is to cut out the shortest straight-line path from start to finish assuming that everything works out with no problems.

For our bug tracking workflow that means that :

When a bug request is submitted someone in QA needs to get an email about it.

QA find the bug is documented with perfect accuracy so all they need to do it pass this over to the appropriate Team Lead in Development

The Team Lead finds a free developer and passes the request on to the developer to fix the bug.

The developer fixes the bug and notifies QA so they can check it out.

The bug was fixed right the first time, and passes the QA tests Ok so we're done.

This basically is it, and that's all that's important. From the time your workflow goes into production anyone can now run a report to find out what and how many bugs are just in, with the development team lead waiting for him to find a developer to work on it, being fixed, and finally being checked out by QA.

Just how elaborate your Demand workflow gets boils down to how many 'statuses' you want to keep track of for the request.

For example, consider how you want to handle these cases:

The person submitting the bug request has'nt supplied all the information needed to specify the bug clearly enough for a developer to go to work on it. You can either add a flow-back step with status 'Pending Clarification' to send back the request to the user for clarification or you could just have the QA analyst call back the originator, get the extra information, and have him add this on the Notes tab. without elaborating the workflow at all.

QA might not be happy with the fix and want to send it back to the developer for more work. Do we have the QA analyst add a note, call the developer, or add a 'Not Approved' transition back to the developer step?

There isn't an absolute answer to these questions.

I'd argue that in the first case, if there aren't a lot of these, and resolving this is just a matter of a phone call, then it's going to speed the process along if the QA analyst just picks up the phone, calls the bug originator, gets the required information, annotates the request with it, and moves the request on down to the project lead.

Remember the problems we had with the development team lead complicating our workflow with side flows to prove that work was'nt being held up by him? We can reasonably assume that requests sticking in 'Initial QA Review' status are there because they aren't adequately spec'd. Do we really need another status?

In the second case i'd say that we do need to define a 'Not Approved' flow back, and to the Team Lead, not the Developer because the Team lead may need to deal with resource issues - that developer may now be busy on something else. Also the QA analyst does need to formally document the problem in the notes field, and maybe add references to test documentation before sending the request back to the team lead - the changes may be handled by a different developer.

Cases like this tend to be the stuff and staff of the arguments that need to get resolved before you workflow is ready to go into service and you discover how well you have actually aligned it with the business process as practised in the real world. Try to restrict the number of statuses the workflow tracks to those that get asked in the production meeting. Try to arrange for people to co-operate outside the workflow by informal communication backed up if necessary with Notes and References (to external documents). It's what they do now anyway. You're not being asked to automate the whole world, and your workflow will end up an unwieldy failure if you try to do so.

Remember the old yellow inter-office envelope with the the ruled lines for you to fill in the addressee? You filled in a form stuffed it in the envelope, and wound that little piece of string around the button.

Kintana Demand works just the same way. You get an email that an issue's waiting for you to do something. You open the issue and fill in the information you need to add. The only difference is that the string's disappeared, and you press a button instead to send the issue on it's way.

We need to customize a request form to carry your custom bug tracking information. You can add one or more custom sections to carry the information you need. In this case one 'Bug Info' section was all that was needed. (The graphic is from an earlier version of PPM when custom information was grouped under 'Tabs' instead of 'Sections' but this makes no practical difference.)

The status tab shows the progress of the request.

It's good practice to number the (person oriented decision) workflow steps following the shortest-possible-path strategy so that the minimum path steps list first. The other steps can occur in any order.

Now you're ready to map the business process information you've captured into the tool.

Formally define the step names, types (Decision, Condition, or Execution), and Parent Status.

(The Parent Status sets the Request Header Status as a Request moves into the workflow step).

Set up 'validations' (menu choice lists) to be made at each step

Each choice represents a 'transition' (workflow branch or path)

Kintana Demand allows you to control who has the authority to execute a specific step in a Workflow.
Specifying a security group for a step where the security group contains the list of people authorised to make the decision is the normal way to do this.

When setting up Security Groups

Use sensible descriptive names that make it easy to identify the use or membership of the group.

Don't create any more security groups than you need. For example Steps 1 and 4 are both to be carried out by QA team leads so one 'QA Team Leads' security group can be shared by both these steps.

Notifications may be defined for each Workflow step that will be sent out either when the step is reached, or, if the step is a decision step, when out of the outbound paths or 'Transitions' is chosen.

This allows users to be notified by email if there is an Issue pending their action,
if a Workflow step failed, or even on an informational basis.

The best way to do this is to associate a security group listing the people to be notified with either the step being reached or an outbound path. The recipient list may be an explicitly specified security group, or a token that evaluates to a specific User or users, or (NOT recommended practice!) an explicit user name.

The first step (12) in the system is run when the bug originator submits a new bug request. It has some automated code that uses the application code to look up a list and sends an email to the QA analyst handling bugs for that application.

Note! 'ALL' should NOT be included in the application list or it will flood the inbox of the recipient!