One Example of How to Use an Agile Tool with Balance

best agile toolbox
So many tools… which one to choose? Check out our great list of Agile Tools

Using an Agile or Scrum tool like many that we have in our list and those reviewed can be a challenge. We’ve helped many companies utilize their ALM’s well, and we’ve even helped even more remove the challenges that Agile tools can create… and let’s be honest, sometimes the problems they create.

I, for one, am tool agnostic, any client that’s worked with me will tell you the same. My adage when it comes to any type of tool usage is this:

The effectiveness of any tool is the discipline [enterprise-wide] to use it well.

Working with assertive people is always great, they even sometimes come up great ideas, like a colleague of mine, Jason did on their current implementation of Jira:

Current benefits of Jira

The tool provides a number of benefits if properly maintained

  • Mechanism for anyone, including customers, to quickly log issues or create stories
  • Easy integration with Confluence, the document repository
  • Easy integration with Tempo, the time tracking tool
  • Snapshot of stories and defects in the product backlog
  • Snapshot of stories and defects in the sprint backlog
  • Easy integration of combined backlogs
  • Snapshot of stories planned for a release
  • Email notifications when a ticket is created or updated
  • Quick dissemination across the team of this information, including offsite and extension to customers

Current challenges of Jira

Currently, the tool is over-engineered, resulting in abandonment

  • Too many options available; it is a Frankenstein of new fields and options built over a long period of time over many projects and types of projects
  • Workflows too complex (provide screen capture of the current WFs. They are spider webs)
  • WFs have unnecessary steps; people just ‘click along’ to close stories
  • Too much effort to move tasks and stories through the queue, resulting in waste
  • Workflows are built at the task level, requiring an unsustainable amount of discipline by every team member to keep it updated
  • Email subscriptions result in a torrent of email, so they get ignored or filtered out. Can’t differentiate between an important update versus a trivial comment
  • Too difficult to understand what’s ready/backlog, what’s WIP, and what’s done
  • Unless every team member has updated every task at all times, it’s not accurate
  • Few PMs/SMs use it for release planning; they either don’t have the time to maintain it or they don’t know how
  • Some resources rely on the tool to assign tasks, expecting the task to be done, and the task assignment to the assignee is lost in email
  • Using a tool to “assign” tasks inherently results in a push system, further resulting in pushback and missed commitments
  • Due dates are seldom applied, and when they are, they come and go. If something needs a due date, a team discussion is needed, NOT data entry into a tool that isn’t used
  • Therefore, predictably, teams have abandoned the tool. It takes ALL of these things in perfect synchronization for each piece to be meaningful. This model is unsustainable and not scalable
  • And therefore, Mgt. cannot point to a single project where the status is concise, simple, and clear to them what’s happening; it communicates little meaningful information for our managers unless a PM/SM is physically there to walk them through it. This defeats the purpose of having a web-based tool in the first place

Proposed solution

In short, use the tool to do a few things well, instead of everything for all projects

 

Things to change or stop doing:

  • Pull the existing workflows. The workflow should be one simple workflow:
    • Initial state: Open. It stays open and only open while assigned to the product backlog or the sprint backlog
    • Then you only have two options:
      • Means it’s done.
      • Means it’s rejected, duplicated, de-scoped, working as designed, etc. Keep these selections when cancelling.
    • That’s it. Anything more complicated than that and the tool will be abandoned
  • Tasks and subtasks no longer maintained in Jira. These are for the team to manage and should be done on a physical board
  • Stop relying on Jira to communicate due dates. If something is urgent and a due date needs to be committed, a team discussion should take place to understand the impact to the current work queue and negotiate what is deferred in its place
  • Stop relying on Jira to push tasks through a queue. Tasks should be pulled by the team, not pushed onto individuals

 

Things to keep doing

  • Open new defects and stories
  • Close or cancel defects and stories
  • Maintain product backlog; use the rapid boards to move stories into sprints
  • Track stories to epics
  • Track releases and release dates
  • Assign stories and epics to releases
  • Link stories as-needed to Confluence
  • Maintain relationship with Tempo
  • Assign an onsite resource to update the physical board for offsite resources; send photos of board(s) to offsite team members

Leave a Reply