[DanHulton]

From both the developer and manager side of things, I've found that the most important attribute of estimates is frequently the least paid attention to: that they be kept up to date.

When you discover more work hidden under that "simple" pile of code, you absolutely HAVE to update your estimate. Add more points, add more tickets, whatever. But then your various managers have the ammunition to decide what to do next - allocate more resources to the project, descope the project, push back the release date, etc.

Far too frequently, the estimate is set in stone at the start of the project and used as a deadline that is blown past, with everyone going into crisis mode at that point. The earlier the estimate is updated, the calmer and more comprehensive action everyone responsible can take.

[torginus]

Which if you try to do - those agile people will kill you for it.

They wrangle a number out of you which goes into an user story estimate, which feeds into a Gantt chart they use to make their pretty powerpoints they present to upper management to say that the feature will make it into the Q4 release.

If you move this number around the whole estimation will crumble, not that it wont in real life but you deprave them of two things - an illusion of control and somebody to blame when things go south.

[mpyne]

> Which if you try to do - those agile people will kill you for it.

Does this actually happen to you? This is literally the whole point of agile, is to change the plan as you learn more about your work. If you didn't want to change the plan you'd spend a lot of time on up-front planning and do waterfall.

Like, a Gantt chart is more or less explicitly anti-agile. I'm aware of the 'no true Scotsman' thing but we shouldn't buy into people using agile terms for what is really a BDUF-based plan.

[torginus]

> Does this actually happen to you?

Yes and millions of other devs who work in an enterprise 'agile' environment - where a single huge project is/was developed by armies of developers work on a single product with a strict-ish release cadence?

Have you heard about the horror that is SaFe?

I'm not convinced that true agile works or has ever worked on a project that was bigger than a dozen devs.

In practice, it's just another dishonest way of selling consulting hours, infantilizing and disempowering devs, and putting folks who have zero subject matter knowledge in charge by doing these feelgood rituals.

Agile (scrum) in practice at enterprise-scale projects tends to be a combination of feelgood BS +top-down micromanagement (product owners dicking around with task priorities) +traditional project management.

One of the key ways these agile people are incredibly dishonest, is that Agile at the top level is sold to enterprises as a way of keeping the old high-level project management style, with push-only command-structures, and agile people subsequently try to sugarcoat it as it somehow 'empowering' the devs and giving them autonomy, when the truth couldn't be farther from it.

[mpyne]

> Have you heard about the horror that is SaFe?

Yes, and I successfully argued against it by pointing it was was a wolf in sheep's clothing. It has as much to do with agile as waterfall does.

> I'm not convinced that true agile works or has ever worked on a project that was bigger than a dozen devs.

It works fine, large projects are inherently trouble which is why organizations should spend some energy into reducing the scale of an individual team's work rather than piling dozens or hundreds of people into yet another Too Big to Fail megaproject. If Google can build and maintain Bigtable with like a dozen devs then maybe you don't need 200 people and a PMO for your enterprise data warehouse consolidation project.

In fact the biggest issue with SAFe is the size of the project you'd try to use it on, not that it references agile style methods. Waterfall methods were even worse, which is the only reason charlatan consultation manage to keep selling organizations on things like SAFe.

> One of the key ways these agile people are incredibly dishonest, is that Agile at the top level is sold to enterprises as a way of keeping the old high-level project management style, with push-only command-structures, and agile people subsequently try to sugarcoat it as it somehow 'empowering' the devs and giving them autonomy, when the truth couldn't be farther from it.

You're right that this is dishonest and that people try and fail to cargo cult successful efforts they watch from afar. But that doesn't mean these successful teams weren't successful, or that there aren't common attributes of those successes.

That's always been the problem with methodological fixes to the software delivery process for organizations, you usually can't impose the structure from the outside anymore than you can meld your bones with adamantium without having a crazy mutant healing factor...

[Aeolun]

> If you move this number around the whole estimation will crumble

I still love this sprint where the further into the sprint we went, the further the ‘remaining work’ line went up.

It’s good we could do that without blame, but it looks super funny.

[kragen]

You're describing the opposite of Agile Development. The Agile Manifesto says, "Responding to change over following a plan."

[humanfromearth9]

Yes, but the comment is targeting those people that usually would say about themselves that they embrace agile, while actually fighting everything that changes their little schemes...

[kragen]

So should we be talking about how "those democratic people" put everyone who disagrees with them in concentration camps because that's what the Democratic People's Republic of Korea does?

There are, of course, extreme-right-wing reactionaries who make exactly that argument, but I don't think their example is a good one to follow.

