Why does Agile boil down to constant deadlines?

That's not Agile, that's Micro-Managile. I.e. how 90% of companies implement "Agile" after watching some YouTube videos on it.

Your company is not actually doing Agile but rather cargo culting it, like 99% of all companies who pretend to do Agile.

arbitrary deadline set by management

I think you already know this, but having management set arbitrary deadlines is quite obviously not agile.

it’s a failure of leadership more than anything

You're absolutely correct. Do the most senior members of the team push back on those arbitrary deadlines? Do they have influence to be able to do that? If not, your company may be lacking technical leadership.

that allow for asynchronous teamwork and should increase productivity

In my experience, the whole async teamwork thing doesn't really work. The latency between communication is too long and writing software is very much a social thing. I think it can work when teammates are largely working by themselves and on separate projects, but not when a lot of collaboration is required.

To be clear, the best teams set ambitious deadlines. Without deadlines you're just coasting. I've been there before and morale sucks. At the same time, a good management team should press you to set those deadlines while also encouraging you to adjust if needed.

My experience has been that companies often don't want Agile. People can say they do but in reality unless you are a product oriented company that focuses on the value of the product speaking for itself, Agile won't work. Developers are often not really thinking about the dollars and cents of the decisions they want to make. How many developers will properly stand behind a decision that two months of refactoring is worth more than a brand new feature? Similarly, is the developer going to stand in front of the client and tell them no to the new work to make room for refactoring?

Most of us are doing Agilefall and that's okay. You try to be Agile, you do more of a Waterfall style, and you just make it work. Or you do Kanban or whatever you do but it's not properly Agile. And again, that's okay.

This topic is the deadest-beaten horse in software development and honestly I don't really think it's about agile, "agile", or any particular process model gone wrong. It's a lot easier for me to understand it as the averaged response from engineering management having to handle continuous delivery. As the time required to receive your return on investment approaches 0, so must your processes of investment. Extending the process across multiple iterations requires justification and invites arbitrary deadline acceleration to mitigate competition and increase ROI.

It's a human problem. The average person can't actually wrangle the depth of interdependencies between engineering efforts of different scope and size and keep them aligned with the very tractable business opportunity timelines. Simplifying and crunching are the result.

The goal is to consistently deliver incremental value, to build a culture of continuous iteration / improvement, and to make predictable and reasonable commitments to maintain a sustainable pace of work.

Having to change your two-week plans regularly because you ignored something obvious isn't working incrementally. It's just bad planning.

If you are regularly encountering "unforeseen problems," then the issue is not unforeseen. Whatever the source is needs to be factored into your planning in the short-term, and resolved in the long-term. You are posting on ExperiencedDevs, not csMajors, so things you mentioned like tech debt are your problem as a professional to identify, raise, and successfully advocate for fixes for.

And so that they can put a hard stop on a “project” even though there almost never truly is

As a business you need to decide what level of investment / what quality of product you are aiming for. You cannot just allow things to drag on forever, or you'd constantly be wasting time adding bells and whistles instead of delivering the next big chunk of value for your customers.

Your meeting situation sounds funky, but I'm not grasping how you're simultaneously in hours of meetings every day yet struggling to schedule meetings due to time zone conflicts. People shouldn't attend meetings that aren't relevant to them, but that is all a matter of company culture and completely independent of agile.

Realistically, contracts are based on deliverables, budgets and deadlines. The only true agile is a recurring budget and ongoing discussions on what to do next. But most clients want to have clear expectations and that kills agile. The best way to go is when the client trusts you to spend their budget wisely, and if you consistently make them happy, you get to do it however you want. 

Going through similar bullshit right now.

Had a pre-standup sync, then stand up, then a 90 minute 'delivery status' meeting ???? How the fuck does this help the project go faster?

Management seem to avoid the root cause of problems (low performers on the team, including themselves) and try just about anything that comes to their head lmao.

What agile really did is expose how much of our industry is being run by MBA's with zero knowledge about building software and approaching the building of software as if we're all factory workers.

The real issue we has is just this; a lot of companies suck. And the hiring process for engineering managers is mostly on how confident they are in their interviews. This will never be fixed because this is a top-down cultural issue that can only be solved if the entire management tree is actually good at their job.

Not 'doing agile' doesn't solve this. At best it hides the problem.

Agile got hijacked by management's need for control and false sense of progress.

