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.
After 5 years of designing and developing Federal websites, a pattern has emerged. 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 beauty 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? Finally, JIRA is very 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. #1, 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 way 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.