re: Is Jira an antipattern? VIEW POST

FULL DISCUSSION
 

I'm not convinced that Jira is at fault itself, it's a very flexible tracking tool that can be used/abused in many ways. As others have suggested here, I think it's the tutorials, courses, examples (maybe the defaults too) and wider culture surrounding Jira that cause the problems, likely because of it's heritage.

My company is experimenting with alternative team organisation & delivery approaches: things like DAD (disciplinedagiledelivery.com/intro...), which is well supported by Jira, and working in autonomous squads, guided by a common System Development Life Cycle strategy that helps teams choose their local implementations and still be able to work together (yes, large org. fun).

The mantra of breaking problems/issues/delivery down into bite size pieces doesn't have many alternatives (please suggest some though!), and Jira let's a team do that, provided they choose why & how carefully, then write those principles down :)

 

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, 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...). I'll have to look more into that methodology, thanks for the link!

The mantra of breaking problems/issues/delivery down into bite size pieces doesn't have many alternatives

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. Roughly T shirt size how long it should take, actually use stand ups to get feedback on your approach rather than status updates, but for the most part be trusted to break it down and manage your own workflow/implementation. Maybe you ship code daily. Maybe weekly. Lots of peer reviews or few. That could be a team policy or a personal one depending on how you work, whatever. You wouldn't get a diverse skillset if epics are taking a month or two, but you would get people who are experts in their zone who can pound out bits quicker than constant context switching and they'd have the high-level thoughts of how it should look and work in the end while doing the early work.

 

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.

 

Perhaps the problem is managers trying to use a collaboration and work tracking tool as a way to measure performance. This inevitably distorts the work - whatever is measured or set as a goal will become the goal.

code of conduct - report abuse