Playing Politics With Agile Projects (cio.com) 145
A harsh perspective on agile software development, shared by Slashdot reader itwbennett: Politicians would be utter failures as agile project managers, writes David Taber, and for all the reasons you might imagine, but mainly because they wantonly make promises they have no hope or thought of keeping. But then he gets into the political attributes successful project managers need. And that's where things get interesting because, while he points out that agile was 'conceived of as a way of bypassing bureaucracy and internal politics,' the attributes he says are required for success are pretty much the worst of the political behavior we've all witnessed in our organizations.
For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"
For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."
His submission ends with this question. "Is it any wonder why users hate agile?"
FrAgile (Score:1, Insightful)
I am a software dev of many years and now a software dev manager on top of that (still do dev work). Agile has got to go. Developers think that because they're programmers, they're special and deadlines don't apply to them.
The prototypical case against waterfall is BS, by the way. Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work, works extremely well.
Also, and this is THE KEY reason that I'll never accept agi
Re: (Score:3)
Different development methodologies are appropriate for different projects. One size does not fit all.
Re: (Score:1)
That's sort of true. There are two possibilities (and of course shades of grey between them.. but that can be decomposed into separate bits with these characteristics)
a) you are doing something that has been done before
b) you are doing something new
In case a) then what you are doing is really IT. You will find that waterfall may well work okay as long as you can stick in this region. Unsurprisingly, lots of IT projects go horribly wrong because they fall over into b) for some small part of the project wh
Re:FrAgile (Score:5, Insightful)
Waterfall doesn't have analysis and planning phases?
You're just wrong, waterfall handles 'honestly new' just fine. Virtually every piece of software used was built with waterfall.
What it doesn't handle is 'constantly shifting demands', but agile doesn't handle that at all well either, nothing does. If the customer doesn't understand the problem, you have an analysis problem, no methodology will solve it.
If the problem changes faster than you can release, the best move is not to automate that part until it settles down.
Agile is just waterfall with all the roles and phases renamed and with a fixed, very rapid, iteration cycle.
Re: (Score:3)
I thought that, and then I thought "surely there's more to it, or why is everyone talking about it?"
And then I figured technology is as prone to hemline oscillation and varying tie widths as the clothing industry.
Re: (Score:3)
You really really don't want some SCRUM team messing around with those.
And yes, Agile is superior
Re: (Score:2)
Typically the planning phase comes before a contract signing or something
That's the giant failure right there. Essentially that work is done speculatively and for free. This means it's goal is to get the contract signed even though it is supposed to be get the software designed. Anything not directly contributing to getting the contract signed will be half-assed at best. Then once the contract is signed, since the analysis and design is "done", everyone jumps into coding to a woefully inadequate design and it devolves to cowboy coding.
Re: (Score:2)
Except that's not how it works. Nobody, not even beltway bandits, can afford to do the analysis for free. If they don't know what exactly their problem is, the contract is time and materials. With milestones around completing the design.
Re: (Score:1)
You don't sit there 'imagining software'. You sit with the client staff, examining their current process and sort 'essential' things from 'things they've always done that way'. More often than not you have to learn a bunch of stuff about the industry. Then you have to understand what about the process is currently broken and how a computer will fix that.
Have you ever worked on a commercial software project?
The agile manifesto is a pretty useless collection of platitudes. To deliver working software in
Re: (Score:1)
You don't sit there 'imagining software'. You sit with the client staff, examining their current process and sort 'essential' things from 'things they've always done that way'. More often than not you have to learn a bunch of stuff about the industry. Then you have to understand what about the process is currently broken and how a computer will fix that .
Or in other words you "imagine" software and how it will fix their problems. You certainly, from what you have described, don't create it and test it. More or less the only difference between that and agile is that in agile you try to actually deliver a simplified version of that software quickly and see if it actually does help solve the problem as expected. This is similar to, but different in important ways, the old idea of delivering a prototype version of the software.
Have you ever worked on a commercial software project?
The agile manifesto is a pretty useless collection of platitudes. To deliver working software in the real world, you have to follow old fashioned waterfall steps like 'testing'.
If you are doing "testing" as a
Re: (Score:1)
Understanding the problem IS a separate step. If you build a prototype, you still have to think through the flow before you start, even if it turns out you were wrong, you don't just start blindly coding.
If you think it's possible to 'completely automate' testing you are smoking crack. Unit testing is great, but always incomplete. Scripted tests typically only find recurrence of problems or at best problems that were already thought about. Those aren't the ones that really fuck schedules.
I've worked te
Re: (Score:2)
I know a dude who makes really good money by breaking consumer products. He's just really good at 'being an idiot' and finding ways that consumers could break prototypes.
UI testing just can't be automated, (just the 'correct' tab order for controls is tricky). Testing for conditions not in the test cases can't be automated until they are found. Test datasets grow with time due to human intervention.
It's always the tricky, poorly thought out edge case that blows your schedule. They are mostly found by h
Re: (Score:2)
One further thing.
In waterfall (as practiced), when a design flaw is identified the process goes back one or two steps to design/analysis before dropping back to coding. You aren't forced to code to release before updating design (just as you constantly go back to coding from testing). In a working group, those 'formal steps' are just within the team, but do generate updated design documents.
Re:FrAgile (Score:4, Insightful)
It's all iteration. Waterfall is a special case where the iteration count is one. Agile is a special case where the iterations are arbitrarily short. In some of the most successful projects, the length of an iteration is determined informally in the planning phase based on logical stopping points. The rest is largely window dressing based on the principle that all teams and all programmers are exactly alike.
Managers (especially the MBAs that have never programmed) tend to like waterfall and Agile because it lets them stick to hard fast rules. Managers that came up through the ranks and kept current will be more open to variable iteration.
Re: (Score:2)
Waterfall is a special case where the iteration count is one.
That isn't actually true, it is just an assertion by the anti-waterfall people that usually goes unchallenged.
Even the canonical waterfall project, engineering a structural bridge, contains multiple planning iterations before getting to the implementation. The iteration of the whole project is one, but that is true for agile too; if you ever accidentally implement all the requirements, you've finished. The only "iteration count" that is "one" is one in both situations; there is one overall project that some
Re: (Score:2)
Re: (Score:1)
I think you mostly think of cases where software, and sale of a "finished" product is what you are working on.
A lot of people work more in areas where software is a support role, where what your software needs to do changes with the problem the main business is facing just now etc. (and there is no sales involved anywhere, and your users are sitting in the office down the hallway).
In one case, you produce a reasonable product and your users and who exactly buys your product will adjust as long as you produc
The eternal meetings... (Score:2, Interesting)
My problem with Agile is the stand up meetings. I have been at places where they go for 2-3 hours a day, with people doing little each day, and using "Wah, I'm blocked" as a way to blamestorm and shift responsibilities to other parties. I could be doing a -lot- more with my time than hearing some other person talk about their stuff, what they did today in detail, down to how many times the HANA developer shook her weewee in the restroom, what their aspirations are tomorrow, and "what have you done tomorro
Re: (Score:2)
I have been at places where they go for 2-3 hours a day, with people doing little each day, and using "Wah, I'm blocked" as a way to blamestorm and shift responsibilities to other parties.
Then you're doing it wrong. Our company is officially agile (though really it's more like waterfall with daily status meetings), and the meetings rarely last more than 15 minutes. If person A says they're blocked waiting for person or team B to do something, we can normally trust them to sort it out themselves. Sometimes the scrum master will set up a meeting of just A and B (plus himself, to keep them honest), and then report the outcome of that to the rest of the team at the next stand-up meeting.
To be fa
Re: (Score:2)
That's what always saves Agile. If you have problems, it means you're not doing True Agile.
It can easily leave onlookers thinking that Agile isn't very agile. Maybe it is just too hard to be practicable?
Re: (Score:2)
You could say that about a lot of things, but yes, Agile does seem to have more than its share of "you're doing it wrong."
The notion that if you have a fixed release date, you should sacrifice features for quality, seems counterintuitive to many. It's much easier for a sales or marketing person to say, "Our next release will be on this date and have these features," (and leave unsaid, "But we have no idea how good any of them will be.") than it is to say, "Our next release will be on this date, and we don't
Re: (Score:2)
I'm going to suggest that more people get Agile wrong than get a lot of other things wrong. One thing that hurts Agile is that it's fully buzzword-compliant nowadays, which means that it's a lot more tempting to have some sort-of ill-defined process and call it Agile than to call it Waterfall. Moreover, the Agile Manifesto doesn't translate well into typical management-speak, and the whole concept is not really well-defined.
Re: (Score:2)
Good points. It sounds, then, as though the majority of people who are doing Agile wrong will only stop doing it wrong when the next shiny buzzword-compliant methodology comes along, leaving the ones who were doing it right still doing it.
Re: (Score:2)
True. Fortunately we haven't found it necessary to limit an individual's speaking time - we just accept that some will be terse and some will be verbose, and it usually averages out. I sometimes deputise for our scrum master, and when I send him a report of the meeting, it's very rare that anyone gets more than one line, no matter how much they said.
Re: (Score:2)
You used past tense, so I hope you're no longer at such a place. Even so...
Holy crap... hours? Did they realize the entire point of making the meeting "stand up" is to encourage people to keep the meetings extremely brief? Did they actually *stand* through those entire meetings? I hate the kindergarten mentality behind it, but I'm all for keeping meetings as short as possible. If a team can't even get that right, then no methodology is going to help. It's critical to keep the number of participants do
Re: (Score:2)
I've been in meetings where it started going that way, and the boss suggested (i.e. told us, but nicely) to sort it out later among ourselves.
"Shall we report back?"
"To me when you're done, short summary to the group next week."
And then we finished the rest of the agenda and went to the pub.
Half agree (Score:3, Insightful)
I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid. Over the medium to long term, without a plan you end up either doing work and then throwing it out three months later, or constantly working around earlier decisions, ending up with a system full of duct tape hacks. That creates unreliable systems that are difficult and expensive to maintain.
Artificial deadlines are just as problematic, however. Properly designing and building a system with
Re: (Score:2, Interesting)
I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid.
So I'm going to AC this one... at work we're doing a project where 2.5 years out of 3 has been dicking around with the spec. Or rather creating lots of wordy documents, fancy presentations, flowcharts and magic boxes that supposedly solve problems. No developers were involved, because we were not in the development phase. The first month of the "development" project I spent ripping the spec apart saying we need design choices, not vague descriptions of many ways to accomplish the same thing like data acquis
Re: (Score:2)
You talk about throwing work away as though it's a bad thing. My experience tells me that the first version of any complex piece of software or software component you try to create is going to be garbage anyhow. Maybe it would be better to count on calling your first try a prototype, learn the hard lessons about what doesn't work and why, and then scrap as much of it as you need and write version two with the lessons you gleaned from the prototype.
The problem with detailed planning is that there's simply
Re: (Score:2)
You talk about throwing work away as though it's a bad thing. My experience tells me that the first version of any complex piece of software or software component you try to create is going to be garbage anyhow. Maybe it would be better to count on calling your first try a prototype, learn the hard lessons about what doesn't work and why, and then scrap as much of it as you need and write version two with the lessons you gleaned from the prototype.
In my experience, this never goes down well with management. The expensive development team has spent the last four weeks doing something that now will be thrown out and redone. All in the name of "quality" that the client will never appreciate (or indeed know about) in the short term. Not to mention the deadlines on which the upper management signed off on to the client. Really, the management will rather ship mostly working "garbage" now and meet the deadline, rather than spend the time to throw out the p
Re: (Score:2)
All in the name of "quality" that the client will never appreciate (or indeed know about)
This is the difference between having a client, and being a professional. It is easy for consultants to become sleazy, because the incentives are often misaligned due to the pricing structure.
This is why it is better to have employees writing software. They won't save money by writing something that sucks, they'll just have to fix it. They'll plan to throw the first idea away, and they'll talk about it as a prototype from the start. It will be part of the original plan do testing and additional planning bef
Re: (Score:2)
On the largest agile project I've been involved with, we started by refactoring some pretty basic elements of the system. ("We have A, B, and C, which we're special-casing in the main code. Now you want to add D. We're going to pull a lot of that stuff out, make a class that knows this sort of things, and we'll have subclasses for A, B, C, and D.") It worked great, and had management approval.
I like working here.
(We kept adding on E, F, and G, and split A and B into two. If we hadn't done the refa
Two approaches to learning requirements (Score:3)
> it is impossible to find out the full requirements before you have tried putting out some code.
>... emphasis on the word "full"
You may never fully understand all of the users' needs and desires. There are three approaches to handling that:
A) Ask the user's manager what the requirements are.
B) Walk over to the user's desk and watch them work for 30 minutes, asking questions.
C) Guess, then build the minimum thing that might address some of the requirements.
It's well known that option (a) doesn't work
Re: (Score:2)
Or, if you know you don't owe anything, you can file whenever the hell you want, because there is no penalty. (The fine for late filing is a percentage of the taxes owed.)
Re: (Score:2)
Silly question - why don't they stagger them through the year, by something like birth/founding date?
Re: (Score:2)
The problem is that in waterfall both the requirements and the timeframes are set by product owners and sales, with developer estimates of the time needed being ignored. Which is what results in developers getting fed up and deciding that "I'm willing to be accountable for meeting my estimates, meeting your estimates is your problem".
As far as having no product vision or plan, reality is that you can have a very solid product vision and plan and it'll still turn out part-way through that your customers simp
Re: (Score:3)
That's not waterfall. That's 'off the cliff'.
Re: (Score:2)
When I was a consultant, I always set the estimates of the time it would require. That was part of the bid. There is no client time requirement, the client requires an estimate as part of the bid and they will select a bid. In waterfall, the bid is likely to include multiple planning steps and be a full-price realistic bid, and it may even quote a total project cost. In Agile, the price is per week, and there are simply no promises or "quotes" allowed to be made about an overall project. Planning is also by
Re: (Score:1)
"Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work"
Thank you for identifying your preferred work style as Agile, or more particularly Scrum, where each of your "short waterfalls" is a Sprint, Product Owners and Sales are Chickens and your developer estimates are applied to all work based on both consensus and prior work (they give away those decks of cards for a reason)
You are either a magnificent troll or clu
Re: (Score:2)
Re: (Score:3)
Actually I've been reading through a lot of Agile consultant training lately (had to go to the training myself, too), and I see a clear divide. Some of them are fo
Re: (Score:2)
According to this classic, you just need to make estimates, and measure results, and then you can normalize the values and make good predictions of actual time.
http://www.joelonsoftware.com/... [joelonsoftware.com]
Re: (Score:2)
Re: (Score:2)
The estimates end up within tolerance.
Worse than that, I finish at exactly the end of the given tolerance!
Re: (Score:1)
You realize you pretty much just defined what agile recommends... right?
So you're agreed: agile works very well. Why would you then state "Agile has got to go"?
Agile was just terribly named (Score:2)
Talking - Yes, both sides (the person that wants the work and the one doing the work) really need to talk to each other regularly so we don't have somebody going off for 6 months and coming up with something nobody wants. (That also mean
Re: (Score:2)
As somebody who worked in agile projects:
The good side:
* If the customer had no f*****n idea what they wanted, at least they could not act like they had and the failure was due to the dev team.
The bad side:
* Instead of taking complicated issues seriously, settling to a well-defined and engineered solution, writing hundred times a variant of "hello world" was the preferred way of presenting user stories to the customer because then "we have something to show in the end of the sprint". This was going so far t
Re: (Score:2)
YOU DON'T JUST RUN A BUSINESS SUCCESSFULLY BY THROWING SHIT AT THE WALL AND SEEING WHAT STICKS
How do you think the rest of companies operate? Large companies like Ford, GM, VW, etc do that all the time. New engine emissions requirements? Run 5 programs in parallel until one of them works. (Or in VW's case, fake it and try to make it)
Re: (Score:1)
Re: (Score:2)
YOU HAVE NO PRODUCT VISION OR PLAN. YOU DON'T JUST RUN A BUSINESS SUCCESSFULLY BY THROWING SHIT AT THE WALL AND SEEING WHAT STICKS.
You miss the point of Agile. The point is, the developer is a contractor. The client companies are all run by Pointy-Haired Bosses. They have no product vision or plan . Agile is a system for the contractor to prevent that from getting in the way of the contracting. They can throw whatever at the wall they want, they're paying for it.
As a longtime software developer, this is why I am not a contractor anymore. Real products that are part of a vision... need the same "modified waterfall" that was being used
Re: (Score:1)
The "agile development methodology" is nothing but a farce and a cover-my-ass strategy for incompetent software and engineering practices. Throughout my career in information technology I has always used a test-driven approach coupled with proper analysis and design beforehand. If any manager or coworker ever told me Agile must be used for a project I would ignore them and get back to productive work.
Test Driven Development is part of XP - Extreme Programming which is the archetypal agile methodology. It sounds like you are being told to use Scrum, but with the person telling you not knowing the difference between Scrum and Agile. Scrum was actually developed before and separately from Agile. XP was the first Agile methodology. Only later did people start to confuse Scrum with Agile (since the Scrum people wanted to get on the Agile bandwagon).
Re: (Score:2)
When well done, Scrum can be Agile. You do have to take the process less seriously than I've seen in some places.
better idea (Score:2)
how about managers stop playing games and start treating their teams as people rather than "assets".
Re: (Score:1)
"Our office employs only the most beautiful programmers with plentiful assets. Your interaction with our programmers will be a highly enjoyable experience." --ISV marketing after the software industry specific AI singularity.
What is needed: kill competing projects (Score:1)
Observation from an orginization that "moved to the cloud"
Developers and managers flock to solve the easy problems
There are far too many projects attempting to deliver the same outcome
Despite having processes to document and discover projects mangers and developers do not use them
Leaders of groups duplicating work claim "are effort is just different" (actually it isn't)
Agile What Now? (Score:3, Informative)
If you're doing "Agile Projects" or have "Agile Project Managers" you're not doing agile. Agile is a set of PRODUCT methodologies. If you assemble a project, identify scope, get seed funding, kick off, and then decide to delivery you're project "Agile", you've missed the key point of agile: adjust priorities in response to change.
I get why people hate "agile", it's because most people haven't done the real thing. https://www.youtube.com/watch?... [youtube.com]
Re: (Score:1)
I get why people hate "agile", it's because most people haven't done the real thing.
Many years ago I was talking to a person who was going on about communism and how the U.S. should embrace communism as being superior. And I said to that person "Look at China and the Soviet Union. How can you say that communism is desirable?"
And their response was "Oh, that's not *REAL* communism"
Such is the case with Agile. People don't like Agile because they have lived under Agile and they know what it's really like.
Re: (Score:3)
In the real world Agile is more often an excuse than a methodology.
Re: (Score:2)
Well so is communism.
Hey, roman_mir, GTFO of my account!
Re: (Score:2)
There's a difference, though. There are successful Agile shops. There are no Communist countries that have turned out well. If I could point to China and the USSR and say "that's bad Communism" and point to another few countries and say "that's good Communism, because these countries are free, democratic, and have thriving economies", I'd be more in favor of Communism. Given the lack of such countries, I'm sticking to my belief that Communism can work for a very few thousand people, for a generation or
Re: (Score:2)
This impacts much more than Agile.
The modern day is amazed at the success at 'science'.
If only we had: ...
-evidence based policy
-agile projects
-no politics
-transit systems based on reports
And 'ideally' it is true most of these are great if you're dealing with competent, well meaning people, honest, cooperative people all operating within that system, you'd get amazing results.
But of course, that is the whole question of humanity isn't it?
If we all operated by those traits, we'd have utopia regardless of Agi
Re: (Score:2)
-evidence based policy
That doesn't always work [bmj.com] fwiw
The problem with agile is "proof it works." (Score:4, Informative)
I don't think it's bad, exactly. I've worked in a shop that has been using agile for about 5 years now. Before agile, we had good releases and bad releases. After agile, we have had good releases and bad releases. I certainly *like* aspects of it, like daily meetings, limited goals, being two weeks from something shippable, etc. But my *liking* it is different from being able to prove, quantitatively, that it's much better or worse than any other software development method.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
My problem with agile is the daily meeting crap.
Meetings are a necessary evil. The fact is, you're working with and for other people, and as such, you need to know what's what.
If it's a choice between daily short meetings or weekly long meetings, I'll take the short meetings any time.
Re: (Score:2)
I got into computers because I don't want to be around people.
This used to be true, but no more. The age of solitary developer working in isolation is long gone (If it ever existed at all). Developers need to understand the business requirements, communicate with wide variety of stakeholders from all business levels and work together as a team. Politics, clear verbal and written communication skills, and people-skills are all mandatory requirements for anyone in this industry.
You may find the environment you seek doing open-source development or perhaps (Rarely) some
Re: (Score:2)
MAKE UP YOUR MINDS (Score:2)
Can someone tell me how "agile" went from being an adjective to a noun? I accept that I am behind the curve, but why didn't I get the memo?
Is "agile" a management approach, an IDE or simply a word that's made the evolutionary leap from adjective to noun all on its own, like "chubby"? I feel so lost when a term is used without any explanation in the summary. Remember, not all nerds are corporate software developers, thank god.
Re:MAKE UP YOUR MINDS (Score:5, Informative)
"Agile" is -whatever you want it to be-, and that's part of my problem with it. There's no real normative definition that can be used to distinguish 'agile' from 'not-agile.' And whenever you push back at 'agile' asserting it is not meeting its promises, you get told "you're doing it wrong."
So at the end of the day, "agile" means not having to do anything you don't want to do (see 'technical debt')
Re: (Score:3)
So basically, like every other corporate management fad since WWII. Got it.
I'm still old enough to remember when managers were reading ancient Chinese texts like the Art of War or Tao te ching (or rather, were reading books written by hucksters who claimed to have read the Art of War or the Tao te ching) and brought their newly-minted Oriental WisdomTM to their workplaces.
God, it sucks to have to work at a corporation for a living.
Re: (Score:2)
God, it sucks to have to work at a corporation for a living.
Just take the money and run...
Re: (Score:2, Informative)
Where I work, Agile means 50 people sit around a conference table for an hour (at least) watching the project manager fill out a spreadsheet.
I myself keep my brain from dying during this by writing limericks and praying to ancient gods for a merciful death.
Re: (Score:2)
Which is why the good Lord made laptops.
Hackaday is not going to read itself, and I have beer serving devices and homemade vacuum tubes to construct.
Plus, webcomics.
Re: (Score:1)
Can someone tell me how "agile" went from being an adjective to a noun?
A bunch of guys found that their software development was going quite well and wrote the agile manefesto to explain [agilemanifesto.org] and gave it a name "Agile Sotware Development". After that lots of people wanted to pretend that what they were doing already was the same thing. They all claimed that "Scrum is an agile methodology" and that "this is agile". Needless to say they deeply perverted the main aims of agile.
Don't blame Agile... (Score:2)
...For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. Agile should inherently involve frequent 1:1 contact with users: use that time to lower expectations! Without this habit, the inevitable scope creep and the impulse to believe "of course the system will do X for me" will get you."...
I am not a fan of Agile, but the excerpt I quote is blaming Agile for what should be a routine conversation among users and developers. Of course, users have high hopes and expectations, they don't have to write the software, they only have to come up with ideas for new features.
.
It is then the responsibility of the developers, in conjunction with the users, to prioritize those expectations within the constraints of the current business. This process is not limited to Agile, it is a part of every devel
Re: (Score:3)
writes David Taber..A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture.
That's really dumb. The proper response isn't to lower expectations, the proper response is to give the user insight into the trade-offs of a new or changing requirement. Increase the budget? Reduce scope somewhere else? Extend the schedule? If the new requirement is more important that something else, let the user make that call.
Meanwhile back in the real world... (Score:2)
They don't want insight into ... ummm ... whatever it was you just said. They don't understand whatever it is you said, and they couldn't if they tried, because they can't be bothered.
They want a pony. You're just a goddam secretary (why don't you just type faster) and they'll go crying to your boss if they don't get it by this afternoon.
Re: (Score:2)
Re: (Score:2)
No they don't.
You equate not being able to do the impossible by yesterday with being incompetent? I take it you're a user. The kind one who acts like a child if he can't have a pony *and* a puppy.
I award you zero points, etc.
But does it really work? (Score:2)
Management (Score:2)
Re: (Score:2)
I've fund that it helps to think of management as an implementation of UBI [wikipedia.org]. Paying someone regardless of whether or not they do any constructive work.
Playing down expectations on video games... (Score:3)
Re: (Score:2)
(The sole developer who submitted a 256-page design doc — most design docs are promises on napkins — got their video game done on time.)
That's an example of BDUF.....Joel would be so happy.
Re: (Score:2)
I believe that is called a perverse incentive. One of my favourite mannijmunt konsepts.
Re: (Score:2)
Re: (Score:2)
Maybe the bonuses should be tied to code quality instead of schedule, or some combination of the two.
The primary purpose of agile (Score:1)
Is to sell books and consulting about how to implement agile.
Nobody has found a silver bullet for software development yet. The endless hype cycles around different methodologies like agile spring from the desire of non-technical management to systemize programming so that low-skill, low-paid labor can be organized in a repeatable way to produce consistent results.
That's why agile in particular is so focused on short-term planning and incremental results. When you constantly roll over your programming wor
Building roof before foundation (Score:3)
I worked in an Agile house for 4 years.... and went to local Agile meetups regularly. Overall, my opinion about Agile is bit.. hmmm.. Fragile!
Firstly, Agile is good at getting half-baked products out of the door. Two (2) week cadences, where features to be build, demo and shipped is quite narrow... and you get time to barely test it. Yes, you can demo it is working, but it is the tip of the ice berg. How the feature interact with other features or infrastructure is the iceberg what's below the water surface.
Secondly, Agile is good at sweeping hard work under the carpet. For an example, because there is no centralised architectural thinking or planning, every developer goes wild and build their own architectures... half of them are duplicates doing similar functions (and not to forget, poorly tested). Things like database or API designs generally takes lot of planning and thought process. By design, Agile doesn't allow such lengthy ventures.
Thirdly, Agile not scalable. Agile works best for smaller website projects.. say 5-6 page dynamic websites. If you are to do a huge mission critical project involving 100+ templates, 20+ devs so on... Agile will fail half way point, and you will have to downgrade to Waterfall, and pretend you are doing Agile to your client... which method I christened as "ScrumFall" (after James Bond movie).
Overall, I promote "prototype, maturity and ship" model (I don't know there is an actual name for this). Basically, try out prototypes first.. if it works, then promote to regular development, and finally production. I see JavaScript & C++ language committees adopting a similar work cycle. Overall, they are doing pretty well IMO, with regular releases and good quality.
Re: (Score:2)
We sent to three week sprints, to allow extra time for QA.
Which means we cram even MORE CODE onto QA the last few days...
Re: (Score:2)
Re: (Score:2)
Agile = Lazy (Score:2)
Agile was conceived as a method for managers to get more work out of developers for less money.
However, as most manglement techniques are, Agile has been turned on it's head, and is now a method for lazy developers to do LESS work, while completing more BS "tasks", then blame the "Team" when shit doesn't get done.
Purpose of Business Software (Score:2)
Agile is the same as always (Score:2)
I've figured out that the design /production team has these mandates ;
Executive management wants reduced costs.
Product owners want product that is on par with the competition.
Dev team managers (yay, plural) want achievable goals.
I work on a servicing team. I want either functional product or what to tell customers when it isn't.
Agile has changed the time frame of failure from months/years to weeks. Can I define that as success?
The right answer to expectations and timelines (Score:2)
The right answer to expectations and timelines: fuck off, it will be done when it's done, but we'll do our best. At Google this is handled by setting quarterly goals, and then watching them whoosh by when the quarter ends. Or not, in this regime things often do go faster than expected. The key mechanism that makes it work is the reward structure: Google rewards launches and basically nothing else. Want a bigger bonus? Launch something. Want a promo? Launch something. And so on. And I can personally confirm:
Re: (Score:1)
Re: (Score:2)
Netslaves never have a nice day?
You should be trying to advance to higher caste in the New Media World Order or whatever they call it now
Re: (Score:2)
-1 Offtopic for mentioning Scrum. This is a discussion about agile methods, not one about a religious cult.