4 ms·

"Jira sucks" is not a useful thing to say. Yeah, Jira's default workflow isn't awesome. Yeah, it's a giant pain to configure an alternative workflow; and the l

"Jira sucks" is not a useful thing to say. Yeah, Jira's default workflow isn't awesome. Yeah, it's a giant pain to configure an alternative workflow; and the learning curve to do so is ridiculously steep. Yeah, some BigCorps have configured painfully bureaucratic workflows in it. But you can also configure it with a very Trello-like workflow. Why would you use Jira with a Trello-like workflow instead of just using Trello? Well, for one thing, you get additional features even just on the Kanban board - such as swimlanes. But the most important reason is that with Jira you get a true database of your issues. One that you can query with a SQL-like language. And one that allows you to present multiple different views of the same data. For instance, we have a main kanban board for one project. We have a main board for another. We have a kanban board that contains some issues from each specifically for our DevOps person; and another specifically for our QA person. The QA person's board contains three columns that correspond to a single column in the developer's board. I can create an "epic" that contains multiple tickets (not subtasks or checklist items) that can each progress through the workflow and be deployed independently but still be grouped together under a single parent epic. And if I want to pull up a list of all Foo component tickets that were filed by Bob before June, implemented by Alice, QAed by Carol, and were released in July - and then open each one in a tab - that's incredibly easy.

wpietri 9y ago
I get why you're excited about this, but I think it's a mistake. One thing I've seen over and over is projects where everybody did their job and the project still failed. Why? Because everybody was put into silos. Each person could define success as doing what they were assigned. The developer built to the spec. The database person made the database work. The QA person verified that the system met the spec, and the ops person made sure the servers stayed up. No actual value was delivered, but everybody can say, "Well I did my job!" Elaborate systems like this encourage people to focus on output, not outcome. You don't have a team so much as a umber of individuals who happen to be working on the same thing. Teams are groups of people who win and lose together. They have a common goal and focus on achieving the goal. One of the reasons startups are so powerful is that early on you have a cross-functional team that is intensely focused on outcome. Everybody knows that "did my job" doesn't matter if the company's going to run out of money in a year. The incentive is toward a much deeper intellectual engagement. It's not just, "Did I do what I was told?" but "Am I doing the right thing for the user and the company?"
- dangoor 9y ago
  I agree about the need for successful cross-functional teams. But what happens when you have multiple cross-functional teams? Sometimes they have interactions. Sometimes you have management that needs some visibility into how things are going.
  - wpietri 9y ago
    I agree those are issues, but I've not actually seen Jira solve them. With or without Jira, cross-team coordination issues mainly get solved by teams talking. I've definitely never seen Jira solve a management visibility problem. Even if a team uses Jira fully, and even if the work is properly represented in Jira, and even if it's represented in a way that's more about the business need than the technological process, Jira is still a system for reporting on output, not outcome. Just last week I was talking with an executive whose teams use Jira, but he still has little idea how things are going. He really wants it, but Jira's not satisfying that need. I doubt it can.
- twobyfour 9y ago
  A siloed mindset doesn't come from giving people personalized views of their actionable work. And making those views available doesn't prevent people from opening the other views or seeing the big picture. Our team works as a very unified team despite having the ability to pull up specialized views of their own work. Tools that prevent people from focusing in on their own work are no substitute for good communication.
  - wpietri 9y ago
    A siloed mindset doesn't come from that. But it is encouraged by it. Whereas tools that present a unified view of the work (e.g., [1]) encourage a unified view. I agree a great team can use whatever and have things still work. But most of the people buying tools are hoping they will help solve organizational issues. So it's the non-great teams that concern me most when we're talking about tool selection. [1] http://williampietri.com/writing/2015/the-big-board/ http://williampietri.com/writing/2015/the-big-board/

wpietri 9y ago

I get why you're excited about this, but I think it's a mistake. One thing I've seen over and over is projects where everybody did their job and the project still failed. Why? Because everybody was put into silos. Each person could define success as doing what they were assigned. The developer built to the spec. The database person made the database work. The QA person verified that the system met the spec, and the ops person made sure the servers stayed up. No actual value was delivered, but everybody can say, "Well I did my job!" Elaborate systems like this encourage people to focus on output, not outcome. You don't have a team so much as a umber of individuals who happen to be working on the same thing. Teams are groups of people who win and lose together. They have a common goal and focus on achieving the goal. One of the reasons startups are so powerful is that early on you have a cross-functional team that is intensely focused on outcome. Everybody knows that "did my job" doesn't matter if the company's going to run out of money in a year. The incentive is toward a much deeper intellectual engagement. It's not just, "Did I do what I was told?" but "Am I doing the right thing for the user and the company?"

dangoor 9y ago
I agree about the need for successful cross-functional teams. But what happens when you have multiple cross-functional teams? Sometimes they have interactions. Sometimes you have management that needs some visibility into how things are going.
- wpietri 9y ago
  I agree those are issues, but I've not actually seen Jira solve them. With or without Jira, cross-team coordination issues mainly get solved by teams talking. I've definitely never seen Jira solve a management visibility problem. Even if a team uses Jira fully, and even if the work is properly represented in Jira, and even if it's represented in a way that's more about the business need than the technological process, Jira is still a system for reporting on output, not outcome. Just last week I was talking with an executive whose teams use Jira, but he still has little idea how things are going. He really wants it, but Jira's not satisfying that need. I doubt it can.
twobyfour 9y ago
A siloed mindset doesn't come from giving people personalized views of their actionable work. And making those views available doesn't prevent people from opening the other views or seeing the big picture. Our team works as a very unified team despite having the ability to pull up specialized views of their own work. Tools that prevent people from focusing in on their own work are no substitute for good communication.
- wpietri 9y ago
  A siloed mindset doesn't come from that. But it is encouraged by it. Whereas tools that present a unified view of the work (e.g., [1]) encourage a unified view. I agree a great team can use whatever and have things still work. But most of the people buying tools are hoping they will help solve organizational issues. So it's the non-great teams that concern me most when we're talking about tool selection. [1] http://williampietri.com/writing/2015/the-big-board/ http://williampietri.com/writing/2015/the-big-board/