6th April 2015
The Agile methodology was developed to work primarily with software development projects. Essentially it resolves the problem that there is a gap between what was asked for and what was delivered and the solution is to work more closely with the end user and to build discrete, useful software in phases (known as Sprints) rather than take a big bang approach.
At the end of each phase, the Agile team reflects on what it did and how it could do it better, thus building a cycle of continuous team improvement.
The essence of Agile Project Management therefore is:
- Collaboration - between development, delivery and the end user
- Management of work in discreet (though often linked) phases
- Continuous measurement that leads to improvement
This approach works for non-technical projects just as well as it does for technical ones, sometimes better. Most Agile project tracking software however is so jargon packed and inflexible it can only be understood by a software development team and business users recoil even from its UI. Gemini is not like that, it is specifically designed to bridge the gap between the business and IT.
5 Steps to configure Gemini for a non-technical audience
Step 1 – Use business terminology
The first step is to use business terminology and not technical jargon. If work is structured by Department and not ‘Components’ then ‘Components’ must become ‘Departments’. If people who work on the tasks are ‘Employees’ then ‘Resource’ must become ‘Employee’.
Altering Gemini terminology is simple. Because of its unique Project Template architecture, Gemini allows each group to base its projects on a Template that defines their jargon. To change any Gemini field name, navigate to the Template folder, open the Resource.xml file, enter the Gemini term and specify its override.
In the XML above you can see that ‘Components’ become ‘Department’ and ‘Items’ become ‘Enquiries’ simply by editing the Reource.xml file for the appropriate Template.
One of the decisions you will need to make in the naming convention is of the basic type of item you are tracking. In the example above Gemini is being used to track “Enquiries” so the basic Gemini term ‘Item’ is overridden (singular and plural). This is how in the default delivered Templates, ‘Items’ become ‘Tickets’ in the Help Desk Template, ‘Stories’ in the Agile Template and ‘Issues’ in the Issue Tracking Template.
Item types in Agile are hierarchical and Gemini supports an unlimited level of nesting of items through its Dependencies feature. If you rename the types of work item in the Agile Template then remember that a Story is the level at which a piece of work is defined from a business level and the Tasks (Task is a different type of item, capturing different data) that stem from it are its children. Tasks are the level at which Resources are assigned and optionally where Estimated and Actual time is tracked. You might want to override the term ‘Resource’ for ‘Employee’, ‘Team Member’ etc. if that is not how you refer to people involved in delivery in the business.
Step 2 – Use business statuses and workflow
The sample Project Templates that ship with Gemini are simply a starting point. Duplicate/alter the Agile Template and rename the Agile Status values to those that closely fit your business terminology. For example:
|Agile Status||Meaning||Business Equivalent|
|In Backlog||All outstanding work that will not be done in the current phase||Outstanding Tasks|
|In Sprint||Tasks selected for the current phase||Selected Tasks|
|In Progress||Work that has been assigned to a resource who is notified of such assignment.||Work in Progress|
|Tested||Released to someone who will verify/approve the work||Approved|
You can of course add more statuses or, if appropriate, remove a status. For example, you may not need to distinguish between ‘Selected’ tasks and ‘Work in Progress’ if the business process of selection incorporates work assignment at the same time. In Gemini you don’t have to use Status to indicate anything other than pure workflow as you can create any number of custom fields to refine a status value, or use the Resolution Code that comes out-of-the-box. If “Work in Progress” can have multiple meanings, don’t create different Statuses for each meaning, simply create a custom field with selectable values and avoid duplicating the condition of a work item for descriptive purposes. Status values should be used to simply mark a progression from Open to Closed.
Workflow is a simple point-click-drag action between the statuses you select and you can easily assign permission to groups of users to allow or deny status transitions.
Step 3 – Customize screens and set defaults
You should endeavour to minimize data entry to reduce human error and encourage usage, particularly among time-constrained business users. By setting defaults on fields such as Status, Dates etc. and by use of field permissions on screens, you can keep the data set that users must provide to a minimum. One of the best features of Gemini screens when it comes to keeping things simple is the use of Cascading Custom fields, an example of which would be Zip Code cascading from City. This ability to create inter-dependent field relationships and prevent incorrect data combinations, together with non-programmed business Rules and Actions makes Gemini ideal for deployment to an end-user audience or external 3rd parties.
Gemini also has a Portal mode, the ability to create external organizations with restricted access inside a project and a Read Only mode.
Step 4 – Enable email integration and recognize this essential tool of business
Email is an essential tool of business but many tracking tools don’t have it built in as a first-class feature. One of the strengths of Gemini is that the Breeze email-to-ticket component can be added to any project. You can define as many mailboxes as you like with rules for managing them. Gemini allows on-going communication around a single work item, tracking every email as a comment against the item so that nothing is ever lost. You can also reply from inside Gemini so there is no need to have disjointed, disconnected project communication because people have work-relevant emails in their personal inboxes.
Gemini has a free Outlook plug-in that allows users to create tasks from emails in their inbox at the click of a button.
Step 5 – Customize response templates
Every automatic notification that comes from the system is associated with an HTML alert template (resource assignment, workspace alerts, email receipt confirmation etc.) and each project can have a unique template for each notification type. You can customize the alert templates to contain the type of information that business users need and use business appropriate language. Use the same terminology in the alert templates as you use in the Resource.xml file.
Recap of steps to running your business project in Agile
- Collect the list of ‘stories’ – the things the business would like to do. Until you have decided to address them they should have a status that is the Agile equivalent of “In Backlog”.
- Working with all stakeholders, prioritize the work that you will perform in the next phase.
- Break the work down into tasks. A task is a discreet piece of work to be done by an individual. Try to avoid tasks that have more than one person involved in delivery to keep your estimates and time tracking tight.
- Fit the estimated work into standard chunks of time. It is recommended that you break your working cycles (Sprint in Agile) to between 2 and 4 weeks. The important thing is to keep the working cycle regular so you get to know roughly how much work the team can get through in any given cycle and you build up a routine. At the end of a working cycle everyone must be able to SEE progress, if not the entire deliverable. If you can’t SEE it then it’s not Agile! Work selected for the current cycle has the Agile equivalent status of “In Sprint”.
- If someone picks up a task to start on it they should set the Status on the task to the Agile equivalent of “In Progress”.
- Tested and Closed are self-explanatory, feel free to substitute a different Status for Tested but Closed has special significance in Gemini as it is the status where tasks will not be shown to you unless you specifically request to see closed work items.