Jira is just one fantastic example of tools that profoundly assist organisations in doing the wrong things righter.
— Bob Marshall (@flowchainsensei) September 24, 2013
My team uses JIRA. And MS Project. And Trello, Smartsheet, Workflowy, Basecamp, Google Docs, SharePoint, Jive, Dropbox and Excel. And that’s just the stuff I know about. The arsenal of tools to manage web and personal projects is staggering. Some are great for personal task management, some for file sharing, some for resource planning. JIRA’s the big beast though. Even the name comes from the Japanese for Godzilla.
But JIRA won’t tell you how far towards completing your project you are unless you know what ‘complete’ is. It won’t give you resource reporting unless your teams log their work. It won’t manage your change control process until you know what your change control process is. It won’t tell you that you’re overcommitted unless you said what you’d committed to do in the first place.
At one level, JIRA is just a task manager, but it can do more – it can help a team track effort, facilitate change management and churn out data on a project or it can be a time suck, give unreliable data, and force you to revert to any one of a number of other systems to compensate. I’ve spent several years learning and using various software or web-based apps and tools and it can often be really tempting to see a problem and immediately offer a tool to fix it, but I’ve ended up holding my breath until I’ve had the opportunity to ask some really basic questions about what the team needs. And keep on asking questions.
We started using JIRA while changing the whole way we work and running a huge project, so adopting a new toolset has felt less like putting the cart before the horses and more like trying to change the wheels on the cart while trying to navigate a road we’ve never been down at full speed. So we’re understanding the project with a whiteboard, paper and pens, gridding tape and conversations, and planning resources in a spreadsheet and on a wall. We’re dealing with tasks and bugs in JIRA, an environment the development team seems comfortable in. The system is constantly evolving. So is our project. So is the software. Existing in a continuum of constant iterative improvement and development, of both the project and the tools and processes to run it, is described by some people as agile, but sometimes I can’t tell the difference between what we’re doing now and what I was doing ten years ago. It’s all just trying to get the work done, and constantly asking how we can improve the way we work. Call that what you like.