re: Is Jira an antipattern? VIEW POST

re: helps teams choose their local implementations and still be able to work together (yes, large org. fun). It might be that my org is too large, bu...

It might be that my org is too large, but individual teams can't really pick what works best for themselves. Metrics need to be uniform across all teams, so no deviation from the norm that could cause your numbers to look off (though I haven't seen managers comparing velocities... yet...).

That sounds like a fairly unhealthy regime, measuring things that don't actually matter to the paying customer, only the kudos/bonus of the local manager(s) and feeding a morale destroying performance management system. It was stuff like this that encouraged me to leave my last employer (BT) and work somewhere smaller (320 people, ~100 devs in 2013) where I had an opportunity to help prevent us making the same mistakes... we're up to almost 1000 now, I'll let you know how it goes when we get to 1500 people around 2022!

Only thing I can think of off the top of my head at night is only break down to the epic level and give that to one person and let them roll with it. ... but for the most part be trusted to break it down and manage your own workflow/implementation.

This is pretty much what we are trying to do, with a team/squad (choose your metaphor) owning an Epic: typically delivery of a value providing (micro)service defined by an API (eg: data matching service, usage logging service, authentication service, etc.) or saleable things (products/featuresets) defined by their customer facing API/UI/UX. We have infrastructure and architecture squads, providing our base platform to deliver services into (currently in AWS) and managing our roadmap in the open (with customers!) for everyone to see/contribute if they wish. Critical to success in this trust model is open communication, not "managing messages" through traditional hierarchies. Jira actually helps with this, if a task is stuck people can see and help out (usually a hand raised in stand up), if a technology lets us down or a customer changes their needs we can see that in reports where tickets get bounced back, perhaps to architecture to try again...

measuring things that don't actually matter to the paying customer

Implying there are paying customers :) A lot of what is being worked on is internal, so there are stakeholders, but no one's getting rich off of it. The devs are 3 levels removed from stakeholders, so our perception is more that we're making a thing and telling people to use it rather than them actually wanting the thing. And our actual users are the employees several layers down from the stakeholders...

Sounds like you've got a really solid group and a good workflow in place! :D

The devs are 3 levels removed from stakeholders
And our actual users are the employees several layers down from the stakeholders

Are the end users part of the team?

One of the principles is "customer collaboration", where the customer (or a representative of them) should be part of the team.

If you're "making a thing" for who knows who, no wonder you feel that way :D

Are the end users part of the team?

Nope! The product's three-letter-acronym person at the top talks to the customer, who is the stakeholder, and people several organizational levels below the stakeholder are the ones actually using the thing that the stakeholder bought (it's a sister company, so we know of their org structure but aren't coworkers).

The stakeholder has access to our Jira as a part owner of the product, but what they want and what the person actually logging in to the system want are quite different.

code of conduct - report abuse