I feel like this article represents a certain angst I’ve felt for a while.
In our small org, we have consistently re-written and re-factored our communication approach over and over again since the inception of our company, and we’re only six people. It’s that important.
I don’t think we have a perfect approach, but I think the part we get right is that we need to bend our approach to fit over and over again.
We use Slack, GitHub, ZenHub, email, Google Drive, Asana, with other context-specific stuff mixed in. We recently overhauled a few of these. I hope we can drop and merge a few of these, but time will tell.
This stuff is hard, and trying to solve too much of it with a standardized Jira approach is a recipe for waterfall IMO.
I think it also comes from a place of different org sizes having way different needs.
Small business:
This doesn't feel like it should be a hard problem. It's just talking to people, right? We don't have many people so yay
Planning to plan is a waste of time. Find something to do and do it or queue it to be done. Boom, done.
Wait, why did we get all these different things to do things and talk to people? We were just supposed to be working hard and fast.
???
Profit? Or take the time to do a retrospective on all the crap going on and aggregate.
Big businesses:
Well, we spent the money on this tool for 200+ seats, so use it for everything
We need you all on the same workflow to judge you all evenly
No kanban. How will we do sprint metrics review if you all are off doing your own thing?
No unique metrics. Only these things turned on in the tool. That way we can silently judge your teams against one another.
(I may sound salty, but that's mostly because I wrote a 15 page paper on how companies use Agile metrics wrong)
True Agile kind of sounds like exactly the process you've been doing. Try it. Does it work? Keep it. Did it not? Ditch it. Though I'm with @rhymes
that the timing of the email-less post was perfect :)
We use Slack, GitHub, ZenHub, email, Google Drive, Asana, with other context-specific stuff mixed in. We recently overhauled a few of these. I hope we can drop and merge a few of these, but time will tell.
This just popped up on dev.to, you called for it :D
Alyss has been working in tech since 2012, with diverse experience in Sales Engineering, Developer Advocacy, and Product Marketing with companies such as GitHub, Box, Atlassian, and BigCommerce.
What I personally struggle to reconcile is my experience with Jira vs. what I see so many people in the industry do with Jira. You've made a good point that re-factoring communication is a requirement and the same is true of any tool you use. Every organization is as unique as a fingerprint or someone's taste in food. You can't take the way you did Jira (or your favorite foods) and transplant the same style to another team/org (or feed your new boss your cordon blue recipe when she's lactose intolerant).
Similarly, Jira is incredibly complex and understanding those moving parts to create effective communication patterns is difficult. You have to step back and have the experience of solving the problem as well as the wisdom to know what will elicit the correct outcomes.
I think a large part of the problem with JIRA is that there's simply too many options - they're trying to please everyone (and his dog) which just ends up creating about a trillion possible horror configurations for every sane configuration.
I've recently switched to an ultra simple workflow, fields, statuses, etc. - and don't really hate it so much anymore. But the thing is, a tool with about 100 times fewer features could have done exactly what I'm doing with it. And it took 4+ years to work out the details.
So who's winning with a tool like this really?
It just seems, in trying to make it right for everybody, they actually managed to build something that isn't right for anyone at all, because it's simply too complex for most people to understand.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I feel like this article represents a certain angst I’ve felt for a while.
In our small org, we have consistently re-written and re-factored our communication approach over and over again since the inception of our company, and we’re only six people. It’s that important.
I don’t think we have a perfect approach, but I think the part we get right is that we need to bend our approach to fit over and over again.
We use Slack, GitHub, ZenHub, email, Google Drive, Asana, with other context-specific stuff mixed in. We recently overhauled a few of these. I hope we can drop and merge a few of these, but time will tell.
This stuff is hard, and trying to solve too much of it with a standardized Jira approach is a recipe for waterfall IMO.
I think it also comes from a place of different org sizes having way different needs.
Small business:
Big businesses:
(I may sound salty, but that's mostly because I wrote a 15 page paper on how companies use Agile metrics wrong)
True Agile kind of sounds like exactly the process you've been doing. Try it. Does it work? Keep it. Did it not? Ditch it. Though I'm with @rhymes that the timing of the email-less post was perfect :)
This just popped up on dev.to, you called for it :D
How we stopped using email at IOpipe
Pam Selle
Wow, great timing. Also amazing to see a first post from @pamasaur , I’m a big fan!
What I personally struggle to reconcile is my experience with Jira vs. what I see so many people in the industry do with Jira. You've made a good point that re-factoring communication is a requirement and the same is true of any tool you use. Every organization is as unique as a fingerprint or someone's taste in food. You can't take the way you did Jira (or your favorite foods) and transplant the same style to another team/org (or feed your new boss your cordon blue recipe when she's lactose intolerant).
Similarly, Jira is incredibly complex and understanding those moving parts to create effective communication patterns is difficult. You have to step back and have the experience of solving the problem as well as the wisdom to know what will elicit the correct outcomes.
When people complain about jira, they’re really complaining about how their managers have used jira and similar tools.
Definitely a people problem through and through.
I've never met a dev saying "I love Jira, it's my favorite tool" :D
As @preciselyalyss said, it's quite complex (though it got better in the last few years).
I think this complexity is by design though, because Jira is marketed to managers, not to developers.
I think a large part of the problem with JIRA is that there's simply too many options - they're trying to please everyone (and his dog) which just ends up creating about a trillion possible horror configurations for every sane configuration.
I've recently switched to an ultra simple workflow, fields, statuses, etc. - and don't really hate it so much anymore. But the thing is, a tool with about 100 times fewer features could have done exactly what I'm doing with it. And it took 4+ years to work out the details.
So who's winning with a tool like this really?
It just seems, in trying to make it right for everybody, they actually managed to build something that isn't right for anyone at all, because it's simply too complex for most people to understand.