Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment: Re:*shrug* (Score 5, Insightful) 246

by turbidostato (#49757623) Attached to: 25 Years Today - Windows 3.0

"IBM's PC strategy from the mid '80s to mid '90s could be summed up as using their influence to prevent networking, multi-tasking and file permissions from happening on the same platform at the same time."

Of course yes.

That explains why in the mid '80s to mid 90's IBM was busy in a joint venture with Microsoft first and alone afterwards... to produce a PC system with networking, multi-tasking and file permissions and even 32 bits (OS/2).

Or maybe you are wrong.

Comment: Re:Do people really take this risk seriously? (Score 1) 218

by turbidostato (#49755749) Attached to: Asteroid Risk Greatly Overestimated By Almost Everyone

"An ELE shows up about every 60 million years. If it kills 6 billion people, then that is on average 100 people per year, which is small, but still much larger than they imply."

It would directly kill those 6 billion but then, it would stop humanity from growing at least 25x that number (provided it takes 25 generations to rise back to 6 billions and that 6 billions is more or less the max capacity of the Earth). This would mean -as per your numbers, about 2500 people/year, and that is without taking into account the life standars for the survivors or if it doesn't manage to extinguish the species altogether.

Comment: Re:Is Agile Development a Failing Concept? (Score 1) 507

by turbidostato (#49704635) Attached to: Is Agile Development a Failing Concept?

Yes.

Again a case of "methodology X" failing at delivering the expected but shinning at surfacing your company's misfunctions.

Agile, being about "Individuals and interactions over processes and tools" is specially good at that.
The paradox is that sane companies would react at all that revealed insanity and would take the chance to correct themselves, which the only thing it's impossible to be done in the companies that show this kind of insanity.

Comment: Re:Is Agile Development a Failing Concept? (Score 1) 507

by turbidostato (#49695595) Attached to: Is Agile Development a Failing Concept?

"By definition, if can't fit into a single Sprint, then you cannot do it"

That's right.

But it works both ways: if there are things that cannot be fitted into a sprint, your sprints are too short.

Nobody is telling that a sprint have to be two weeks long. Sprints should be as long or short as to be able to accomodate a significant result. Sometimes this means one week, sometimes three months, sometimes this needs to change from sprint to sprint or at least to product-livecycle phase to phase. The only requirement is for the sprint's duration to be fixed beforehand.

"The report is required to be done by Dec 1"

That's an OK bussiness need -at least, when it really is a bussiness need and not just a date to add pressure to your team, but one that some if not most of agile *methodologies* (no a problem with agilism by itself) can cope with.

This only means that most probably this single request needs to be handed in a custom way: if the feature set is clear and fixed (and it probably is) even the charicaturesque version of waterfall-as-an-antipattern can perfectly work: you get the requirements, design the solution, asign a team for the expected time, test and deliver. I don't see what the problem can be with that -except, maybe, that the team needs to come from somewhere, probably the same team doing everything else, which would mean, say, no sprints for the next month, or a negotiation to push forward stories that don't requiere to be delivered by the people now reassigned to the report and if that's really the problem you are again failing on agilism, since one of its tenets is "Customer collaboration over contract negotiation": obviously, putting people to do "this" makes it impossible for that people doing "that" at the same time, so the customer needs to make up his priorities, or the team to be expanded at the risk of falling in "the mithycal man-month" trap.

"Our board has directed that we are required to do Agile, and the certified scrum master they hired wouldn't let us start on the report."

You see, "scrum" is not "agile" but an "agile methodology". Your "scrum master" looks to me more of a "scumbag master" than anything else, since he failed twofold:
1) Within scrum, "The Scrum Master serves as a facilitator for both the Product Owner and the team", which he obviously failed to be.
2) In the overall context of agilism: being scrum an *agile* methodology is naturally driven by agilism first, and that means "Working software" as well as "Responding to change" and he failed in both fields.

Comment: Re:No. (Score 1) 507

by turbidostato (#49695443) Attached to: Is Agile Development a Failing Concept?

"Oh, don't let the devs add their own bugs or issues. Otherwise it will turn out that they have only been working on the tasks that they created internally."

Agree on that. At the very least, a developer-opened task would have to be agreed first with the customer or even created by the customer himself upon the developer's request.

"I came back 6 months later once only to find out..."

Your fail. If you had come back two weeks later instead of 6 months, you would have found much earlier. You know, "agile" is a burden for the customer as much as for the developer. You can't have "agile" without both of them.

Comment: Re:No. (Score 1) 507

by turbidostato (#49695423) Attached to: Is Agile Development a Failing Concept?

"the bugtracker agile system."

You yourself say it afterwards: just call it "the issue tracker system" and you are done.

And, yes, it probably would work better than the average "agile in the forms, old school everywhere else" because, since most of the problems about agile come from people and culture clashes than anything else, having a simple and easily understandable means to produce a queue and track its evolution makes for a perfect start point that it is certainly fully aligned with the "agile manifesto".

Taking the first day's morning to explain the customer what "agile" entails, specially for him -and agree with him on doing it that way (or not, but then you are fred to go waterfall or anything else that better suits the scenario), and the evening to explain both customer and the internal team what DONE means, and a Redmine site for tracking customer-opened issues and the internal team-produced documentation should be more than enough on most cases.

But this is just too cheap and logical to gain traction.

Comment: Re:No. (Score 1) 507

by turbidostato (#49695371) Attached to: Is Agile Development a Failing Concept?

"I end up being unable to do the tasks (stories) assigned during the development period (sprint)"

Bzzzt! Error!

Stories are not *assigned* to the sprint, they are *queued* for the sprint. It might look like splitting hairs, but it's far from that.

Part of the reason d'etre of agilims is that you don't have a crystal ball to see the future. Maybe your team's velocity is not well stablished, maybe you missed the complexity of the task... when planning a sprint you are not *commiting* to complete, say, these five stories, but agreing with your customer that these 1, 2, 3, 4, 5, 6, 7... stories are the most interesting right now and in that order, and that given your current knowledge about yours and your team's abilities and the complexity of the stories at hand you *probably* will be able to fulfill 1,2,3,4 and 5 of them by the end of current sprint.

Once again, the old problem: agile "processes" put on top of the old mentality -like trying those new dancing steps from charleston over the same old waltz. Funny results guaranteed!

Comment: Re:No. (Score 1) 507

by turbidostato (#49695295) Attached to: Is Agile Development a Failing Concept?

"The real truth is that there are developers of different skills, and there are some that excel in specific areas while the rest plod along, and they are not interchangeable like Agile states"

Wait... what!?

You obviously don't know what you are talking about.

Why do you think "velocity" is not interchangeable and it is instead tied to a given group if people were interchangeable? Why do you think "velocity" evolution needs to be referenced just to a given team's history if it could be stated in advance?

"Individuals and interactions over processes and tools" is the first basic tenet of agilism. Why do you think "individuals" is the very first word of it if people were interchangeable and, thus, out of consideration?

Comment: Re:No. (Score 1) 507

by turbidostato (#49695259) Attached to: Is Agile Development a Failing Concept?

"See? None of these involves requirement changing. How you can do waterfall in large projects worth millions is beyond my imagination..."

I see your point but I can't see its relationship with anything agile vs waterfall here. Nothing you talk is about your application's functional requirements so it doesn't even enter the agile realm.

Comment: Re:No. (Score 1) 507

by turbidostato (#49695225) Attached to: Is Agile Development a Failing Concept?

"There is nothing about waterfall that requires you to make ironclad decisions at the very start"

Of course there is. Once the requirements phase is closed, it is closed. You can have iterative waterfall, but you need to wait for next iteration to alter requirements. You can have overlapping waterfall, but overlapping shouldn't make more than 10-20% of your gantt, and even then, at the cost of increasing at least on the same proportion your allowed cost/deadlines variances. In fact, the only guarantee for deliverability on waterfall comes from the fact that when a phase is closed, it's closed and you can't go back to it, which would add uncertainty to the process.

"The difference that I've seen in practice is that it's incredibly hard to implement Agile correctly"

It is, but that's the case because of the way companies are organized since Ford days: hierarchies, functional and responsability clear niches and boundaries, processes and bureaucracy, while agilism is about team playing, empowering people, planitude and results over processes and paper trails.

Agilism looks hard for too many companies the same way chess looks hard when you try to play it on a tennis field and with tennis rules.

Comment: Re:No. (Score 1) 507

by turbidostato (#49695157) Attached to: Is Agile Development a Failing Concept?

"You are basically just saying that agile is more *fr*agile than waterfall"

It is, but then you need to add context to see what that really means.

Agile was always about empowering people over process and bureaucracy. If you are process and paper trail centered you are not doing agile. Full stop. Please, take your time to rumiate this.

Now let's imagine you really are embracing agile and let's think about your team's members (not only developers but management and even customers): is it really advantageous to empower them? Or is it like giving a loaded gun to a monkey? For one obvious thing, taken right from the agile manifesto "Customer collaboration over contract negotiation", will your customer abide to collaborate or will he want a full contract with all things strongly tied -costs, deadlines, features... by day one? Because if it's the latter, you can forget about agile right on the starting line, you see...

Now, on waterfall: of course it is more solid and efficient than agile... provided the customer (be it internal or external) perfectly understands his needs, is perfectly able to transmit them, their needs are perfectly understood and expressed formally on paper, they are agreed back by customer and you have an experienced enough team all across without a hidden agenda.

Failing anything in the list above, waterfall not only tends to quickly fall apart, but doing so in very expensive and notorious ways that agile mentality (in any of its incarnations) provide checks and balances against (but first you need to take the time to understand what is all this stuff about).

Now that I reread what I wrote, find it similar to the republic ideal: it works because its checks and balances, but obviously they only add more moving parts (thus fragility) and unefficiencies... if only everything worked as hoped.

If it's working, the diagnostics say it's fine. If it's not working, the diagnostics say it's fine. - A proposed addition to rules for realtime programming

Working...