[xboxnolifes]

That war is over. We lost.

[alanfranz]

I have noticed the same for a lot of long-running software projects. The estimate is created at the start an never revised.

Projects can and will fail or run late; but heck; a 6-months projects cannot found late after 5 months and 29 days; things must be discovered early, so that the most important issues can be addressed.

[solatic]

> But then your various managers have the ammunition to decide what to do next - allocate more resources to the project, descope the project, push back the release date, etc.

In your view, is this a good thing or a bad thing for developers? In other words, are developers incentivized to update their tickets because it gives their managers "ammunition" to make project changes?

I find that this is usually more evidence of organizational dysfunction.

Sometimes, its developers who don't have enough ownership - someone higher-ranking filled out all the tickets for them and left no room for interpretation, so changes require trashing a bunch of irrelevant tickets and writing a bunch of new ones, making for more communication overhead and less time spent in development. Developers are disincentivized to update tickets since doing so just becomes write-amplification for more bureaucratic overhead.

Sometimes, it's a communication breakdown. Tools like Jira are necessarily asynchronous, and decisions about what to build are necessarily political. Politics and asynchronicity don't mix, such discussions need to be held face-to-face. If they're held face-to-face, then having developers update Jira is pure overhead. Developers are disincentivized from updating Jira because either it's a one-sided conversation (lag in getting notified that your ticket was closed and the work on it should be thrown out, PMs don't always follow through with issue links from the closed issue to the newly opened issues, so developers lack context on what decisions were made on replacements), which is emotionally draining, or the conversation happens outside of Jira, in which case updating the ticket is a formality/not actual communication, in which case it feels like a waste of time.

For most development work, I'd argue that developers shouldn't be making changes in Jira, their managers should be, on the basis of frequent, synchronous communication with the developers they manage.

[dawnerd]

Exactly. And I’ve found this is incredibly hard to get people to do, developers especially. No one wants to say a task is going over / taking longer than expected but will gladly run over. It’s hard for pms to resource if estimates are not updated as scope and complexity changes.

Also doesn’t help when estimates become due dates.

[trueno]

This is why stuff like Jira is so polarizing for many developers. It is an additional translation tax on me, the developer, to have to go constantly keep this tracking tool thing up to date so that the product owners/managers stay off my nuts. The burden of effort is placed on me to make their tool functional that they can have what they need to provide roll up status. This tool virtually never benefits me, it's always a time consuming sidequest that breaks focus and scatters important information all over a kanban board where tickets disappear and makes it really hard to cohesively work as a unit to get anything done. Like many orgs we've had PM's and stuff try to mandate expectations on when those updates should be provided, somehow completely oblivious to the human nature of development: you should never expect that a developer can simply hop in and out of moments of deep focus and suddenly provide a bunch of updates regularly when it's convenient for you, as if that has zero impact on their work. It takes a toll, full stop. I won't say no to it, but I do expect PM's to know that style of PM'ing is effectively asking me to make your job easier by populating your tool with updates that are useful to you and not me because I'm well aware you aren't involved enough to assess where things are yourself.

We've gone through so many cycles of how to use Jira well at my org where these frustrations are shared and we try a different approach, and we're finally starting to converge on the idea that this has historically been a little too lopsided requiring too much tax on the developer doing the actual work. We agreed on a new approach that has actually been pretty awesome: the product owners or managers that are trying to direct a body of work must be a little more in the trenches with us to have an overall understanding of where the different pieces are in a moving body of work. We don't expect them to understand the nitty gritty work in the trenches, but at the same time no more 30,000 foot view product managers who just ask for status updates at EOD. _Everyone_, developers included, is responsible for keeping documentation up to date as we go. So we have central working-bodies of information to find details without having to cruise thru 100+ jira tickets to find details we're looking for. The expectation is that they're engaged enough with development whether in chat or on meetings that if they were blindsided by an executive asking for an update, they could speak to it with some authority over at the water cooler without having to go check Jira. This has really helped weed out the lazy product owners/managers, has forced them to thoughtfully consider their meeting schedules, and has placed the exceptional ones in the pod of work being done and really added a lot of velocity and together-ness about the things we're pushing along.

This approach we're using now was born out of some hurt feelings from projects that didn't go so well & we had to have some real restrospective convos where everyone aired out their beef. Those are good convos to have, I think a lot of teams would find that people aren't deceptively trying to screw you over. Being encouraged to level set human-to-human genuinely is one of the greatest parts of working where I work. Always walk away from those types of chats learning valuable things: for the most part our product owners really do care. Not just about their career aspirations but also about _us_ nerdy and sometimes socially maladjusted developers. They look forward to working with us, and they want to make this as easy as possible for themselves but also for the developers. In the past they spent a lot of time in planning phases trying to scaffold out a project in Jira and attaching timelines to it so that their needs are met to provide predictable timelines to their bosses... but also with the hope that by plainly outlining work it sort of 2 in 1 satisfies our needs and will make development timelines a breeze. We've had to ask them to cede rigidity on that latter part because even the software architects admit the work being done is often a moving target. And when that target moves, maybe you realized you need to add a pivotal software solution to the stack, you can sometimes throw like 45 planned tickets into the dumpster. New ship dates need to be assessed. This was our reality check that we were all collectively shit at adapting to the dynamic nature of any given project. Now, our product owners decided that the expectation they have of their own role is that they understand this dynamic and are prepared and willing to make the case about why the shipping timeline must change. So there's actually a pain point solved here: don't break your back doing so much up front work to try and guess/capture what the body of work might look like only for it all to possibly get thrown away, involve architecture a bit more in the planning phases, but most importantly let's engage throughout the project and we'll try our best to have shared ownership/interest in making sure where we are in the project is broadly understood by everyone involved.

We're currently in phases of implementing a major platform right now and it's just night and day better and dare I say fun. We're still keeping Jira up to date, but the product owners and PMs are more or less managing this as it is a tool they find useful. Removing the "can you update this ticket please" 24/7 has forced them to be a little more involved and have the right chats, but also makes us developers happier to jump in and get it updated on our own volition because we also want to help them have an easier time. If my PM pings me and says "hey I'm looking at this ticket that's stuck in blocked, I just wanted to make sure we got an update from so-and-so about provisioning this credential so I can follow up if needed" I will likely automagically jump in and be like "still stuck, but let me update that ticket for you there's a couple key details I want to make sure our there for you before you reach out". There's an inherent "we're both interested in seeing this ticket through" here that doesn't strike a nerve with either party. Pretty much everyone involved both developers & non developers has a really solid read on where anything's at and we're all just talking a lot more. And for developers I find that it's really good, even if you've got them committed in one narrow body of work, to understand the larger pieces in motion. When they're in tune with the broader orchestration of a projects timeline, they tend to weigh in during unsuspecting moments that might tie seemingly unrelated pieces together. They might be assigned to work on x, but in a group chat about y they notice y has a dependency on x and they'll speak up and call out the need to test that they both work together. We've had a lot of great callouts materialize like this, and on a human-psyche level I think it snowballs & avalanches encouraging developer participation in a way that is really meaningful for PMs. It's interesting that Jira & the expectation that predicting development time in an arena of uncertainty was previously in the way of forming the group dynamics we have now. Jira, despite just being a tool, can really amplify a lot of bad outcomes when it's used by those who aren't fit to be near development, it sort of devolves into a two dimensional behind-schedule tracker that detrimentally impacts how team members on the ground communicate with each other.

And since we're talking a lot more there's just like... way more memes. And memes are important in any development timeline. We prioritize laughing through the pain together.

[patrickmay]

This is a fantastic description of why Technical Program Managers (TPMs) can be force multipliers. Imagine involving someone who understands both the needs of Product and Engineering and whose job it is to allow both of them to focus on where they add the most value. We do exist!

[trueno]

It is very much this, your types are insanely valuable to how quickly and effectively we can blast through massive bodies of work that are well beyond the scale of personal-hobby-project. We're in the annoying HR-involved process of revising the role internally to actually include the word 'Technical _' & the bullet points of expectations will demand such capacities. It's been an exciting shift for us and we've reappropriated non-technical product owners/managers to roles they are happier in (and believe it or not we are happy for them).

We didn't get it right the first, second, third, fourth or fifth time. I'd say as an org we are learning lessons that other orgs may have learned a decade ago, but it's just nice to come to these conclusions on our own & really understand how our setup came to be. We hope we remember that things can evolve again in the future, but are grateful that we journeyed together and didn't just throw in the towel and fire people when things didn't work out. We believe sending people through some fires of hell, reassessing, then reattempting is sort of a cycle that levels people up.

We hope to have more technical product guys on board up ahead cause it's a dream setup that really organizes and harnesses velocity in all the right places, but also effectively stops unnecessary side-quests. It's so nice to have a technical product guy step in and say "no" to some absurd executive request because he/she is well aware of what such an implementation would look like. They can actually be vanguards and stewards over development personnel in their own way and it seems to go hand in hand with a lot of mutual respect for each other. Always get a kick out of nerding out over possibilities with our technical product dudes.