Once upon a time

There was a time when it sounded perfectly right to introduce a ticketing system for software development in a service desk environment:

• It would streamline the flow of incoming and outgoing tickets.
• It provided a central location where management could see the queue of tickets pending, in progress and done.
• It would fit in the ‘an electronic tool for every purpose’-type of culture.

However, in a lot of situations, it would only lead to additional problems:

• A “throwing it over the fence” attitude.
• Tickets bouncing back and forth because they weren’t clear enough because A/ they were missing context, B/ the developer didn’t feel like doing this kind of job, or C/ the business guy didn’t want to close or approve the ticket as he felt it didn’t meet his unexpressed expectations.
• The indirect communication between developers and business people resulted in lack of empathy and bad morale. When the developer and the business person finally met in real life, it often created a ‘f*ck you’ behaviour as a lot of frustrations already piled up in the ticket logs.

The agile revolution

Then the agile revolution came and people started to tweak this way of working so that it would meet some of the agile principles. They started to work in iterations, used ticket priorities to determine iteration planning and started to use agile co-operation and self organizing processes within the IT team..

However, not getting rid of the tool as the primary communication channel between the different departments was still a very important flaw in thinking that the process now suddenly was perfectly agile. The first line of the agile manifesto makes this clear:

Individuals and interactions over processes and tools

A suggested scrum-based solution

Stop using the tool

First of all, ditch the tool, at least for now. You can always go back to using a tool when the process works fine, but you should never try to use tool to compensate for poor communication or customer interaction.

Instead, start using a cork board for your planning:

• it works for every type of user, also the ones who aren’t that tech savvy.
• it guarantees optimal visibility
• you can carry it around
• it’s extremely user-friendly and flexible

Unless the business people are located in a different floor or building, running around with the cork board might just be fine.

Short iterations

Use short iterations, so start with iterations of just a single week. After all, you are working in a helpdesk environment, so people might feel that two-week iterations are too long for bug fixes.

Involve the business

Involve the business people in the sprint planning, daily stand up, sprint review and sprint retrospectives just like in ‘normal’ scrum. It creates mutual empathy and understanding and will make everybody’s life easier.

Create a ‘fire’ slot

Here comes the magical trick: Reservate the first line or swimlane on your cork board for unexpected ‘fires’ or emergencies. The business people can add a task in this swimlane whenever they want (even in the middle of a sprint) but they should never add more than one at the same time. This task will get absolute priority and might put other tasks on hold until this one is finished.

To avoid that they keep on filling up this swimlane with one task after the other, you might need to agree on some criteria.

Your (simplified) cork board might look like this:

User stories remain under ‘open’, and their tasks flow from left to right on the board. Also note the yellow swimlane for fires and emergencies (maximum 1 at a given time!).

If needed or desired, you can use kanban to reduce the number of items in progress. This is not a necessity, but it will help you to keep the number of WIPs (Work In Progress) under control so that the flow and resulting output are optimized.

How do YOU handle helpdesk-oriented environments in an agile way? Feel free to let me know: stefan.luyten@gmail.com.

Stefan Luyten

For more information: http://www.triton-consulting.be