In my company, the sprint deadlines aren't just goals for the development team to hit, it's also a test to ensure the user stories coming from the product team are well-defined and actionable. Sometimes the issue is product, not development. Sometimes unforeseen issues are really odd-balls. Other times they could have been avoided if more planning or thought went into sprint planning. Missing one arbitrary deadline set by management is one thing because shit happens. Missing 10 sprints worth of deadlines is indicative of a different problem.

Inefficient meetings is an entirely different topic. Sticking people in meetings "just because" is a terrible idea.

Unfortunately this is very common mode of operation. The reason is money. The customer wants a piece of software and telling them it will be ready when it will be ready is not good enough. They want concrete dates and they pay for it.

Agile in most cases looks like you would try to squeeze rubber balls into a steel box.

I saw a youtube video once about agile contracts, and all agreement with the customer about delivery dates and content should be defined in an agile way to enable true agile software development. Never saw them being applied in real life unfortunately.

https://agilecontracts.org/

Because people get obsessed over optimizing the process. I'm currently working at a company where some people spend so much time trying to accurately estimate the workload of features they are planning to build that would have been better spent on actually building them.

And like every team, you run into unexpected road bumps while developing, which leads to even more time spent in meetings talking about how we can improve the process while analyzing various Jira graphs that quantifies how productive the team is.

I've told certain coworkers during meetings to just stop talking because they'd agreed with eachother for 15 minutes without realizing it.

I like to call it "manufactured urgency"

Because “it’ll be done when it’s done” isn’t a real answer that the business can plan around. People need to know when stuff is gonna be done

Because management doesn't understand what agile actually is (I actually had a professor in college who taught my project management fundamentals class say "I don't understand it agile, but here it is") and business loves deadlines. They tend to think that without a deadline, nothing would get done.

(Putting my business hat on) only very small companies or projects can be truly Agile, and those will usually be in a stage where there are no customers and their investors (internal or external) still have patience waiting for results.

Real companies have business deadlines, and those are translated to development deadlines. Can product managers do a better job pushing back on promises they can't deliver? maybe, but many times your team is part of a bigger picture and you won't delay the launch of a big feature because you need to have a slightly more elegant solution without pressure.

That's why abominations like SAFe were invented, they try to bridge the gap between the business and development.

(Putting my dev hat back on)

a long list of things: management, business, devs, and the scrum cert sellers. cert sellers transformed agile development from something a team can be into something a team does. hell, look at how you wrote agile; it’s written as a proper noun — like it is a deity. agile is an adjective, and that is important.

management and business will use numbers as a way to estimate deadlines. that’s the funny thing about math and numbers…people think they can solve the formula for estimating deadlines. i honestly prefer it if someone gives me a deadline so the team can decide what to fit in.

devs could push back a bit, but that is admittedly frightening. i do it often, and it isn’t always well received. whenever the team gets stuck during point estimates, i’ll tell them it doesn’t ultimately matter if the ticket is a 3 or 5 because it’s an estimate. by the team’s reaction, you would have thought i said the earth with flat.

Let's look at the influences on agile and how they lead to mechanisms to subvert what's in the Agile Manifesto.

1. Scrum preaches Predictabilty and Commitment and Transparency and lays these values on top of the extremely vague, ill-defined abstraction layer that is Agile. These values then become the vector by which a bad management can override any philosophy of adaptability the original manifesto might have had.

They become a mechanism why which velocity/predictability is an obsession, and by which developers can be shamed for not hitting a velocity target as they "violate their commitment". The transparency angle creates a zillion custom jira statuses that must be constantly updated and micro-monitored to ensure maximum transparency.

1. Compounding the damage and making it worse is the fact that XP (Extreme Programming) and the Software Craftsmanship movements have the value that documentation, fixing tech debt, refactoring only be done as part of feature work. Given these movements influences in Agile thought leadership, this value then becomes a vector by which a bad management can shut down any work to make a codebase less of a mess and support higher agility.

This leads to scrum masters and managements saying things like "You don't need dedicated time to refactoring or fix tech debt; we're doing Agile and it's part of the feature work and delivering value to the customer". Anyone who attempts to do the right thing and informally, under-the-radar bundle in fixing the codebase with feature work will have a lower individual velocity and will become a target for pips, terminations, and getting passed-over for promotion compared to their peers who do as little as possible to crank the feature out as fast as possible.

1. Agile Principle #6 states

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

