Tuesday, August 16, 2016

Managing to JIRA is Not Agile

How do you know if your JIRA/Agile project has a problem?

  • You are constantly talking about “improving the process”
  • There’s a blurry line between design and development indicating design is not being managed. 
  • Work is getting done for the ticket, and not for the project. 
  • Burn down rates are more important than deliverables. 
  • People are working slower, not faster. 
  • JIRA drives the project management instead of planning. 

A Bad Pattern Has Emerged - JIRA Does Not Compliment Design

For years I’ve worked on more than a half dozen Federal websites for various agencies, from the US Patent Office to USAID and a couple more places. I’ve participated in a very diverse set of projects with even more diverse teams and working styles. But two things have remained consistent throughout, the Agile development process and JIRA. All projects have been, or tried to be, Agile. Most projects use JIRA, a web-based project management and tracking tool made by Atlasssian Software.  Here’s the thing, ALL the projects heavily invested in the use of JIRA have been bad. And those few projects that have not relied on JIRA software, have been great. After a recent bad experience on another JIRA driven Federal project I see the pattern, and the problem is in part, with JIRA.

As a Designer I want to create a holistic end-to-end design for my website project. This is a best practice that JIRA disrupts. There’s a balancing act that needs happen between interaction design, web development, and usability and this balance is tenuous, and needs to be managed. Decisions that get made regarding how a page looks, will affect how a page is built, and how much it costs to build. How design work gets managed is as important as the effectiveness of the design work itself.

If there’s a disconnect between these three areas, projects start to churn. But here’s the thing about JIRA, it was made specifically for development and then later on adapted to be used for design and other project disciplines. Because JIRA started as a tool for programmers, it’s not so natural for requirements and design. And then, because it’s so heavily promoted as part of the Agile process, which is a big deal on Federal Contracts, Managers “manage to JIRA” and not to the project. Everyone is slightly confused. I’ve seen senior managers struggle on their own projects because of JIRA. They think work is getting accomplished because tickets are being closed and sprints numbers keep climbing, but then stakeholders are frustrated by not seeing real progress. There’s a very blurry line between design and development where production aspects of design work are taken for granted and not managed. It’s undefined what work should go to developers and which work is for designers, and hand-offs between the two are messy. And, this is a big one, if you are a good senior developer (or designer) you work four times faster than a recent grad. The kind of rockstar talent we really want building our government websites for us have a different style of working that is MORE Agile and a lot faster and thorough. This type of talent gets really bogged down when they work in a “managing to JIRA” situation. Why would you want a $200/hour person (this is the rate the government pays their vendors) spending time on JIRA (or Confluence) and not doing actual work?

JIRA is Bad for Usability and User Testing 

Ask any JIRA coach how to incorporate usability testing, and you will get a blank stare. QA testing, OK, usability no. Usability testing is vague in the Agile process so people make their own decisions about how to (or not to) do usability work depending on how they feel about it.

On a few Federal projects that did NOT USE JIRA here’s what I observed. Everything went great, work was completed quickly, the client was happy. These were mainly design projects (because I am a designer), development was going to be done separately after the design. Because these were design projects the work of design was being managed better than on the bigger combined discipline projects. In other words, design was not taking a back seat to development, and consequently planning for each area, including development was easier. How do you know what resources you actually need until you have a picture of what you are actually making? I’ve found that when development drives the design, spending on developers will go way up. Your project can be “in development” forever. It can be a lot more cost effective to separate design from development and create clear boundaries between the two.

How Can We Make our Federal Agile Projects Better? 

Maybe the design process needs to be a different separate process from development? Maybe managers should interact with JIRA and let team members focus on dong what they do best. Good senior designers should get more client exposure and can manage aspects of design work, especially if project managers and clients aren't as experienced with design. I think Agile is better for maintenance on websites and software, and doesn’t work when you are trying to create a brand new site. Too many different processes for something brand new vs. evolving something already running. And then there's planning. The projects that went very smoothly for me were very well planned before anything was started. What this tells me is that management needs to BE Agile too (not just close tickets), in order to maintain balance, costs and sanity.

Work With Professionals Who Already Do Agile Well 

There are lots of companies who understand design as well as technology and development.  A little research can connect you with these folks. But these companies are not "Fed-Ready" and that's a real problem that needs to change.

For comparison, here's a company that develops apps, and this is a great informative read.

- By Fueled - 10/04/2016

The Agile Development Process
"Again, it’s important to keep in mind that agile development encompasses many different methodologies. No business needs to use all of them, nor could any one business possibly use all of them. As such, the process varies depending on the project. "...