Eventually features get dropped from a version if they aren't ready. So what does it mean? Did you make the deadline? Or did you not?
You made "the sprint", and dropped what you could not do. So no: there was no deadline.
Same for the other examples. It is ready when it is ready. A deadline does not change anything about the stuff people have developed before the "point of time" or after it.
All cryptocurrencies are underpinned by the belief that people will trade something of value for them. Same for fiat currencies. Or don't you remember the time, before the EURO, when the most important news was, which currency the central bank is buying to hedge against speculation? Or when the dollar dropped, european central banks did "supporting buys" and when the dollar rose, they sold their surplus? There were years where the "Deutsche Bundesbank" made substantial gains by trading foreign currencies. So did all the lucky speculators.
- no longer allowed to meet with stakeholders as needed, must wait for weekly "demo" That is not agile, it is stupid. And all agile methods demand access to the stakeholders. So why are you trolling?
- daily standup that just takes tons of time to say "no change from yesterday because I'm still not allowed to find out what the stakeholders want because it's not Tuesday yet" Trolling again? A standup should not take more than 90 seconds pr person.
- our group is cross functional, so that means that the learning project manager can do development work right? Yes he can. What has that to do with agile, non agile?
- my agile group is only 3 hours a day, strictly scheduled, so I'm only allowed to work on that project for those 3 hours, If that is made clear to every stakeholder, it is fine. What is your problem?
and work on nothing else during that time, EXACTLY. That is called "commitment" and "accountablility"!
nevermind that my projects fluctuate daily in their requirements, it can't... at least your sprint can't. And if you really have to react daily: then for funk sake don't use sprints but Kanaban
and one day I might have 8 hours work for this project, and none for others, but tomorrow it could be the reverse, and with deadlines as tight as they are, I can't afford to twiddle my thumbs because the wrong project has work ready. Ha ha ha. Troll!
A rigid process is good. (But it should be as lightweight as possible - so it does not get into your way and causes overhead) But it does not mean you can not adapt and change it. Worst case: you change it every sprint. AFTER the sprint retrospective. Obviously: if you change it every sprint, you never really can measure if your changes have any effect.
So if Agile is getting in the way, then be dextrous and sidestep it. I often felt that putting points on stories would be the same as committing myself to a promise. So you did not have the guts, to estimate in future more accurately and put more SPs on the stories? Or you did not have the guts to finally accept that you can not make x SP but only 70% and plan your sprint with 30% less points?
You fail. Prime example for not grasping what agile is about. Cheating yourself is not agile.
Agile does not say you don't need a software architecture. Agile says: find good people, educate the others. Hence, you should have a good architect in the team, or grow one.
If you can not craft an architecture in an agile environment, how do you come to the idea you can in a non agile one?
In agile, there are no deadlines. Exactly. There are plenty of software systems that don't need deadlines. Does the linux kernel have a dead line? Does Twitter, Facebook, Google, Pinterest have dead lines? What would be their use? You define a feature, give it a priority, implement it, give the green light, deploy it. You are as fast as you are. No magic makes you faster. Why would you need a deadline for three dozens of "micro services" that gradually get deployed and change the functionality or look and feel of a "web site"?
agile lets you hide that you're nowhere near where you should have been until the very end. And how would that work? You have a magical "burn down graph" that ignores the open tickets in the issue tracker?
If you have issues worth 500 story points open in the issue tracker, but only deliver 20 SP per sprint, and your sprints are 6 weeks, I can quite good estimate that you wont be finished in 3 month. And not in 12 and not in 24.
The only way to hide that, is not telling how many SP you make per sprint, not telling how long your sprint is, not telling how many open issues you have, how many open SP you have: and that is fraud. A crime. Not a "process mistake".
I do Agile projects since roughly 2004 (and did some before 1998). None of them failed.
If you want answers to your problems, I'm glad to answer. But what you ask here is much to unspecific.
But what if it's Agile that made the project too big, the team slow and apparently bad? What is that supposed to mean? How should doing something agile instead of RUP/Waterfall/Spiral make the project bigger?
I've seen Agile metrics make a team to be slow when they were working on some part that appeared no different than others but simply required more thought and care to build. And? What is wrong with that? If you are running your Ferrari over the highway and hit a construction site you have to slow down. What the funk? Obviously you lose velocity. If you don't know WHY you lost it, what has that to do with agile?
I've seen great teams that worked well together look "bad" at times under Agile because over time the system was too rigid to allow for needed infrastructure work, which never got prioritized by the system over which the developers had little input. This is called "technical debt". What has agile to do with it? If you follow a software process and the result is a pile off mess you can not refactor, what the funk has that to do with the process? You made a mistake. You have wrong priorization. What has that to do with the process?
any time there's a failure it was not REALLY agile you were practicing No, any time you encounter failure, you have to look into the mirror and admit: you/someone made a mistake. And agile says: people over process! The people make the mistake. They should learn from it, and if necessary adjust the process.
You sound like a school boy who asks: what is better? Kung Fu or Karate. Then he starts learning Kung Fu and wants to fight and loses every fight against a Karateka. Then he is pissed and switches to Karate, and loses every fight against a Kung Fu guy. Problem is: he is bad in fighting. Does not matter what "school" he is following. If he does not learn how to fight, aka learn how to make successful software projects: he will fail. At least sometimes. And agile means: face it! Draw conclusions from it. If you don't face your failures (sprint failed!), don't do a sprint retrospective (why did it run so bad?), don't have a log of suggested improvements, don't track if you actually implement the improvements (CI/reviews, or what ever), then you are not improving, then you are not learning, then: you are not agile!
The easiest example are external resources that have longer delivery time. Then adjust your sprint length or mock them away till they are ready.
But also internally, if you have to e.g. run a 4 week test for regulatory reasons Then adjust your sprint length. The original recommendation for sprint length in Scrum and in XP is 6 weeks to 12 weeks!!!! Not one week, not two weeks!
or prime a machine learning algorithm with real-time data that happens in a particular time frame. That is usually outside of the sprint, completely irrelevant for ordinary software development.
The agile answer is then "sorry, we cannot commit to this", That is nonsense. The agile answer is: adapt!
Scrum is not a process. Scrum is a meta process. You define your own process inside of the scrum framework. Scrum is not rigid at all, besides the ceremonies and the iterative/sprint approach.
Also having an issue tracker, a decent source code control, continuous integration, working build system, everything automated that takes time or can fail due to human interaction, there are probably a dozen more.
we'd all be drifting that way and things would get better and better, simply because those doing it right would outcompete the others. This is actually what is happening:D
This is not what we observe happening. You don't observe it. I do. Change job to place where it works...
Agile means: you realize after 3 sprints, the project is to big, the team is to slow, the team is to bad. You have sunk three sprints, you can decide if the project is worth it. You can decide if you invest into improving the team. If you are not agile you have spent much more money when you finally admit that you have failed.
That is not short sight. That is checking the map and the heading at the end of each sprint. Just like the pilot or captain on a ship checks every hour its position and makes an entry into the log. The log entry in an agile project is at every sprint end. As an organization you immediately realize if you are sinking money: that is the point!
with the mythical man-month assumptions than enable it. It does not. It does the opposite!! It tells you clearly: you going into a death march and don't do happy sprints: stop and reconsider what you are doing.
Projects get interminably delayed and finally cancelled because they are too big and can't be split into smaller pieces. Everything can be split into smaller pieces. It is called a task that needs to be done. You don't need to make your sprints on the level of a use case, story or subsystem. The question is: does it make sense to split a "milestone" into 100 tasks taking 4h - 16h (in original Scrum a task should not be longer than 2 work days). It might not make sense, because obviously you can not really prioritize them differently. Unless you see synergy effects with other corners in the architecture.
You are somewhat right, though. I guess, some companies simply think to big. They want a whole system, because they can not imagine how to monetize parts of it already.
In the Adriane they assigned a 16bit value to a 32bit variable, or was it a 32bit to 64bit, does not matter. Which lead to an overflow. Ah, it was opposite around, here is a link: https://archive.eiffel.com/doc...
The Mars lander had to convert one unit into an other, but did not. That is obviously an oversight, not language related.
My point is: errors don't show up early necessarily. OpenSSL was buggy for a decade or longer until someone realized it. And the fact that we have such errors have nothing to dow with "is the programmer competent", or "is the programmer lazy".
However they made a bad impact analysis. Bottom line programmers simply rely still much to much on build in data types and their automatic conversion. C++ and operator overloading, cornering in what can be assigned to what, would have had zero overhead and completely made it impossible to assign incompatible types to each other. Both in the Ariane case as in the Mars lander case.
American groups from GE to inspection the safety got regularily silenced. The prime minister who tried to get the atomic industry on track and the governor of the region got silenced and removed from office.
Youtube is full with documentaries about "how the atom industry in japan" is run. However that obviously happened already for years or decades before the actual incident.
You reveal that you don't understand the technical details you are trying to argue by invoking "military grade". Nice that you included helicopters in the story to make it sound impressive. Are you an idiot? They flew in diesel generators from the military with helicopters. Tried to activate the "as you say still working" cooling system: and failed. Hence the hydrogen explosions later. Why do you think I use helicopter and military to sound impressive is beyond me.
"Military grade" doesn't mean magical. No, it means they were provided and flown in by military, obviously. If you recall: the roads where blocked by debris or still under water.
If you don't get a good grade in an unrelated topic in a trade school, no one cares.
If you get a bad grade in a mandatory, but completely unimportant class in university, it reflects on your diploma grade. Would you rather hire one with an A or an B? And how would it influence you if you knew the B was because of unrelated topics? I mean for a highschool diploma in Germany some people pick religion, art and music (or whatever) because they get a guaranteed A in it. Then they go and study some business administration at an university that requires an A in the diploma. What is the point of that? For an BA I would expect two or three foreign languages, math skills and perhaps another science. But certainly I don't care about his gradse in sports or religion.
Actually if you know what you are doing, a pragma might be the exact right thing to do. I don't rewrite comprehensible _correct_ code into a harder to understand variation, just because there is a warning (emphasize on _correct_).
Warnings are warnings, not errors, for a reason. And putting a pragma on top of it means: I have examined the point in question and have decided the code is ok.
Anyway, probably you did not see my smiley in my previous post, so I repeat it;D
Stealth fighters/bombers are mostly stealth from below or for other planes flying similar heights, depending on course ofc. That also means that long range radar guided air to air missiles have trouble to lock on a stealth fighter.
But: they are not so invisible from above, e.g. for an carrier based Hawk Eye or an Land based AWACS.
However I have no clue what range heat guided missiles have and how they lock on at a stealth plane (especially if fired over a long distance)
And don't forget, carriers have their own defenses and a screen of support ships around them. Then again, EXOCETs are extremely effective.
Slashdot Mirror
Eventually features get dropped from a version if they aren't ready.
So what does it mean? Did you make the deadline? Or did you not?
You made "the sprint", and dropped what you could not do. So no: there was no deadline.
Same for the other examples. It is ready when it is ready. A deadline does not change anything about the stuff people have developed before the "point of time" or after it.
All cryptocurrencies are underpinned by the belief that people will trade something of value for them.
Same for fiat currencies.
Or don't you remember the time, before the EURO, when the most important news was, which currency the central bank is buying to hedge against speculation? Or when the dollar dropped, european central banks did "supporting buys" and when the dollar rose, they sold their surplus?
There were years where the "Deutsche Bundesbank" made substantial gains by trading foreign currencies.
So did all the lucky speculators.
Is that a kind of provocation?
- no longer allowed to meet with stakeholders as needed, must wait for weekly "demo"
That is not agile, it is stupid. And all agile methods demand access to the stakeholders. So why are you trolling?
- daily standup that just takes tons of time to say "no change from yesterday because I'm still not allowed to find out what the stakeholders want because it's not Tuesday yet"
Trolling again? A standup should not take more than 90 seconds pr person.
- our group is cross functional, so that means that the learning project manager can do development work right?
Yes he can. What has that to do with agile, non agile?
- my agile group is only 3 hours a day, strictly scheduled, so I'm only allowed to work on that project for those 3 hours,
If that is made clear to every stakeholder, it is fine. What is your problem?
and work on nothing else during that time,
EXACTLY. That is called "commitment" and "accountablility"!
nevermind that my projects fluctuate daily in their requirements, ... at least your sprint can't. And if you really have to react daily: then for funk sake don't use sprints but Kanaban
it can't
and one day I might have 8 hours work for this project, and none for others, but tomorrow it could be the reverse, and with deadlines as tight as they are, I can't afford to twiddle my thumbs because the wrong project has work ready.
Ha ha ha. Troll!
I simply commit and continue working.
The CI server is running the tests.
Why should I waste time running tests on my machine?
A rigid process is good. (But it should be as lightweight as possible - so it does not get into your way and causes overhead)
But it does not mean you can not adapt and change it.
Worst case: you change it every sprint. AFTER the sprint retrospective.
Obviously: if you change it every sprint, you never really can measure if your changes have any effect.
So if Agile is getting in the way, then be dextrous and sidestep it.
I often felt that putting points on stories would be the same as committing myself to a promise.
So you did not have the guts, to estimate in future more accurately and put more SPs on the stories?
Or you did not have the guts to finally accept that you can not make x SP but only 70% and plan your sprint with 30% less points?
You fail. Prime example for not grasping what agile is about. Cheating yourself is not agile.
Agile does not say you don't need a software architecture.
Agile says: find good people, educate the others.
Hence, you should have a good architect in the team, or grow one.
If you can not craft an architecture in an agile environment, how do you come to the idea you can in a non agile one?
In agile, there are no deadlines.
Exactly.
There are plenty of software systems that don't need deadlines. Does the linux kernel have a dead line? Does Twitter, Facebook, Google, Pinterest have dead lines? What would be their use? You define a feature, give it a priority, implement it, give the green light, deploy it. You are as fast as you are. No magic makes you faster. Why would you need a deadline for three dozens of "micro services" that gradually get deployed and change the functionality or look and feel of a "web site"?
agile lets you hide that you're nowhere near where you should have been until the very end.
And how would that work?
You have a magical "burn down graph" that ignores the open tickets in the issue tracker?
If you have issues worth 500 story points open in the issue tracker, but only deliver 20 SP per sprint, and your sprints are 6 weeks, I can quite good estimate that you wont be finished in 3 month. And not in 12 and not in 24.
The only way to hide that, is not telling how many SP you make per sprint, not telling how long your sprint is, not telling how many open issues you have, how many open SP you have: and that is fraud. A crime. Not a "process mistake".
I do Agile projects since roughly 2004 (and did some before 1998).
None of them failed.
If you want answers to your problems, I'm glad to answer. But what you ask here is much to unspecific.
But what if it's Agile that made the project too big, the team slow and apparently bad?
What is that supposed to mean? How should doing something agile instead of RUP/Waterfall/Spiral make the project bigger?
I've seen Agile metrics make a team to be slow when they were working on some part that appeared no different than others but simply required more thought and care to build.
And? What is wrong with that? If you are running your Ferrari over the highway and hit a construction site you have to slow down. What the funk? Obviously you lose velocity. If you don't know WHY you lost it, what has that to do with agile?
I've seen great teams that worked well together look "bad" at times under Agile because over time the system was too rigid to allow for needed infrastructure work, which never got prioritized by the system over which the developers had little input.
This is called "technical debt". What has agile to do with it? If you follow a software process and the result is a pile off mess you can not refactor, what the funk has that to do with the process? You made a mistake. You have wrong priorization. What has that to do with the process?
any time there's a failure it was not REALLY agile you were practicing
No, any time you encounter failure, you have to look into the mirror and admit: you/someone made a mistake. And agile says: people over process! The people make the mistake. They should learn from it, and if necessary adjust the process.
You sound like a school boy who asks: what is better? Kung Fu or Karate. Then he starts learning Kung Fu and wants to fight and loses every fight against a Karateka. Then he is pissed and switches to Karate, and loses every fight against a Kung Fu guy. Problem is: he is bad in fighting. Does not matter what "school" he is following. If he does not learn how to fight, aka learn how to make successful software projects: he will fail. At least sometimes. And agile means: face it! Draw conclusions from it. If you don't face your failures (sprint failed!), don't do a sprint retrospective (why did it run so bad?), don't have a log of suggested improvements, don't track if you actually implement the improvements (CI/reviews, or what ever), then you are not improving, then you are not learning, then: you are not agile!
Then perhaps your spring length is wrong?
areth, with all respect, you are wrong.
The easiest example are external resources that have longer delivery time.
Then adjust your sprint length or mock them away till they are ready.
But also internally, if you have to e.g. run a 4 week test for regulatory reasons
Then adjust your sprint length. The original recommendation for sprint length in Scrum and in XP is 6 weeks to 12 weeks!!!!
Not one week, not two weeks!
or prime a machine learning algorithm with real-time data that happens in a particular time frame.
That is usually outside of the sprint, completely irrelevant for ordinary software development.
The agile answer is then "sorry, we cannot commit to this",
That is nonsense. The agile answer is: adapt!
Scrum is not a process.
Scrum is a meta process. You define your own process inside of the scrum framework.
Scrum is not rigid at all, besides the ceremonies and the iterative/sprint approach.
Well,
if they are dead and are lying around on the ground, they are food for their offsprings.
Also having an issue tracker, a decent source code control, continuous integration, working build system, everything automated that takes time or can fail due to human interaction, there are probably a dozen more.
FBF is probably the most important.
we'd all be drifting that way and things would get better and better, simply because those doing it right would outcompete the others. :D
This is actually what is happening
This is not what we observe happening. ...
You don't observe it. I do. Change job to place where it works
You got it completely reversed.
Agile means: you realize after 3 sprints, the project is to big, the team is to slow, the team is to bad. You have sunk three sprints, you can decide if the project is worth it. You can decide if you invest into improving the team. If you are not agile you have spent much more money when you finally admit that you have failed.
That is not short sight. That is checking the map and the heading at the end of each sprint. Just like the pilot or captain on a ship checks every hour its position and makes an entry into the log. The log entry in an agile project is at every sprint end. As an organization you immediately realize if you are sinking money: that is the point!
with the mythical man-month assumptions than enable it.
It does not. It does the opposite!! It tells you clearly: you going into a death march and don't do happy sprints: stop and reconsider what you are doing.
No idea how you can get "agile" so wrong.
Projects get interminably delayed and finally cancelled because they are too big and can't be split into smaller pieces.
Everything can be split into smaller pieces. It is called a task that needs to be done. You don't need to make your sprints on the level of a use case, story or subsystem.
The question is: does it make sense to split a "milestone" into 100 tasks taking 4h - 16h (in original Scrum a task should not be longer than 2 work days). It might not make sense, because obviously you can not really prioritize them differently. Unless you see synergy effects with other corners in the architecture.
You are somewhat right, though. I guess, some companies simply think to big. They want a whole system, because they can not imagine how to monetize parts of it already.
Both are coding problems.
In the Adriane they assigned a 16bit value to a 32bit variable, or was it a 32bit to 64bit, does not matter. Which lead to an overflow. Ah, it was opposite around, here is a link: https://archive.eiffel.com/doc...
The Mars lander had to convert one unit into an other, but did not. That is obviously an oversight, not language related.
My point is: errors don't show up early necessarily. OpenSSL was buggy for a decade or longer until someone realized it. And the fact that we have such errors have nothing to dow with "is the programmer competent", or "is the programmer lazy".
However they made a bad impact analysis. Bottom line programmers simply rely still much to much on build in data types and their automatic conversion. C++ and operator overloading, cornering in what can be assigned to what, would have had zero overhead and completely made it impossible to assign incompatible types to each other. Both in the Ariane case as in the Mars lander case.
How do you mean that?
I don't understand it. If you pay taxes and don't need a health insurance, obviously it is 100% public.
Actually there is a "conspiracy".
American groups from GE to inspection the safety got regularily silenced. The prime minister who tried to get the atomic industry on track and the governor of the region got silenced and removed from office.
Youtube is full with documentaries about "how the atom industry in japan" is run. However that obviously happened already for years or decades before the actual incident.
You reveal that you don't understand the technical details you are trying to argue by invoking "military grade". Nice that you included helicopters in the story to make it sound impressive.
Are you an idiot? They flew in diesel generators from the military with helicopters. Tried to activate the "as you say still working" cooling system: and failed. Hence the hydrogen explosions later. Why do you think I use helicopter and military to sound impressive is beyond me.
"Military grade" doesn't mean magical. No, it means they were provided and flown in by military, obviously. If you recall: the roads where blocked by debris or still under water.
And?
If you don't get a good grade in an unrelated topic in a trade school, no one cares.
If you get a bad grade in a mandatory, but completely unimportant class in university, it reflects on your diploma grade. Would you rather hire one with an A or an B? And how would it influence you if you knew the B was because of unrelated topics? I mean for a highschool diploma in Germany some people pick religion, art and music (or whatever) because they get a guaranteed A in it. Then they go and study some business administration at an university that requires an A in the diploma. What is the point of that? For an BA I would expect two or three foreign languages, math skills and perhaps another science. But certainly I don't care about his gradse in sports or religion.
So you don't have healthcare included in the taxes like the danish and the other nordics?
I hope you did not mean a firing squad?!!
Actually if you know what you are doing, a pragma might be the exact right thing to do. I don't rewrite comprehensible _correct_ code into a harder to understand variation, just because there is a warning (emphasize on _correct_).
Warnings are warnings, not errors, for a reason. And putting a pragma on top of it means: I have examined the point in question and have decided the code is ok.
Anyway, probably you did not see my smiley in my previous post, so I repeat it ;D
Easy to imagine. Difficult to pull off.
Stealth fighters/bombers are mostly stealth from below or for other planes flying similar heights, depending on course ofc. That also means that long range radar guided air to air missiles have trouble to lock on a stealth fighter.
But: they are not so invisible from above, e.g. for an carrier based Hawk Eye or an Land based AWACS.
However I have no clue what range heat guided missiles have and how they lock on at a stealth plane (especially if fired over a long distance)
And don't forget, carriers have their own defenses and a screen of support ships around them. Then again, EXOCETs are extremely effective.