Quote:
One thing that writing elegant software has in common with art: its crafters should remain cognizant of the overall macro vision of the project at the same time they are working on its smallest micro details. JIRA, alas, implicitly teaches everyone to ignore the larger vision while focusing on details. There is no whole. At best there is an “Epic” — but the whole point of an Epic is to be decomposed into smaller pieces to be worked on independently. JIRA encourages the disintegration of the macro vision.
What’s more, feature-driven JIRA does not easily support the concept of project-wide infrastructure which does not map to individual features. A data model used across the project. A complex component used across multiple pages. A caching layer for a third-party interface. A background service providing real-time data used across multiple screens. Sure, you can wedge those into JIRA’s ticket paradigm … but the spiderweb of dependencies which result don’t help anyone.
Worst of all, though, is the endless implicit pressure for tickets to be marked finished, to be passed on to the next phase. Tickets, in the JIRA mindset, are taken on, focused on until complete, and then passed on, never to be seen again. They have a one-way life cycle: specification; design; development; testing; release. Doesn’t that sound a little … um … waterfall-y? Isn’t agile development supposed to be fundamentally different from waterfall development, rather than simply replacing one big waterfall with a thousand little ones?
This is all basically a complaint with agile imo. Focusing on the details rather than the big picture is a feature of agile, not a bug. I'm glad I don't have to look at all that crap my project manager does. Just show me the tickets my team has to work on so I can refine and organize them. I can still focus on the UX and architecture big picture as needed, w/o getting bogged down in the project management crap.
It's true that Agile doesn't handle project-wide/cross-sprint platform dependencies well. We used to keep those in a separate project. You just have to give up on that stuff perfectly fitting the model, and be happy it's being tracked and detailed somewhere so everyone is on the same page.
As far as pressure to mark tickets finished - there's a scene in Silicon Valley where Richard converts the devs to agile and gives them a bunch of tasks on post-it notes. Suddenly they're competing with each other to knock all the post-it notes off their plates. It's a joke - but there's some truth to it imo. It taps into a basic human desire to mark your **** finished, slide it over on the kanban board and onto someone else's plate. You start to feel like you have momentum going and get more involved - vs. waterfall where you have this giant list of **** and don't get any pats on the back when you cross out one line on your to do list.
I feel like maybe the author is on a team of devs trying to work Jira on their own w/o a project manager. I don't know what that would be like - but I have a feeling it would suck.