The extreme emphasis on face-to-face communication becomes a mechanism by which management can justify 20 hours a week of meetings.

Agile didn't invent management dysfunctionality; it merely created a vastly superior distribution system for it and helped sanctify it further.

The Team should be setting their own deadlines. Each Sprint should be a deadline. As a team, everyone agreed that this was the amount of work they could complete in one Sprint. So isn't Agile by nature full of deadlines already?

I am not agreeing with deadlines imposed from outside the Sprint team, though if you are supporting a product in production, that is always a possibility. In a good Agile system, management should be able to set milestones and prioritize epics. There is a business to run after all.

Also, isn't it funny that you do a Sprint run (implying pushing yourself to the limit for a short duration).. then instead of resting, you do another Sprint, and another, until infinity - or you burn out and leave? Even the term they use doesn't support the insane idea.

Usuallyagile is only applied to development so sales and marketing don't run on agile meaning their deadlines are forced on development

it works best when you promise to deliver certain things in a sprint, and the end of the sprint applies gentle pressure to actually do that. i'll often descope nice-to-haves from a ticket or spin stuff off into dedicated tickets while doing the minimum necessary for the headline if it looks like it's going to significantly exceed its estimate

tech debt, documentation and so on should be factored into expected time taken for a ticket. if your project has lots of problems, picking away at them while delivering feature tickets is the way to go - the goal for tech debt is to keep it under control. strike a balance between tickets taking longer / less time than expected

complete the sprint and stakeholders get the progress they wanted. fail to do that, stakeholders get some of what they wanted and plan the next one better if necessary. finish your tickets early, squeeze in a low priority ticket that would otherwise never get scheduled

If agile is a wheel then I believe milestone are important on the road. They are an active part of the journey.

The point is visibility for managers, and not to create better software. Hence the constant deadlines. They want to know both what you are doing and if you finished it "on time". They generally don't actually understand what it means to build software.

Yup, bad Agile can turn into a CAN’T MISS IT DEADLINE every two weeks.

Welcome to the circus, at least there’s free peanuts.

Waterfagile

Constant arbitrary deadlines is a bad manager thing.

Managers have a problem: being responsible for things getting done, but not being the one who does any of it.

Good managers find good people and then do everything to help those people get what they need to do good work. This is exceptionally hard.

Bad managers apply pressure. That's it - they think their job is to apply pressure in order for things to be done. Deadlines is a primary way of doing so.

None of this has anything to do with agile.

I suppose Dev work has always been deadlines even in late 90s early 2000s but now it's just got completely out of control with deadlines on a week by week basis. Agile on paper with small packages of work and derisking features is a great idea, but Scrum has totally destroyed all that was great and good about it . For shity devs who wish to hide day to day week to week it's a brilliant mechanism for giving the illusion of progress but getting nothing done whilst your start up burns through its runway. I remember dev circa 2002 it wasn't uncommon to go a month between meetings and that was ok, as folk owned their work packages, sometimes we just had to trouble shoot engineering problems for 10-20 days asking only folk who could offer genuine insight without concerning or distracting everyone else. Simpler times.

Why does agile boil down to constant deadlines? Because you're doing it wrong

The constant deadlines is not a bug it is a feature. It brings transparency on velocity and a shared common view about the project’s progress every x weeks.

I have worked with scrum/agile in both positive and negative projects. The problem is usually not the deadlines but if there is a negative blame culture associated with deadlines being missed instead of the team, management and client being grateful about early on transparency and being able to find constructive solutions to e.g. an underperforming velocity.

When agile works well IMO the constant deadlines are there for feedback and you use them to adjust workload for the next sprint with the goal of finding the team’s “rhythm” so that the work load of each sprint is balanced to the capacity and you can assess if it matches the current scope and budget.

The end goal is thereby to give predictability and transparency early on rather than to optimize and try to increase speed and velocity. Usually predictability trumps speed IMO if I had to choose one.

Another BIG advantage with having deadlines every 3 weeks or so is that I believe we devs have a tendency to believe that we are 80% done with a task when we in reality are 50% done because we miss all the finishing touches for stuff in order to be production ready once we have managed to do the hard/unknown/problematic part of a task.

Then it is much better to get a constant reminder of this every 3 weeks when things should be finished up for real in the sprint so that it could be closed, instead of the last month of a 1 year project when the client is angry because they were out of the loop and thought everything was under control and now you are 70% finished when 11/12 months have passed and the budget is almost finished.

