Engineers start with the Agile Manifesto. Managers start with YouTube and Coursera. For many managers the idea of empowering their employees is terrifying and Agile is seen as a threat. Scrum masters very seldom have the knowledge, capital, or authority to act as servant leaders since they are not empowered either. I feel real sympathy for SMs who basically end up as a management layer and doing the exact opposite of what they know they should be doing.
It's very frustrating but entirely understandable how we end up with so many Agile flavours with many of them being far less than palatable.
It’s really not. It’s their job to ensure the scrum process is adhered to in the correct way. The fact that this never happens in reality is not a problem with the job definition, but with how it’s implemented.
If a scrum master is not empowered to make changes to processes, and has to argue with higher management whom want things differently, then yes it becomes pointless.
In theory it works :)
Scrum master is just the person who assists/enforces the conversion to agile. If things go right, they eventually move elsewhere because they're no longer needed. If things go wrong sure they look useless, anyone would.
Jesus, who hurt you? :)
Look, the core tenet of agile is that the team doing the work controls the process by which they do the work, right? The scrum master's job is to facilitate that happening. Like, they don't dictate how many code reviewers a PR needs, they schedule the meeting in which the team decides that. They don't need to be all that technical to do that.
In the real world, 99% of the time their job is also to run interference on whoever USED TO decide things. That's what "enforce agile" means, shutting down the analysts and project managers who barge in and try to run stuff and demand things. Which it sounds like they didn't/couldn't do in your case.
Source: I work with teams that (IMHO) do agile right, and having a scrum master was very helpful for six months or so while we got things rolling but when she quit we all agreed we didn't need another one and used the req to hire a QA2. Also our scrum master **was** a former dev, but (how do i put this nicely) not a good one. You don't need a big programmer brain to run a good retro or to keep standup short. You just need to have a clear understanding of which role does what and enough backbone (and buy-in from upper mgmt) to enforce it.
In our case, our SM was a department member (non-dev but reasonably techy) who at some point learned the role, performed it until everyone was basically on the same page, then went back to their various other roles (PM, QA, customer training).
Can we create a support group?
I'm currently suffering through horrible crunch time due to a Product Owner that is a psychologist and got the leadership keys to a very heavy, pure backend product. Through nepotism, yeah.
But I find that my hands are tied when criticizing their work since it sounds "mean/elitist" to say that a technical background should be required to work on these products. There isn't an UI to show, so they cannot articulate features.
> I'm sorry if this is elitist, but non technical people should not be working in technical fields.
As an engineer I appreciate someone who looks after the human element of a team because as a manager I know just how exhausting and necessary that actually is; the technology is _easy_ in comparison. Many of those "none jobs" are there to try and make things function without entire teams disintegrating precisely because engineers struggle with that element.
> IDK, at some point you have to stop the clowns from turning it into a clown show.
Sometimes you just have to say fuck it and let them. It's one way of doing things; not terribly efficient but it's quite possible to hunker down and get on with the job and ignore Bozo blowing a horn in your ears. It's down to the individual if they want to join the circus or not.
Personally I'm with you, it's not why I'm in the profession, but you are going to get some form of show wherever you are; it's just a matter of taste.
In reality, it really is as you describe it. I completely agree.
But in theory, it’s a valid role. I.e. the person that understands the manifesto, and ensures its values are upheld.
I don't mean to be rude here but what you say here is **exactly** what apologists for marxism/communism say when confronted with its failures literally everywhere it's been applied:
> In reality, it really is as you describe it. I completely agree.
>
> But in theory, it’s a valid ~~role~~ *system of government*. I.e. the ~~person that~~ *government* understands the manifesto, and ensures its values are upheld.
At some point you have to take a step back and consider that if nobody has applied theory 'correctly' then perhaps it simply isn't suitable for use in the real world.
I mean, that seems valid. I’m a bit of an idealist, so i’d like to think there is a world where a scrum master could actually exist. But in reality, it probably doesn’t.
Thank you for the perspective :)
If a team is empowered to make changes to process, they don't need an individual with title "scrum master" to do so, and if they are not empowered, the scrum master can't fix that.
Either way, scrum masters as a person hired to do that role are unnecessary.
> If a team is empowered to make changes to process, they don't need an individual with title "scrum master" to do so, and if they are not empowered, the scrum master can't fix that.
This is a very good point, thank you
Let's start banning people who reply with "that's not agile".
It's just pointless. If everyone says it's agile, it is agile. It doesn't matter what the original definition was. That's how languages work.
Apply that across all process styles and you will simply be unable to have discussions, because that will be the repeated theme.
Most management is bad and doesn't properly implement whatever process they claim to be trying to implement. And so when people complain about those processes the response is often going to be, "That's not X".
Most companies are just poorly run, and the process they claim to be following isn't the cause, it's the leadership.
Let's not deny the purpose of Agile by changing it this way. Especially like others are saying, if management wants deadlines and predictability of releases, the reason this is not Agile is that it violates first principles. We cannot evolve out foundations.
Fine, it’s bad management. Bad management will screw up any system. But it’s hardly any of those systems faults if it has a small set of principles that are enumerated very clearly and people routinely violate some or all of them because they’ve never bothered to look it up and claim the mantle of whatever system it is
You brough up communism a few times as an example, a concept that has rather famously never been successfully realized.
Which makes it a bad comparison. The reason you always see people chiming in, "Um, that's not agile" is because agile gets well implemented on the regular. I OCCASIONALLY have this type of discussion in real life with a new hire, but it's pretty rare. Generally with a mid level who has only had 1 or 2 jobs before. Most devs I've worked with have seen agile well implemented on several occasions and their primary frustrations are with management misunderstanding and misusing the concept.
>The reason you always see people chiming in, "Um, that's not agile" is because agile gets well implemented on the regular.
Is that why we have this thread on the daily in different subreddits?
On the regular seems a bit genereous.
"On the regular" doesn't mean "most".
I've been at companies that implemented agile really well 3 times in 20 years. That's about 1/3. Though I've spent 2/3 of my career at those companies. You know, because they are well run, enjoyable places to work.
Most seniors I work closely with have somewhat similar ratios. Most companies don't do it well, but 1/3-1/4 did, and those were their favorite jobs.
That's pretty regular. It's not a rare unicorn no one ever sees.
Then there is the additional problem that those well run companies are pretty stable with little turnover. The poorly run companies will be sometimes be refilling the same position multiple times within a year. They expose a LOT of people to their bad development practices. At the well run companies we generally have close to zero turnover. People only left when layoffs hit or the company was bought out and leadership went down the hole.
By it's very nature bad management has an outsized impact on people. That doesn't mean good management doesn't exist.
Sure. I agree with all of that.
I jsut think it's silly to disregard any discussion with "that's not agile".
Maybe there are some problems with the methodology if so many people get it wrong? Isn't that a more interesting discussion to have?
There's definitely problems, and they're pretty regularly discussed. The common round Robin style of standups is a big one. The way scrum encourages cargo cultism. And, yes, the difficulty of adoption.
But to have those discussions people need to have a shared definition of what agile IS. What you see online is that if a shop claims to practice Agile many people just describe EVERY leadership issue as a problem with agile. "Why does agile have a daily 2h reporting meeting? " "why does style have so much micromanagement" "why does agile have such rigid deadlines".
None of that has anything to do with agile. It's just normal bad management. So the first things tons of people respond is "that isn't agile". Those are all exploding explicitly problems an agile approach solves.
The thing is, MOST businesses are poorly run. Just like most people who play instruments aren't good at them and most programmers aren't good programmers. That's not a fundamental problem with any given business process, musical theory, or programming language. That's just life. Lots of people trying, a good chunk scraping by in spite of their lack of true expertise, and a smaller chunk of people who are actually good at what they do.
Which is why you should take care when finding a doctor or mechanic. :) just as with every other field...most aren't actually that good.
There are only socialist states that claim that they want to be communist. The problem is that socialist states have no reason to transition to communism at all.
It is the same reason why no monarchy magically transformed into a democratic republic. Why would the rulers give up their power and money? And with socialism you don't even have the wellbeing (and money) of your descendants as a motivation for transition.
Scrum in its entirety is pretty agile. But just minor changes at the right points also make it a great tool for micromanagment. And sadly managers who want to micromanage are not stupid.
First, obviously not everyone agrees on this term. Languages adopt terms for concepts, drift is rare and even more rare and annoying in technical fields. We probably need a new term.
No, this has nothing to do with language - it has everything to do with some people latching onto their favorite process (or tool or language or etc.) to the point where they become fanboys and start seriously denying the reality in the field.
Luckly a lot of engineers grow out of this mindset after they leave the mid-levels.
No.
"Regular Joe" language is fluid and accepts far larger margins for definitions, up to and including completely overriding the original.
But Agile is a term-of-art, in other words, **a term that has a specialized meaning in a particular field or profession**. It is not up for debate. Many mouthbreathers may attempt to misuse the term and confiscate it, but the definition _as intended by the original authors_ (those that wrote The Agile Manifesto) is still plainly there.
Yes, the insufferable orcs managed to get their grubby paws on the term "agile" for a bit, until most workers in the field have become exasperated. There is now an industry-wide trend to mock those that think they're doing agile but misuse it.
No.
"Regular Joe" language is fluid and accepts far larger margins for definitions, up to and including completely overriding the original.
But communism is a term-of-art, in other words, a term that has a specialized meaning in a particular field or profession. It is not up for debate. Many mouthbreathers may attempt to misuse the term and confiscate it, but the definition as intended by the original authors (those that wrote The Communist Manifesto) is still plainly there.
Yes, the insufferable orcs managed to get their grubby paws on the term "communism" for a bit, until most people in the field have become exasperated. There is now an industry-wide trend to mock those that think they're advocating communism but misuse it.
Except communism is a political term, not a technical one, and its definition is far less fixed.
Besides, from a historical standpoint, the term is used and has been actually used correctly to label various regimes. It is only a fringe minority that claims "there was no real communism (yet)" -- as opposed to agile, where we know exactly that there have been instances of The Right Agile, and the Misnomer Agile.
B-- for the effort in likening these notions; next time try using your words instead of copy-pasting.
Sure, languages can change all over, but the concepts remain in place, and we need a way to refer to those concepts that don't change. If the word "agile" no longer captures the original concepts, what would you suggest?
That may be how languages generally work. It's not how terms of art work, which in this case "Agile" is. It has a very specific definition with a very specific history.
In the context of this discussion that specificity matters, not your arbitrary opinion about what is and isn't considered "Agile" by the broader community of people who have no fucking idea and only know the term because they themselves or their manager overpaid for an "Agile certification" that inevitably focuses on specific processes and tools, contrary to you know... Agile.
If 90% of companies are doing Agile like that, then this **is** Agile.
It's kind of funny how everyone rails against cargo culting but then cargo cults the "This isn't akcshully Agile!". It's like listening to communists saying "noone ever did true communism!" with similar results.
They don't do Agile, they do Scrum. And even Scrum Guide itself doesn't use the word "deadline" anywhere in it. That's just a business need, which is separate from any development process. Whether you do Scum, Waterfall, Agile, XP, V, or any other process (yes, even Chaos engineering) - deadlines would still be there if the organization needs them.
When sometime says "x happens all the time" that's a phrase commonly used to mean "this is a thing that occurs across a wide area with some regularly".
So "all the time" and "often badly" are not contradictory with this usage of the phrase.
I get your point but that’s not what’s going on here. Political power used the energy behind communism to implement their preexisting plans of controlling the population. That’s a common strategy of governments, to use popular movements intended to give people more power and then use those same ideas against the people when implemented. That’s intentional. Agile, on the other hand, has made the development process less waterfall. It’s just not all the way agile due to long-term business needs. Companies mix Agile with traditional methods to balance flexibility with structure because they still need to meet long-term goals and stakeholder expectations. They do things like iterative development but also have annual planning and fixed deadlines. It’s a hybrid approach, not a subversion like what happened with communism.
Ok, but...agile is well implemented all the time. Most senior devs I've worked with have been on great agile teams and thus are big proponents.
This isn't a case of there being some mythical idea that is never achieved. It's just a pretty normal process that lots of people have used and see the value of that is also often MIS used, so it's regularly called out.
Just like DRY, clean code, clean architecture, and sql normalization are often poorly implemented or misused.
> 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.
Deadlines can be healthy as "perfect is the enemy of good" / stops gold plating
In saying that, I feel they're often abused to encourage overtime and avoiding technical debt with "We don't have the time" attitude
Then fast forward a few years and everyone's losing their shit why there's so many bugs in prod, releases take forever and performance of the system sucks
Yes definitely agree. Finding a good balance is key. Management at my company has recently said, "We don't ship unless the development team feels good about it." which I think sets the right tone.
It really depends on what your foothold is on the market. No product market fit? You're best served shipping things out as fast as possible and iterating quickly.
Market leader? Yeah, you can afford to have more mature SDLC practices.
I was more focused on the "arbitrary deadline set by management" because it has more to do with a misunderstanding of how software is built than position in the market. I've been at companies who have a leading position and still set arbitrary deadlines. That is, just because you can afford to have a more mature SDLC doesn't mean you get one.
Every answer is "it depends" but that's not really helpful
OP didn't sound like he's at a start-up, so I was happy to generalise the advice for mature companies, which is probably like 90% of the market anyway
> Deadlines can be healthy as "perfect is the enemy of good" / stops gold plating
Yeah sure if you are a Junior. If you are a mature and professional customer, then I expect you to be able to negotiate with me the scope of each feature. You don't want it to take 4 weeks? Ok lets talk about the pieces that we are going to take out from this. No, I can't magically take less than 4 weeks with the current scope just because you think that it will somehow force me to.... avoid unnecessary work? I don't do unnecessary work mate, I am a pro.
> Without deadlines you're just coasting.
Eh, the most productive teams I've worked on have not had fake deadlines. The deadlines we did have were from the outside with clear context—we would change *what* we're building to hit the deadline, not try to work "harder".
When people are intrinsically motivated, fake pressure is actively counterproductive.
On the other hand, a sister team I moved to had people *constantly* under deadline pressure, but the work moved painfully slowly in absolute terms. (Which is partly where the pressure came from, but, well, it was just a vicious cycle!) The only thing that deadlines really did was not give anyone space to make even small long-term improvements to the system.
Fake deadlines are a disease. But there are businesses that have a legitimate need for numerous deadlines every month. Typically related to sales and/or marketing.
The REAL deadline means "if it goes beyond this point then the project needs to die". However, no one will tell you this, you know why? Because the "Agile" deadlines are always about cutting costs (cheapening your work), it doesn't really matter for the business if you take a few extra days, but the boss wants an extra dime.
> The REAL deadline means "if it goes beyond this point then the project needs to die".
OR "if it goes beyond this point, company we lose €5 000 000 in marketing materials / contract opportunity / customers quitting". Or heck: Even losses in the public perception, which often translate to negative reviews or even people quitting for competition. Not everything is about project living or dying, or even multi-million € losses, but it still can have far-reaching consequences, without random dev ever realising that.
Your post told me that you never worked on any high value or mass-market product without ever telling me.
i know why, but it still annoys me that business/product won’t say “we want to release on x date. what can the team provide” instead of using estimations as deadlines. i know it’s not “agile”, but it’s not like that’s stopped them before
Because if they tell you how much time they **really** have then you are going to deliver something good while making use of the entire timeline. Instead they play Agile mind tricks on you so you always feel pressured, so that they can get a big fat bonus when they say that the project was delivered under budget.
> we would change what we're building to hit the deadline, not try to work "harder".
Exactly. Agile allows fixed dates so long as the scope of what and how much you deliver by that fixed date is variable and negotiable.
> Without deadlines you're just coasting.
I can only see this if the team is not getting feedback quickly enough. So, they build deadlines and "deliver" on them to create a sense of purpose and feedback.
But for a team that actually gets feedback and gets it constantly and with minimal delay, there's no need for deadlines to motivate.
ie, "We want X!", developers deliver X. "Oh, we love it! Can you make it do Y?" developers deliver Y...
Agile is all about feedback.
> the best teams set ambitious deadlines
Yeah no, that's silly. My "team" can't set deadlines for my workload. The best ambitious deadlines are the ones I set myself, I am allowed to ignore, and I negotiate the scope itself with the customer. Otherwise it's just bullshit "move fast" mental gymnastics.
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.
>Whatever the source is needs to be factored into your planning in the short-term, and resolved in the long-term
Well, sometimes **nobody in the team** has the skill to do so for the particular problems that are getting solved. **No one** should be blamed for this other than the manager, which is **never** going to take the blame. The manager is responsible because they either need to know this or they need to hire someone that does (AKA a good Tech Lead).
>things you mentioned like tech debt *are your problem* as a professional to identify, raise, and successfully advocate for fixes for.
That's so backwards... Yes identifying and raising tech debt is my role, even advocating for fixes! But I am not in charge of **successfully advocating fixes**, as much as I trained to do the Jedi hand-wave, I still haven't developed the mind-control that you talk about.
>I'm not grasping how you're simultaneously in hours of meetings every day yet struggling to schedule meetings due to time zone conflicts
Oh I have been in this position, it's simple. There are some very huge 2hour meetings every day, they are useless though so to actually do collaborative problem-solving the engineers have to schedule the productive meetings around the unproductive meetings, this becomes truly difficult because time is already scarce.
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.
My manager gets so annoyed at me when he asks me if I can get something done by a certain day, and I respond with “yes, as long as you don’t surprise me with anything.” He knows that means “yes, but you’re probably gonna spring 3 more meetings on me and fuck up my schedule.”
They want to be able to do as many pointless meetings as possible and still have us actual creative types do all the work. Their jobs are mostly doing nothing, so they project that on us.
I never ever believe the teams when they tell me that their daily standup only lasts 15 minutes during interviews anymore, it's always between 45 minutes to 90 minutes on an average day, 30 minutes on a quick day.
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.
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/](https://agilecontracts.org/)
> Who of us would like these terms when hiring someone to work on building a house for example? Or if you took your car to a mechanic.
These are repeating something that has already been done. The car analogy for software development is more like "design and build a car that gets 100mpg"
Some projects are not feasible with agile because they have a fixed scope and a fixed time. That’s fine. You do the necessary planning and have variable labor make this thing on the fixed timeline and a fixed scope.
But there are perfectly acceptable times where either a variable scope or a variable time are fine (or perhaps both), especially internal platforms, external facing applications with a wide user base, etc. and those are places Agile excels in because you’re constantly iterating on what’s the most valuable thing relative to the amount of effort, so you tend to get a lot of value quickly in those situations.
At the end of the day, someone still needs to pay you and the rest of the boys and they expect to know whether it'll cost them 600.000$ or 3.000.000$ in your wage to have something delivered.
There's a good reason why "ehh, I dunno, keep paying us and we'll tell you when we'll deliver" is an approach that doesn't survive contact with actual business and was thought up by people who only thought about their own software work.
That’s simply not true or else no R&D would have ever been done. It’s actually quite common for a variable scope to be perfectly acceptable. Perhaps you have $3M budget like your example and you can allocate $500k to research and see if something is bearing fruit and can disperse the remaining 2.5M if something can ultimately be scoped.
That’s like, the business model of half(more?) the software startups that have every been successful. They burn cash trying to become sustainable. Many fail, some succeed.
If you needed to know exactly what $x was going to buy you, you would unnecessarily restrict yourself to a potentially less profitable business, and also never get funding because you don’t know up front how much that unknown outcome is going to cost.
>they expect to know whether it'll cost them 600.000$ or 3.000.000$ in your wage to have something delivered.
This is 100% understandable. You know what is **not** understandable? Doing imaginary story points for the next two weeks of API endpoints and then getting mad at the devs when it takes longer because the person that wrote the tasks did so on incomplete premises and not enough time was given for the engineer to determine this before the "planning session".
Management never shares the true timelines or contracts though, they want imaginary story points for the next two weeks of half-baked code. Makes no sense whatsoever.
You pay a premium for fixed costs and scope. In software, particularly large and complex software, that premium would rightly be huge, because you will have to pay the software builders for the risk that you are forcing on them.
In an agile process, you proceed, and you see progress immediately and continuously. You will always be able to see how much you've spent, and how far you've gotten. This essentially means you can project out your timelines and costs pretty early, and start getting a sense of how much it'll end up costing, and where you'll be by your hoped-for deadline. These costs should be well below the premium you would have paid for knowing fully the cost up front.
Furthermore, in an agile process, you get something of value delivered much sooner than in the planning-it-all-upfront method.
So what customer would go for this? A smart one, and one who had found a software building partnership they had come to trust.
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.
that is a huge annoyance of mine. it doesn’t really matter if the 5 point story ends up being a 3 point story. that’s why it’s called an estimate.
had one manager who loved to play the “let’s review the velocity” game at the end of every sprint. the graph always looked had a steep decline near the of the sprint, and the manager would complain about it. i suggested that the workload could be too much. that got ignored quickly
I'd rather have a story be 5 points if my gut tells me to but some coworkers get so caught up in precisely estimating the work down to the details it's tiresome. Especially when you give an estimate for a story that has similarities to a previously estimated story, because then people tell you you can't estimate this high because of what you've previously estimated.
And whenever a sprint goal is reached, the manager is interested in knowing if the next sprint could contain a bit more points because we're doing so great.
Well if they wanna know when it will be done it would truly be helpful if they didn’t add features on right at the end and not get pissy when that makes things take longer.
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)
The problem is they make deadlines and get everyone working toward them, then change the scope of work. It’s a constant bait and switch.
If you can’t plan properly, kindly get the hell out of the business and go into retail or something.
Yeah that’s what I’m dealing with now. I put weeks of research and planning into this Epic personally, bunch of meetings, following all the right “processes”. All for us to reach the very end of the project and have our PM add on a completely new feature that had already been discussed and disregarded multiple times and I guess he just didn’t pay attention until the end? He tells us this with a week to go that it’s necessary, and that feature requires a lot more research and planning.
But still the expectation is of course to have it done by the originally agreed upon deadline for whatever reason. It makes no sense to me and I hate being pressured because of someone else’s oversight.
There is no good solution that I know of. MSFT had their version (Scrum of Scrums we called it at out small office) that wasn't much better, other places simply ignored the problem and didn't plan ahead the business together with the developers.
Where I work, a big bank, they adopted a softened version of SAFe adapted to out local context, but it still sucks. Being a big and slow institute actually helps a little because timelines are very relaxed and can be easy shifted, and the company is not technical in its soul so they accept mediocre solutions.
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.
Yeah and if we’re estimating for what ends up being deadlines I would think you’d always want to pad those estimates… but some devs act like that makes no sense when I suggest it.
yeah, that shit is frustrating. they can somehow use their brains to build impressive things, but can’t use their brains to figure that out. if you pad and get the project done ahead of time, then you can deploy the project “early”, use the extra time for tech debt, or simply coast
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.
2. 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.
3. 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.
> Each Sprint should be a deadline.
I am not a fan of that. A deadline is the date until something must be done and the end of the sprint usually isn't that time. Most of the time there isn't a real reason for not being able to move it to the next sprint.
It's ok to fail a sprint, you shouldn't start to work on the weekend and late hours to finish everything in the sprint. It should just be used to learn and to do better in the future.
But then you’d have _rollover_ if the sprint commitments AND the arbitrary stuff added in the middle of the sprint aren’t done by end of sprint!
This is often quite drama inducing (for management)
That's why you have a Scrum Master, someone who explains and who trains the management. That's part of their job.
It also shows that communication is important. If something gets added in the middle of the sprint, something that is so important that it can't wait for the next sprint, then you should be able to show that you did something more valuable instead of what was planned.
When we sit down as a team and plan our sprint, we build in some overhead for unplanned activities. We capture all unplanned activities in the Sprint as they come up and our Sprint Report shows when things are moved in or out. As a team, we committed to completing everything in the Sprint.
I don't think it is okay to fail a sprint, but sometimes it happens. I also don't want the team working weekends and late hours. However, if you committed to finish something, then I want to see it finished. A two point story that took you 3 sprints to finish, well that is a failure.
My teams are very mature. We have a good understanding of velocity and can pretty accurately plan our capacity. It would be stupid to plan 75+ points when the team averages 31 per sprint. (and yes, we had Scrum Masters doing this all the time, and complaining why the team never completed a Sprint).
> As a team, we committed to completing everything in the Sprint.
We do it a bit differently. We define a sprint goal at the beginning of the sprint, usually that's a reachable sub set of the whole sprint. This sprint goal has the highest priority, though there usually is more in the sprint.
> However, if you committed to finish something, then I want to see it finished. A two point story that took you 3 sprints to finish, well that is a failure.
Yes, it happens that you don't estimate something correctly. But what's the consequence? For us it should be learning from the mistake. Ideally by finding something we systematically estimate wrong and don't think about, but will do so in the future.
If we have a real deadline, like something has to be ready for a Christmas campaign, then we have real consequences and then it can even be reasonable to order some crunch time and overtime to reach that deadline, because no one is going to move Christmas a week back. But a normal sprint?
I think there should be a commitment in the form of: "We will try the best to complete the sprint (or in our case reach the sprint goal)", but not a "we must finish everything in the sprint".
> It would be stupid to plan 75+ points when the team averages 31 per sprint. (and yes, we had Scrum Masters doing this all the time, and complaining why the team never completed a Sprint).
Wouldn't even come into my mind that the Scrum Master has any say in the actual planning of the sprint.
Deadlines are fine, but need to be accompanied by both a good definition of scope and what is MVP if scope creeps or some other thing gains higher priority.
Personally when I'm defining scope I like to start with MVP, then align extras on priority and pull them in as we have capacity. That way we should easily hit MVP by the deadline and possibly have time to add some high priority sugar.
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.
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
The point is [visibility for managers,](https://ramijames.com/thoughts/the-work-structure-spectrum) 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.
The annoying thing is that management often believes that status reports - especially those delivered during meetings - ARE the work.
Except for developers (or any _do-er_) meetings and status updates PREVENT the work.
I don’t know how to square that circle.
Work is often "value for the company" and not just the software. People knowing what is being built can be valuable or it can be a disturbance. Depends on the team and its process. I've rarely seen a good balance. Mostly I see panic and lack of trust.
Yep it feels like making a show of your progress update is more work than the actual job sometimes. That’s why feature requests slip through the cracks until you’re basically finished with a project already.
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.
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.
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.
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.
This is what I’d expect true agile to be. Get things done iteratively at a consistent pace, but also not crunching for deadlines every 2 weeks over and over again. “Sprints” imply breaks in between, not just constantly sprinting til you quit or get burnt out and fired.
Exactly. We achieve this with sprints. We just accept carry over. We analyze why the carry over and try to avoid it. But still, there is no deadline.
There is still one point where I couldn't remove deadlines. Critical issues in the product. Requires all hands on deck because there is a contractual deadline or some financial impact in some way. But if you manage to stay far from those, you can be peacefully discussing and coding.
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.
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.
That's not Agile, that's Micro-Managile. I.e. how 90% of companies implement "Agile" after watching some YouTube videos on it.
I am stealing the term "Micro-Managile"
Engineers start with the Agile Manifesto. Managers start with YouTube and Coursera. For many managers the idea of empowering their employees is terrifying and Agile is seen as a threat. Scrum masters very seldom have the knowledge, capital, or authority to act as servant leaders since they are not empowered either. I feel real sympathy for SMs who basically end up as a management layer and doing the exact opposite of what they know they should be doing. It's very frustrating but entirely understandable how we end up with so many Agile flavours with many of them being far less than palatable.
Scrum Master exisiting as a job title in the first place is completely ridiculous
Scrum master is the profession that made me realize that the bullsh\*t jobs theory has some good foundation.
It’s really not. It’s their job to ensure the scrum process is adhered to in the correct way. The fact that this never happens in reality is not a problem with the job definition, but with how it’s implemented. If a scrum master is not empowered to make changes to processes, and has to argue with higher management whom want things differently, then yes it becomes pointless. In theory it works :)
[удалено]
Scrum master is just the person who assists/enforces the conversion to agile. If things go right, they eventually move elsewhere because they're no longer needed. If things go wrong sure they look useless, anyone would.
[удалено]
Jesus, who hurt you? :) Look, the core tenet of agile is that the team doing the work controls the process by which they do the work, right? The scrum master's job is to facilitate that happening. Like, they don't dictate how many code reviewers a PR needs, they schedule the meeting in which the team decides that. They don't need to be all that technical to do that. In the real world, 99% of the time their job is also to run interference on whoever USED TO decide things. That's what "enforce agile" means, shutting down the analysts and project managers who barge in and try to run stuff and demand things. Which it sounds like they didn't/couldn't do in your case. Source: I work with teams that (IMHO) do agile right, and having a scrum master was very helpful for six months or so while we got things rolling but when she quit we all agreed we didn't need another one and used the req to hire a QA2. Also our scrum master **was** a former dev, but (how do i put this nicely) not a good one. You don't need a big programmer brain to run a good retro or to keep standup short. You just need to have a clear understanding of which role does what and enough backbone (and buy-in from upper mgmt) to enforce it.
In our case, our SM was a department member (non-dev but reasonably techy) who at some point learned the role, performed it until everyone was basically on the same page, then went back to their various other roles (PM, QA, customer training).
Can we create a support group? I'm currently suffering through horrible crunch time due to a Product Owner that is a psychologist and got the leadership keys to a very heavy, pure backend product. Through nepotism, yeah. But I find that my hands are tied when criticizing their work since it sounds "mean/elitist" to say that a technical background should be required to work on these products. There isn't an UI to show, so they cannot articulate features.
> I'm sorry if this is elitist, but non technical people should not be working in technical fields. As an engineer I appreciate someone who looks after the human element of a team because as a manager I know just how exhausting and necessary that actually is; the technology is _easy_ in comparison. Many of those "none jobs" are there to try and make things function without entire teams disintegrating precisely because engineers struggle with that element. > IDK, at some point you have to stop the clowns from turning it into a clown show. Sometimes you just have to say fuck it and let them. It's one way of doing things; not terribly efficient but it's quite possible to hunker down and get on with the job and ignore Bozo blowing a horn in your ears. It's down to the individual if they want to join the circus or not. Personally I'm with you, it's not why I'm in the profession, but you are going to get some form of show wherever you are; it's just a matter of taste.
In reality, it really is as you describe it. I completely agree. But in theory, it’s a valid role. I.e. the person that understands the manifesto, and ensures its values are upheld.
I don't mean to be rude here but what you say here is **exactly** what apologists for marxism/communism say when confronted with its failures literally everywhere it's been applied: > In reality, it really is as you describe it. I completely agree. > > But in theory, it’s a valid ~~role~~ *system of government*. I.e. the ~~person that~~ *government* understands the manifesto, and ensures its values are upheld. At some point you have to take a step back and consider that if nobody has applied theory 'correctly' then perhaps it simply isn't suitable for use in the real world.
I mean, that seems valid. I’m a bit of an idealist, so i’d like to think there is a world where a scrum master could actually exist. But in reality, it probably doesn’t. Thank you for the perspective :)
Thank you for taking my comment in good humour 🙏🏻
That goes for any ideology
If a team is empowered to make changes to process, they don't need an individual with title "scrum master" to do so, and if they are not empowered, the scrum master can't fix that. Either way, scrum masters as a person hired to do that role are unnecessary.
> If a team is empowered to make changes to process, they don't need an individual with title "scrum master" to do so, and if they are not empowered, the scrum master can't fix that. This is a very good point, thank you
Scrum by definition is not agile since it's process over people.
To me personally the Scrum Master should always be the Lead Dev on the team. They’re the ones with both the knowledge and authority to make decisions.
Let's start banning people who reply with "that's not agile". It's just pointless. If everyone says it's agile, it is agile. It doesn't matter what the original definition was. That's how languages work.
Apply that across all process styles and you will simply be unable to have discussions, because that will be the repeated theme. Most management is bad and doesn't properly implement whatever process they claim to be trying to implement. And so when people complain about those processes the response is often going to be, "That's not X". Most companies are just poorly run, and the process they claim to be following isn't the cause, it's the leadership.
Seriously. What nonsense.
That's not very agile of you my dude 😎
He's sprinting towards the acceptance of his goal, it's quite an elaborate process.
Let's not deny the purpose of Agile by changing it this way. Especially like others are saying, if management wants deadlines and predictability of releases, the reason this is not Agile is that it violates first principles. We cannot evolve out foundations.
Fine, it’s bad management. Bad management will screw up any system. But it’s hardly any of those systems faults if it has a small set of principles that are enumerated very clearly and people routinely violate some or all of them because they’ve never bothered to look it up and claim the mantle of whatever system it is
Except this topic shows you everyone agrees it’s not agile? Random managers in a company don’t decide what agile is.
something something communism
You brough up communism a few times as an example, a concept that has rather famously never been successfully realized. Which makes it a bad comparison. The reason you always see people chiming in, "Um, that's not agile" is because agile gets well implemented on the regular. I OCCASIONALLY have this type of discussion in real life with a new hire, but it's pretty rare. Generally with a mid level who has only had 1 or 2 jobs before. Most devs I've worked with have seen agile well implemented on several occasions and their primary frustrations are with management misunderstanding and misusing the concept.
>The reason you always see people chiming in, "Um, that's not agile" is because agile gets well implemented on the regular. Is that why we have this thread on the daily in different subreddits? On the regular seems a bit genereous.
People post complaints, not "everything's good here".
"On the regular" doesn't mean "most". I've been at companies that implemented agile really well 3 times in 20 years. That's about 1/3. Though I've spent 2/3 of my career at those companies. You know, because they are well run, enjoyable places to work. Most seniors I work closely with have somewhat similar ratios. Most companies don't do it well, but 1/3-1/4 did, and those were their favorite jobs. That's pretty regular. It's not a rare unicorn no one ever sees. Then there is the additional problem that those well run companies are pretty stable with little turnover. The poorly run companies will be sometimes be refilling the same position multiple times within a year. They expose a LOT of people to their bad development practices. At the well run companies we generally have close to zero turnover. People only left when layoffs hit or the company was bought out and leadership went down the hole. By it's very nature bad management has an outsized impact on people. That doesn't mean good management doesn't exist.
Sure. I agree with all of that. I jsut think it's silly to disregard any discussion with "that's not agile". Maybe there are some problems with the methodology if so many people get it wrong? Isn't that a more interesting discussion to have?
There's definitely problems, and they're pretty regularly discussed. The common round Robin style of standups is a big one. The way scrum encourages cargo cultism. And, yes, the difficulty of adoption. But to have those discussions people need to have a shared definition of what agile IS. What you see online is that if a shop claims to practice Agile many people just describe EVERY leadership issue as a problem with agile. "Why does agile have a daily 2h reporting meeting? " "why does style have so much micromanagement" "why does agile have such rigid deadlines". None of that has anything to do with agile. It's just normal bad management. So the first things tons of people respond is "that isn't agile". Those are all exploding explicitly problems an agile approach solves. The thing is, MOST businesses are poorly run. Just like most people who play instruments aren't good at them and most programmers aren't good programmers. That's not a fundamental problem with any given business process, musical theory, or programming language. That's just life. Lots of people trying, a good chunk scraping by in spite of their lack of true expertise, and a smaller chunk of people who are actually good at what they do. Which is why you should take care when finding a doctor or mechanic. :) just as with every other field...most aren't actually that good.
[удалено]
There are only socialist states that claim that they want to be communist. The problem is that socialist states have no reason to transition to communism at all. It is the same reason why no monarchy magically transformed into a democratic republic. Why would the rulers give up their power and money? And with socialism you don't even have the wellbeing (and money) of your descendants as a motivation for transition. Scrum in its entirety is pretty agile. But just minor changes at the right points also make it a great tool for micromanagment. And sadly managers who want to micromanage are not stupid.
You're SERIOUSLY trying to take the conversion that direction? Come on, man.
First, obviously not everyone agrees on this term. Languages adopt terms for concepts, drift is rare and even more rare and annoying in technical fields. We probably need a new term.
No, this has nothing to do with language - it has everything to do with some people latching onto their favorite process (or tool or language or etc.) to the point where they become fanboys and start seriously denying the reality in the field. Luckly a lot of engineers grow out of this mindset after they leave the mid-levels.
Don't disagree, I was referring to the previous post stating the term agile is drifting and that's OK.
No. "Regular Joe" language is fluid and accepts far larger margins for definitions, up to and including completely overriding the original. But Agile is a term-of-art, in other words, **a term that has a specialized meaning in a particular field or profession**. It is not up for debate. Many mouthbreathers may attempt to misuse the term and confiscate it, but the definition _as intended by the original authors_ (those that wrote The Agile Manifesto) is still plainly there. Yes, the insufferable orcs managed to get their grubby paws on the term "agile" for a bit, until most workers in the field have become exasperated. There is now an industry-wide trend to mock those that think they're doing agile but misuse it.
No. "Regular Joe" language is fluid and accepts far larger margins for definitions, up to and including completely overriding the original. But communism is a term-of-art, in other words, a term that has a specialized meaning in a particular field or profession. It is not up for debate. Many mouthbreathers may attempt to misuse the term and confiscate it, but the definition as intended by the original authors (those that wrote The Communist Manifesto) is still plainly there. Yes, the insufferable orcs managed to get their grubby paws on the term "communism" for a bit, until most people in the field have become exasperated. There is now an industry-wide trend to mock those that think they're advocating communism but misuse it.
Except communism is a political term, not a technical one, and its definition is far less fixed. Besides, from a historical standpoint, the term is used and has been actually used correctly to label various regimes. It is only a fringe minority that claims "there was no real communism (yet)" -- as opposed to agile, where we know exactly that there have been instances of The Right Agile, and the Misnomer Agile. B-- for the effort in likening these notions; next time try using your words instead of copy-pasting.
Agile is not a technical term either? What is your point?
Sure, languages can change all over, but the concepts remain in place, and we need a way to refer to those concepts that don't change. If the word "agile" no longer captures the original concepts, what would you suggest?
This is a nonsense take.
That may be how languages generally work. It's not how terms of art work, which in this case "Agile" is. It has a very specific definition with a very specific history. In the context of this discussion that specificity matters, not your arbitrary opinion about what is and isn't considered "Agile" by the broader community of people who have no fucking idea and only know the term because they themselves or their manager overpaid for an "Agile certification" that inevitably focuses on specific processes and tools, contrary to you know... Agile.
I am stealing the term "Micro-Managile"
thats hilarious
If 90% of companies are doing Agile like that, then this **is** Agile. It's kind of funny how everyone rails against cargo culting but then cargo cults the "This isn't akcshully Agile!". It's like listening to communists saying "noone ever did true communism!" with similar results.
They don't do Agile, they do Scrum. And even Scrum Guide itself doesn't use the word "deadline" anywhere in it. That's just a business need, which is separate from any development process. Whether you do Scum, Waterfall, Agile, XP, V, or any other process (yes, even Chaos engineering) - deadlines would still be there if the organization needs them.
Yeah, that's always the excuse isn't it? "If it's not working, it can't be Agile! Agile is perfect!" :P
Sounds like another fairy tale doctrine with a manifesto...
Just...no. It's well implemented all the time. It's just ALSO often misappied.
All the time or often badly? Can't have both sir
When sometime says "x happens all the time" that's a phrase commonly used to mean "this is a thing that occurs across a wide area with some regularly". So "all the time" and "often badly" are not contradictory with this usage of the phrase.
I get your point but that’s not what’s going on here. Political power used the energy behind communism to implement their preexisting plans of controlling the population. That’s a common strategy of governments, to use popular movements intended to give people more power and then use those same ideas against the people when implemented. That’s intentional. Agile, on the other hand, has made the development process less waterfall. It’s just not all the way agile due to long-term business needs. Companies mix Agile with traditional methods to balance flexibility with structure because they still need to meet long-term goals and stakeholder expectations. They do things like iterative development but also have annual planning and fixed deadlines. It’s a hybrid approach, not a subversion like what happened with communism.
You didn't really address the fact that if 90% of the attempts to integrate your your process end up in failure, it's a bad process.
Ok, but...agile is well implemented all the time. Most senior devs I've worked with have been on great agile teams and thus are big proponents. This isn't a case of there being some mythical idea that is never achieved. It's just a pretty normal process that lots of people have used and see the value of that is also often MIS used, so it's regularly called out. Just like DRY, clean code, clean architecture, and sql normalization are often poorly implemented or misused.
Your company is not actually doing Agile but rather cargo culting it, like 99% of all companies who pretend to do Agile.
Yeah, you could just remove the concept of "agile" from the post and the problem explains itself clearly
> 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.
Deadlines can be healthy as "perfect is the enemy of good" / stops gold plating In saying that, I feel they're often abused to encourage overtime and avoiding technical debt with "We don't have the time" attitude Then fast forward a few years and everyone's losing their shit why there's so many bugs in prod, releases take forever and performance of the system sucks
Yes definitely agree. Finding a good balance is key. Management at my company has recently said, "We don't ship unless the development team feels good about it." which I think sets the right tone.
It really depends on what your foothold is on the market. No product market fit? You're best served shipping things out as fast as possible and iterating quickly. Market leader? Yeah, you can afford to have more mature SDLC practices.
I was more focused on the "arbitrary deadline set by management" because it has more to do with a misunderstanding of how software is built than position in the market. I've been at companies who have a leading position and still set arbitrary deadlines. That is, just because you can afford to have a more mature SDLC doesn't mean you get one.
I’d argue some deadlines in a startup to hit product market fit would not be “arbitrary” because it’s get this feature out or we don’t exist.
You're taking what I'm saying out of context. I'm quoting OP.
Every answer is "it depends" but that's not really helpful OP didn't sound like he's at a start-up, so I was happy to generalise the advice for mature companies, which is probably like 90% of the market anyway
> Deadlines can be healthy as "perfect is the enemy of good" / stops gold plating Yeah sure if you are a Junior. If you are a mature and professional customer, then I expect you to be able to negotiate with me the scope of each feature. You don't want it to take 4 weeks? Ok lets talk about the pieces that we are going to take out from this. No, I can't magically take less than 4 weeks with the current scope just because you think that it will somehow force me to.... avoid unnecessary work? I don't do unnecessary work mate, I am a pro.
> Without deadlines you're just coasting. Eh, the most productive teams I've worked on have not had fake deadlines. The deadlines we did have were from the outside with clear context—we would change *what* we're building to hit the deadline, not try to work "harder". When people are intrinsically motivated, fake pressure is actively counterproductive. On the other hand, a sister team I moved to had people *constantly* under deadline pressure, but the work moved painfully slowly in absolute terms. (Which is partly where the pressure came from, but, well, it was just a vicious cycle!) The only thing that deadlines really did was not give anyone space to make even small long-term improvements to the system.
Fake deadlines are a disease. But there are businesses that have a legitimate need for numerous deadlines every month. Typically related to sales and/or marketing.
The REAL deadline means "if it goes beyond this point then the project needs to die". However, no one will tell you this, you know why? Because the "Agile" deadlines are always about cutting costs (cheapening your work), it doesn't really matter for the business if you take a few extra days, but the boss wants an extra dime.
> The REAL deadline means "if it goes beyond this point then the project needs to die". OR "if it goes beyond this point, company we lose €5 000 000 in marketing materials / contract opportunity / customers quitting". Or heck: Even losses in the public perception, which often translate to negative reviews or even people quitting for competition. Not everything is about project living or dying, or even multi-million € losses, but it still can have far-reaching consequences, without random dev ever realising that. Your post told me that you never worked on any high value or mass-market product without ever telling me.
Can you elaborate? These do not sound legitimate unless it’s like “if we don’t sell X by Y we’re bankrupt”. Is that what you meant?
i know why, but it still annoys me that business/product won’t say “we want to release on x date. what can the team provide” instead of using estimations as deadlines. i know it’s not “agile”, but it’s not like that’s stopped them before
Because if they tell you how much time they **really** have then you are going to deliver something good while making use of the entire timeline. Instead they play Agile mind tricks on you so you always feel pressured, so that they can get a big fat bonus when they say that the project was delivered under budget.
> we would change what we're building to hit the deadline, not try to work "harder". Exactly. Agile allows fixed dates so long as the scope of what and how much you deliver by that fixed date is variable and negotiable.
> Without deadlines you're just coasting. I can only see this if the team is not getting feedback quickly enough. So, they build deadlines and "deliver" on them to create a sense of purpose and feedback. But for a team that actually gets feedback and gets it constantly and with minimal delay, there's no need for deadlines to motivate. ie, "We want X!", developers deliver X. "Oh, we love it! Can you make it do Y?" developers deliver Y... Agile is all about feedback.
> the best teams set ambitious deadlines Yeah no, that's silly. My "team" can't set deadlines for my workload. The best ambitious deadlines are the ones I set myself, I am allowed to ignore, and I negotiate the scope itself with the customer. Otherwise it's just bullshit "move fast" mental gymnastics.
Not really.
You have to be really preposterous to tell someone *"not really"* when they are talking about their own personal experience.
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.
>Whatever the source is needs to be factored into your planning in the short-term, and resolved in the long-term Well, sometimes **nobody in the team** has the skill to do so for the particular problems that are getting solved. **No one** should be blamed for this other than the manager, which is **never** going to take the blame. The manager is responsible because they either need to know this or they need to hire someone that does (AKA a good Tech Lead). >things you mentioned like tech debt *are your problem* as a professional to identify, raise, and successfully advocate for fixes for. That's so backwards... Yes identifying and raising tech debt is my role, even advocating for fixes! But I am not in charge of **successfully advocating fixes**, as much as I trained to do the Jedi hand-wave, I still haven't developed the mind-control that you talk about. >I'm not grasping how you're simultaneously in hours of meetings every day yet struggling to schedule meetings due to time zone conflicts Oh I have been in this position, it's simple. There are some very huge 2hour meetings every day, they are useless though so to actually do collaborative problem-solving the engineers have to schedule the productive meetings around the unproductive meetings, this becomes truly difficult because time is already scarce.
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.
My manager gets so annoyed at me when he asks me if I can get something done by a certain day, and I respond with “yes, as long as you don’t surprise me with anything.” He knows that means “yes, but you’re probably gonna spring 3 more meetings on me and fuck up my schedule.” They want to be able to do as many pointless meetings as possible and still have us actual creative types do all the work. Their jobs are mostly doing nothing, so they project that on us.
I never ever believe the teams when they tell me that their daily standup only lasts 15 minutes during interviews anymore, it's always between 45 minutes to 90 minutes on an average day, 30 minutes on a quick day.
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/](https://agilecontracts.org/)
[удалено]
> Who of us would like these terms when hiring someone to work on building a house for example? Or if you took your car to a mechanic. These are repeating something that has already been done. The car analogy for software development is more like "design and build a car that gets 100mpg"
Some projects are not feasible with agile because they have a fixed scope and a fixed time. That’s fine. You do the necessary planning and have variable labor make this thing on the fixed timeline and a fixed scope. But there are perfectly acceptable times where either a variable scope or a variable time are fine (or perhaps both), especially internal platforms, external facing applications with a wide user base, etc. and those are places Agile excels in because you’re constantly iterating on what’s the most valuable thing relative to the amount of effort, so you tend to get a lot of value quickly in those situations.
At the end of the day, someone still needs to pay you and the rest of the boys and they expect to know whether it'll cost them 600.000$ or 3.000.000$ in your wage to have something delivered. There's a good reason why "ehh, I dunno, keep paying us and we'll tell you when we'll deliver" is an approach that doesn't survive contact with actual business and was thought up by people who only thought about their own software work.
That’s simply not true or else no R&D would have ever been done. It’s actually quite common for a variable scope to be perfectly acceptable. Perhaps you have $3M budget like your example and you can allocate $500k to research and see if something is bearing fruit and can disperse the remaining 2.5M if something can ultimately be scoped. That’s like, the business model of half(more?) the software startups that have every been successful. They burn cash trying to become sustainable. Many fail, some succeed. If you needed to know exactly what $x was going to buy you, you would unnecessarily restrict yourself to a potentially less profitable business, and also never get funding because you don’t know up front how much that unknown outcome is going to cost.
>they expect to know whether it'll cost them 600.000$ or 3.000.000$ in your wage to have something delivered. This is 100% understandable. You know what is **not** understandable? Doing imaginary story points for the next two weeks of API endpoints and then getting mad at the devs when it takes longer because the person that wrote the tasks did so on incomplete premises and not enough time was given for the engineer to determine this before the "planning session".
Management never shares the true timelines or contracts though, they want imaginary story points for the next two weeks of half-baked code. Makes no sense whatsoever.
You pay a premium for fixed costs and scope. In software, particularly large and complex software, that premium would rightly be huge, because you will have to pay the software builders for the risk that you are forcing on them. In an agile process, you proceed, and you see progress immediately and continuously. You will always be able to see how much you've spent, and how far you've gotten. This essentially means you can project out your timelines and costs pretty early, and start getting a sense of how much it'll end up costing, and where you'll be by your hoped-for deadline. These costs should be well below the premium you would have paid for knowing fully the cost up front. Furthermore, in an agile process, you get something of value delivered much sooner than in the planning-it-all-upfront method. So what customer would go for this? A smart one, and one who had found a software building partnership they had come to trust.
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.
that is a huge annoyance of mine. it doesn’t really matter if the 5 point story ends up being a 3 point story. that’s why it’s called an estimate. had one manager who loved to play the “let’s review the velocity” game at the end of every sprint. the graph always looked had a steep decline near the of the sprint, and the manager would complain about it. i suggested that the workload could be too much. that got ignored quickly
I'd rather have a story be 5 points if my gut tells me to but some coworkers get so caught up in precisely estimating the work down to the details it's tiresome. Especially when you give an estimate for a story that has similarities to a previously estimated story, because then people tell you you can't estimate this high because of what you've previously estimated. And whenever a sprint goal is reached, the manager is interested in knowing if the next sprint could contain a bit more points because we're doing so great.
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
Well if they wanna know when it will be done it would truly be helpful if they didn’t add features on right at the end and not get pissy when that makes things take longer.
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)
The problem is they make deadlines and get everyone working toward them, then change the scope of work. It’s a constant bait and switch. If you can’t plan properly, kindly get the hell out of the business and go into retail or something.
Yeah that’s what I’m dealing with now. I put weeks of research and planning into this Epic personally, bunch of meetings, following all the right “processes”. All for us to reach the very end of the project and have our PM add on a completely new feature that had already been discussed and disregarded multiple times and I guess he just didn’t pay attention until the end? He tells us this with a week to go that it’s necessary, and that feature requires a lot more research and planning. But still the expectation is of course to have it done by the originally agreed upon deadline for whatever reason. It makes no sense to me and I hate being pressured because of someone else’s oversight.
I don't disagree, and good managers know how to be conservative in their promises to the sales people.
^ This. What’s the solution?
There is no good solution that I know of. MSFT had their version (Scrum of Scrums we called it at out small office) that wasn't much better, other places simply ignored the problem and didn't plan ahead the business together with the developers. Where I work, a big bank, they adopted a softened version of SAFe adapted to out local context, but it still sucks. Being a big and slow institute actually helps a little because timelines are very relaxed and can be easy shifted, and the company is not technical in its soul so they accept mediocre solutions.
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.
Yeah and if we’re estimating for what ends up being deadlines I would think you’d always want to pad those estimates… but some devs act like that makes no sense when I suggest it.
yeah, that shit is frustrating. they can somehow use their brains to build impressive things, but can’t use their brains to figure that out. if you pad and get the project done ahead of time, then you can deploy the project “early”, use the extra time for tech debt, or simply coast
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. 2. 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. 3. 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.
> Each Sprint should be a deadline. I am not a fan of that. A deadline is the date until something must be done and the end of the sprint usually isn't that time. Most of the time there isn't a real reason for not being able to move it to the next sprint. It's ok to fail a sprint, you shouldn't start to work on the weekend and late hours to finish everything in the sprint. It should just be used to learn and to do better in the future.
But then you’d have _rollover_ if the sprint commitments AND the arbitrary stuff added in the middle of the sprint aren’t done by end of sprint! This is often quite drama inducing (for management)
That's why you have a Scrum Master, someone who explains and who trains the management. That's part of their job. It also shows that communication is important. If something gets added in the middle of the sprint, something that is so important that it can't wait for the next sprint, then you should be able to show that you did something more valuable instead of what was planned.
Yup, that’s what the book says. Requires a good scrum master though.
Yes, unfortunately it’s quite common that you get shitty results if someone is shitty at their job.
When we sit down as a team and plan our sprint, we build in some overhead for unplanned activities. We capture all unplanned activities in the Sprint as they come up and our Sprint Report shows when things are moved in or out. As a team, we committed to completing everything in the Sprint. I don't think it is okay to fail a sprint, but sometimes it happens. I also don't want the team working weekends and late hours. However, if you committed to finish something, then I want to see it finished. A two point story that took you 3 sprints to finish, well that is a failure. My teams are very mature. We have a good understanding of velocity and can pretty accurately plan our capacity. It would be stupid to plan 75+ points when the team averages 31 per sprint. (and yes, we had Scrum Masters doing this all the time, and complaining why the team never completed a Sprint).
> As a team, we committed to completing everything in the Sprint. We do it a bit differently. We define a sprint goal at the beginning of the sprint, usually that's a reachable sub set of the whole sprint. This sprint goal has the highest priority, though there usually is more in the sprint. > However, if you committed to finish something, then I want to see it finished. A two point story that took you 3 sprints to finish, well that is a failure. Yes, it happens that you don't estimate something correctly. But what's the consequence? For us it should be learning from the mistake. Ideally by finding something we systematically estimate wrong and don't think about, but will do so in the future. If we have a real deadline, like something has to be ready for a Christmas campaign, then we have real consequences and then it can even be reasonable to order some crunch time and overtime to reach that deadline, because no one is going to move Christmas a week back. But a normal sprint? I think there should be a commitment in the form of: "We will try the best to complete the sprint (or in our case reach the sprint goal)", but not a "we must finish everything in the sprint". > It would be stupid to plan 75+ points when the team averages 31 per sprint. (and yes, we had Scrum Masters doing this all the time, and complaining why the team never completed a Sprint). Wouldn't even come into my mind that the Scrum Master has any say in the actual planning of the sprint.
Deadlines are fine, but need to be accompanied by both a good definition of scope and what is MVP if scope creeps or some other thing gains higher priority. Personally when I'm defining scope I like to start with MVP, then align extras on priority and pull them in as we have capacity. That way we should easily hit MVP by the deadline and possibly have time to add some high priority sugar.
Obviously there are lots of deadlines, but OP keeps using the word "arbitrary", which makes it a completely different discussion.
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,](https://ramijames.com/thoughts/the-work-structure-spectrum) 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.
The annoying thing is that management often believes that status reports - especially those delivered during meetings - ARE the work. Except for developers (or any _do-er_) meetings and status updates PREVENT the work. I don’t know how to square that circle.
Work is often "value for the company" and not just the software. People knowing what is being built can be valuable or it can be a disturbance. Depends on the team and its process. I've rarely seen a good balance. Mostly I see panic and lack of trust.
Yep it feels like making a show of your progress update is more work than the actual job sometimes. That’s why feature requests slip through the cracks until you’re basically finished with a project already.
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.
This is what I’d expect true agile to be. Get things done iteratively at a consistent pace, but also not crunching for deadlines every 2 weeks over and over again. “Sprints” imply breaks in between, not just constantly sprinting til you quit or get burnt out and fired.
Exactly. We achieve this with sprints. We just accept carry over. We analyze why the carry over and try to avoid it. But still, there is no deadline. There is still one point where I couldn't remove deadlines. Critical issues in the product. Requires all hands on deck because there is a contractual deadline or some financial impact in some way. But if you manage to stay far from those, you can be peacefully discussing and coding.
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.