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.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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
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.
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.
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!
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.
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!
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...
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
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
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.