Bc you’re doing it wrong

The problem with fake 'agile' is really around trying to predict the effort of something that is inherently very difficult to predict. Sadly a lot of companies prescribe to what they think is predictability and repeatability. Where that's not how you build amazing software.

The best thing about Agile is that nobody does it right. Anytime it doesn't work, it's because it wasn't really Agile

Agile is not a management process that comes down from software engineering teams. It's a management process that comes down from the organizational structure.

If your lead engineers are "doing agile", but the product development roadmap for this quarter has to be approved by the business team before you can begin to execute it, and your performance as a team is evaluated in a way that prioritizes adherence to that roadmap over your ability to detect, evaluate, and respond to the experiences of users, you can only ever go through the rituals of agile.

The reason for the constant deadlines in agile is so that you can regularly resynchronize the direction of your development with the direction in which your users need your product to develop. Every two weeks or so, your team asks, "what did you do to help the user community this sprint?" and then plan, "what can we work on over the next sprint that most effectively responds to our most up-to-date feedback from our user community?" The business team is another stakeholder, but they mustn't stand between you and your users or you and your operations team. It's a conversation, not a box-ticking exercise.

But if you don't have direct feedback mechanisms for users, you're just going through the motions. Everyone knows you'll "discover" that the user community needs whatever was next on the roadmap the business team agreed to at the start of the quarter. If the organization's program management and reporting apparatus isn't agile, your development teams can't be.

"Arbitrary deadlines set by management"

That's the problem.

If you have arbitrary deadlines, the chances of that being set in such a way that all the arbitrary work that's been assigned to that deadline gets done is effectively zero.

It doesn't matter what project management system you want to use at that point.

I have 0 deadlines doing Agile.

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Worth bearing in mind that Scrum/Agile does not describe a role for "managers". It's a self organising mechanism for developers, product owners and scrum masters.

The scrum master is the closest thing to a manager and they are explicitly defined as a "servant leader". Their role is to protect the team and to ensure the team can meet their goals.

So whatever is going on in your company, it's not the fault of Scrum/Agile.

True agile means incremental development with demonstrable progress instead of deadlines.

PO here.

Management should not be setting deadlines, the team should do it instead. In my experience, even when given the opportunity to do so, most developers don't want to do it though.
It is much harder to plan for work you don't know you will have to do, but planning should take into account the potential unforeseen problems too. Overall if your team delivered only 50% of the planned work for multiple iterations due to issues like "tech debt, lack of documentation, no ownership of codebases" and you don't anticipate any kind of short term improvements on these topics then for your next plannings you should take only half of the work. Some features will probably be delivered faster than plan, others slower but on average the planning should be fine, as long as you meet the actual customer deadlines.

Sprint goal is not always used - and even when used nobody cares much about it in my experience. It is normally done to give a focus within the iteration, corresponding user stories have a higher priority than others. "sprint goal missed" can happen. Concern from management/PO could also be regarding the priority (did people take other tasks instead of the ones that matched sprint goal), escalation (did the team try to resolve/escalate issues encountered), communication (was the risk/delay related to this goal communicated at the right time to the relevant stakeholders) or improvement (is the team taking steps to avoid this problem in the future)

I do agree that the constant arbitrary deadlines (iterations) feel counter-productive. It takes time to build them, track them and they don't add value on their own: customer doesn't really care/know that we build part A in iteration 1, part B in iteration 2 and part C in interation 3 when they are not going to use the solution until we deliver A+B+C.

Using agile and its tools as a way to keep track of progress is definitely something that can happen (SAFe pushes that even more). It's not necessarily a bad thing in itself. Except when it's done at the cost of delivery efficiency itself: if management starts to put KPIs like "complete X% of the user stories from the sprint", then your team is probably going to focus on the quick wins, and plan less work overall rather than try to deliver what would potentially bring more value but has more unknowns.

The meeting feedback is indeed something that comes often with introducing agile, try to see which meetings can be removed / adjusted. But indeed the team wide meetings are not always very productive. It depends on how they are done too, for instance if the iteration planning is completely driven by the PO (assigning tasks to people, making the full iteration plan) instead of being driven by the team then there is not much point of having the full team for that one, it could be done asynchronously by the PO instead.

The only practical meaning of agile is setting the expectation that there will be more work to do when the budget runs out so the client either pays more or accepts the results.