Playing Politics With Agile Projects (cio.com)

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?"

Comments

FrAgile

[Anonymous Coward]

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 agile: if your requirements change that often, while there are some businesses where they do, 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. Sometimes that works, but it's less often than not.

Re:FrAgile

[BradMajors]

Different development methodologies are appropriate for different projects. One size does not fit all.

Re:FrAgile

[Anonymous Coward]

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 produce something reasonable.
In the other case, anything that isn't useful for your (only) user (group), is useless. There is no point in following a plan once it's clear that plan will no longer result in value. Obviously you should have a more long-term plan of making your software less prone to this and you will have a significant number of tasks that you can plan without agile just fine, but sometimes you should just go and do what needs to be done RIGHT NOW even if it was the opposite a few days back.
And at least for some that is what agile is about: you do what makes sense, and don't follow the plan just because it's a plan even if it leads you over the cliff.

Re:FrAgile

[Anonymous Coward]

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 which in the end turns out to be bigger than all the rest added together, e.g. the small part of scaling from 1000 to 100000 users so the whole company can use it. Often though, you can download some libraries from the internet, remake the same software as someone else made before and it will all come out okay and fit your waterfall model more or less.

b) You are developing something honestly new. You have no clue what you will find as you develop it. In this case waterfall will never work because researching unknown stuff takes orders of magnitude more time than reading documentation.

Generally, if you find waterfall is working for you that's either because you are adding yet another set of reporting screens to a pre-existing business information system or because your project should never have needed to be done in the first place and you should just have downloaded the standard package for the job instead of thinking that your company needs it's own special-snowflake package doing the same as every other company already does.

Re:FrAgile

[Todd Knarr]

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 simply don't want what you envisioned and planned on and you're going to have to change your vision and plan. That's what usually causes requirements changes, and the business has to react to that because there's no future for a business selling something the customer doesn't want to buy.

Re:FrAgile

[HornWumpus]

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:FrAgile

[Anonymous Coward]

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 agile: if your requirements change that often, while there are some businesses where they do, 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. Sometimes that works, but it's less often than not.

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.

Re:FrAgile

[Hognoxious]

Agile is just waterfall with all the roles and phases renamed and with a fixed, very rapid, iteration cycle.

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:FrAgile

[Anonymous Coward]

"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 clueless, either way I salute you AC

Re:FrAgile

[HornWumpus]

That's not waterfall. That's 'off the cliff'.

Re:FrAgile

[ohnocitizen]

I am a software dev of many years too. "Deadlines don't apply". The problem is - over and over - business assumes code is instant. So requirements slip through the cracks. And deadlines remain in place. Would you rather ship a broken product on time, or delay so the developers have what they need? Don't call it agile if you don't want to - but to ignore the reality of software development is bone headed.

Re:FrAgile

[phantomfive]

Fred Brooks famously pointed out that, "If you have a small team of competent developers, any development methodology can work." 'Competent' here means largely soft skills: things like being able to plan, and reach your plan on time (or recognize when the plan will be behind schedule as soon as possible). Agile is fine, but not-agile is ok too.

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 focused on process.....they say, "here follow these steps and everything will turn out well." Those are garbage. The other one is focused on improving the skills of the developers, basically teaching them soft skills (here's one example). Those work better.

Re:FrAgile

[Anonymous Coward]

Waterfall doesn't have analysis and planning phases?

The very original waterfall paper was actually suggesting a thing very close to what we call agile now. It did not have "analysis and planning phases". And that is good. Because it was an interative process involving doing experiments. It involved having reasonable documentation of what you wanted to do and updating that as and when you found problems with it, including updates before you developed more features.

The problem with "waterfall" as it is currently understood is that it does have "analysis and planning phases" separated from development. You sit there and imagine what the software would be like and how it would work. Then you write a "plan" and attempt to follow it. Typically the planning phase comes before a contract signing or something and the actual development comes after it. Then we end up with catastrophes like the recent systems in the UK NHS.

N.B. In agile there should also be analysis and design (note, I'm not calling it "planning" right now).

N.B. Fixed iterations are not in any way part of agile. You have probably been lied to by the "scrum is an agile process" people who insist on mini-waterfall / fixed iterations. The closest the agile manefesto comes to fixed iterations is the statement

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

In the modern world this is equivalent to a call for continuous delivery and should be completely uncontroversial. However strictly fixed "sprint" iterations are clearly directly opposed by the first and most important part of the manefesto

Individuals and interactions over processes and tools

If someone is telling you that you have to do fixed, short iterations because that "is the agile way", you want to point them to the agile manefesto on their way out of the door.

Re:FrAgile

[Anonymous Coward]

Short, incremental waterfall, with requirements defined by product owners and sales, with set timeframes based on developer consensus and prior work, works extremely well.

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"?

Re:FrAgile

[Anonymous Coward]

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. Sometimes that works, but it's less often than not.

I work in research (industry research at a large university, previously at a large, Fortune 500 company). I spent 5 years in a production grind (big design up front). You actually need to throw shit at the wall and see what sticks in all industries. That's what research is for. However, you certainly cannot have your whole production environment working that way all the time. That is literally insane, and the whole justification for having dedicated R&D teams.

Re:FrAgile

[drolli]

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 that the developers had to hide work on the underlying code infrastructure from the product owner.

Re:FrAgile

[sjames]

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:FrAgile

[sjames]

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:FrAgile

[0100010001010011]

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:FrAgile

[HornWumpus]

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:FrAgile

[PaulRivers10]

As a developer I disagree with your language and tone but feel exactly the same way about needing a different solution. In my experience agile makes managers inneffective little tyrants. Managers with big ego's thinking they're a special little snowflake trying to pretend programming is a place where you can come up with a simple 6-8 hour chunk of work every single day that gets accomplished with no bugs and no unpredictable behavior day after day week after week. LOL. As an experienced developer, I know that of 10 tasks, 7 will go well, 2 will take extra time or cause bugs, and 1 will be a total clusterf!@#. But with a longer cycle, I can do a decent job of time estimates to have the extra time in there where I know things will go wrong. I don't have any idea which task it will be beforehand - I just know if will be one of them. With Agile the manager once again has a big ego freakout when task #4 ends up taking 4 times longer than the other tasks. Well boo-hoo - we've been doing this for years, and it happens every time. You just don't know which task it will be that causes the web page to stop working for no good reason, or triggers a compatibility issue on the server because they setup the jvm wrong, or works fine in Firefox but doesn't work in IE because of an IE bug - etc. Just because your manager's huge ego means that he thinks that if we just say some inspirational sayings every morning and tell him everything is going great, that that's suddenly going to make all of our tasks easy and predictable and will magically remove that bug that pops up because John's calendar library uses getById, but Tom's page puts a name on the firm, then Thales updated the html header type, and the page doesn't work when I add a calendar to it in IE10. The managers ego is sooooo offended by that - why isn't your task done in my neat little timeframe? The manager is a special snowflake, that's supposed to make these things never happen any more. At least with waterfall I can somewhat plan out that most tasks will go well, but 1 or 2 will be a nightmare and average them out in the schedule.

Re:FrAgile

[HornWumpus]

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 the real world, you have to follow old fashioned waterfall steps like 'testing'.

Agile as practiced, isn't. It's an excuse for PHBs to feature creep and never, ever plan anything. PHBs will use agile as an excuse for giving out partial specs when they know better (so the coders will build them a simple system first, not knowing the model is broken).

The first part of the Agile manifesto referred to 'motivated enthusiastic individuals' (para from memory)...those people are well paid. If a company pays 'industry average' it _cannot_ be agile (per the manifesto).

Re:FrAgile

[HornWumpus]

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

[Anonymous Coward]

Agile has one more thing and that's constant communication with the customer. The theory is that you can see near instantly when you start to go off track of what the customer actually wants (compared to what they said they wanted when the project started) and thus you can fix it before you go too far down the wrong track. With the original Waterfall, you'd create a requirements doc and a year later show the application to the customer and they'd say WTF is that? You just wasted a year and probably lost the contract or the customer will put up with an application they hate and contract someone else to make a new one. No one is happy. With Agile, the customer can make minor corrections (they are minor if you tell them this is what we're going to do compared to saying this is what we did) and verify everything is on track, the final product is want they wanted, and everyone is happy.

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.

That is Agile, short waterfalls with timetables set by developers based on previous work and product owners involved with the mini-waterfall's requirements. The problem with Agile is all the self-taught programmers and managers don't know what it is.

Everything is a form of the waterfall method. No one delivers a product before they start to develop it (well some scams do that), no one starts developing before they know what they're going to develop. The only method that makes a slight change to waterfall is TDD. In test driven development, there's some testing before development. That's the only change. Everything is waterfall.

Re:FrAgile

[Anonymous Coward]

We know deadlines apply, we just suck at estimating how long something will take. Do you make sure all your projects are designed as modules with nice, clean interfaces between them which each module only handles one feature set or is your code a jumbled mess where adding one error condition means you have to change every place errors are checked. Example: didAnyFail(moduleList) vs if(module1Fail || module2Fail || connectionLost || badInput || ...) copied 10 different places or do you even bother to do error checking at all?

The less state there is to manage, the less unplanned work will crop up when making changes and thus the estimates will be better.

Re:FrAgile

[Anonymous Coward]

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 separate step you are stuck in the past. You have to automate it completely and integrate it with your build process.

Agile as practiced, isn't. It's an excuse for PHBs to feature creep and never, ever plan anything. PHBs will use agile as an excuse for giving out partial specs when they know better (so the coders will build them a simple system first, not knowing the model is broken).

This I find hard to disagree with. Almost any bullshit is named "agile" and PHBs and developers go around making a terrible mess. As a simple, easy to spot criteria, if you have gone more than two months without an attempt to deliver real software to real users then you are not doing agile according to the agile manifesto. This does mean that there are projects which simply cannot be run in a purely agile way. It also means that I probably wouldn't qualify most of the projects you are describing as agile.

Back to your question, "Have you ever worked on a commercial software project?" - yes. A number which really matched your description and a few which really matched the "Agile" way of doing things. Maybe the manifesto should be platitudes, however having watched the difference between the two, all of the bad projects failed to follow some of those platitudes. The most obvious being "people over processes". Sometimes things seem obvious until you see people ignoring them and realise that they aren't obvious to other people.

The first part of the Agile manifesto referred to 'motivated enthusiastic individuals' (para from memory)...those people are well paid. If a company pays 'industry average' it _cannot_ be agile (per the manifesto).

Again, hard to disagree with. There can be exceptions - young programmers might be enthusiastic but underpaid - and sometimes in a startup they could be doing something like agile. Generally, however, most of the industry is obviously not doing agile if you just read the Agile Manifesto clearly. I'm not even talking about the "no true Scotsman" definition of not doing agile. I'm talking about in your face obvious opposition to the basics of the Manifesto and every development methodology that ever claimed to be agile.

Re:FrAgile

[Anonymous Coward]

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: FrAgile

[Anonymous Coward]

Then you're not doing a generally accepted agile *process*. as a QA architect and scrum master, I have found that agile *done right* has helped me release better quality software more predictably

Re:FrAgile

[HornWumpus]

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 teams that work and teams that don't. Formal methodology had nothing to do with the distinction. The 'formal methods' people have all been air thieves in my experience.

If the team is made of 'motivated and enthusiastic individuals' it worked. At least until a toxic personality showed up. That's about the only part of the manifesto that counts. Professional HR is the death of most well functioning teams. The team is overruled and the first 'seat warmer' is hired.

Re: FrAgile

[Anonymous Coward]

Don't blame the process for ducky managers. Yes Waterfall lets you hide all the little things that go wrong, but one of the fundamentals of Agile is the transparency of immediately identifying that. That should be a good thing and if it is not, those managers need to go back to remedial Agile training

Re:FrAgile

[golodh]

Waterfall works really well when you have a big coherent system to maintain with all kinds of long-distance couplings in e.g. the software architecture (what should the software do and what not, which part does what, which parts provide services to other parts), data-structures (field definitions, encoding schemes, tracking id's, etc.), database engines, database consistence rules, timing requirements, etc.

You really really don't want some SCRUM team messing around with those.

And yes, Agile is superior to Waterfall when it comes to adapting software to en-user requirements that can be accommodated within the constraints imposed by architecture and application-server and application-application interfaces and have only "local" implications.

It absolutely helps if coders can talk to their users directly instead of through a layer of architects, analysts and designers. But you have to constrain what they can talk about.

Re:FrAgile

[Anonymous Coward]

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.

Software development has moved on quite considerably since unit testing was a big thing. There are many systems for funcitonal testing which do much more complete end to end testing. Combine these with development methodologies such as Test Driven Development which direct you to create testable software and you will find that it is possible to completely automate testing. You should also look up things like QuickCheck and data driven testing which fit in well to give you a much wider testing of your problem space.

Re:FrAgile

[HornWumpus]

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 human testers. If you rely entirely on automated testing, your users are your only human testers.

Re:FrAgile

[Anonymous Coward]

As another AC, I'd would say that any gathering of requirements from the customer, or trying to understand a new domain and identifying interfaces and constraints must count as preliminary design preceding an agile software process. No software or hardware related degree exposes the student to every possible industry or system type, and there is always the first time for somebody and always something new. Tests would be difficult to write before the code without the understanding of the system and its boundaries.

Re:FrAgile

[Anonymous Coward]

Automated testing also doesn't tell you anything about how well the interface will actually work for the users. I remember a project where users were to key/correct data from a full page form with over 40 fields. The UI was setup to following horribly so that the users had to jump all over the form to enter data rather than how the fields were laid out on the actual form. A very costly mistake in terms of lost productivity that could have been easily fixed with some user testing before being put into production.

Re:FrAgile

[Anonymous Coward]

No one does anything new, they just don't realize it was done 30+ years ago. What we get is slight variations to old concepts. Bottlenecks move, and the designs need to be tweaked. I remember reading about async programming and co-routines back in high school from articles that were 20+ years old. Then I wondered why no one was using them other than very low level OS functions. 10 years later I read about all of this "research" going into why Apache is so slow and they say it turns out it was because they were using the thread scheduler to handle their IO by using blocking calls.

Seems no one read about any of this "new" technology and recreated their own, poorly. The problem had been solved, no one cared to know about it. And me, a lowly high school student was asking questions like "if context switching is so expensive, wouldn't that mean it's better to not context switch", which lead me to co-routines. Then I asked "If IO blocks, the co-routines would block. Wouldn't it be nice if there was a system to notify me when the work is done. Ohh, there is!". Does no one ask these questions? Are people really this stupid? Took me a weekend of using Altavista to figure out what took some people years. Seemed like everyone would get so excited to find out great the new systems were, but didn't think twice to reflect on how crappy they made the first system.

Nearly all software issues have been solved. All that's left is the hardware side and the constantly shifting bottleneck in software. Everything comes full-circle once every decade or so, and the industry seems to completely forget what happened a decade before. I think this is because they never truly understood the problems, they just blinding followed best practices and memorized what commands to run in their favorite toolset.

If you want to be working in something new, look at AI, everything else has been solved for a long time. Just too many people too incompetent to google for an answer.

Re:FrAgile

[Anonymous Coward]

I have an account rep who runs around now telling everyone all we do is agile. He has somehow gotten it into his head that if we do agile, then nothing is ever out of scope. This, combined with his logical fallacy of needing to provide full quotes up front to the customers, have got me sharpening my resume again.

Re:FrAgile

[Aighearach]

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 successfully by companies with products all along. But indeed, it does a poor job when providing consulting services to PHBs.

Re:FrAgile

[Aighearach]

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 somebody somewhere probably actually wants to be finished eventually.

The only difference on iteration count is that in Agile, even after you've been through the planning and started to build the things you planned, you go back and change the requirements which means you have to throw away a bunch of what was already implemented. That is good, because... weekly billing cycles. There is no real argument made that changing your mind about the details at that stage is good; the claim is that Agile is good at billing when that's what the decision makers want. ;)

Re:FrAgile

[Aighearach]

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 the week. One baby step at a time. One step per week. However many weeks it takes to get somewhere. So, it is very very different. The only situation where the "product owner" sets a schedule is when they hire employees. And they don't need to listen to estimates, they need to measure and predict based on those measurements.

The part that I find funny is that people without a good plan manage to hire consultants without having agreed to a plan. If the plan sucks, that should be addressed in the bid; they almost certainly passed up bids from people explaining what their problems were, and giving a bid on fixing those problems and building a quality product. Instead they choose the bid that says, "anything you want, for however long you want, pay us by the week." It could be 10 years later with no product and they would never have actually failed at anything specific.

If a client wants a bid on a magic pony, and I want to submit a bid, it is going to be for a game or an animated short, I'm not going to bid on, "magic pony by the week, however long it takes."

Re:FrAgile

[Aighearach]

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/...

Re:FrAgile

[phantomfive]

Yes, and that is really frustrating to me, personally. I always do my best estimate, and then add some time for padding. When I finish right on my estimate, my boss is happy, but I secretly know that I've gone over my true estimate!

Re:FrAgile

[Anonymous Coward]

I spend most of my architecting and design time on edge cases. The other devs hate me for constantly bringing up edge cases during meetings, but their code always has issues in prod. My latest big project for a multi-million dollar contract with over 100k users is almost 3 years old and there has yet to be a submitted bug from the client or a complaint.

They look down on me because I don't use "agile" and they've been officially trained and using agile for years. The proof is in the pudding. My projects finish early, under budget, virtually no customer complaints, and almost no bugs reported by anyone. But hey, I'm not agile, so I'm somehow inferior.

Re:FrAgile

[cwsumner]

Yes, and that is really frustrating to me, personally. I always do my best estimate, and then add some time for padding. When I finish right on my estimate, my boss is happy, but I secretly know that I've gone over my true estimate!

You make estimates that turn out to be off by a predictable amount. You add a "fudge factor" to the estimates to correct for the error, even though the reason for the error is not yet known. The estimates end up within tolerance. 8-)

Sounds like Engineering to me. The better you get, the smaller the "fudge factor" needs to be. Eventually, some scientist will figure out the reason for the error, if you haven't done it first.

"Keep truck'in!"

Re:FrAgile

[david_thornley]

When well done, Scrum can be Agile. You do have to take the process less seriously than I've seen in some places.

Re:FrAgile

[phantomfive]

The estimates end up within tolerance.

Worse than that, I finish at exactly the end of the given tolerance!

Re:FrAgile

[minstrelmike]

The main reason I like Agile-style development is sometimes the programmers have a chance to finish the task before the users change their minds.

Re:What we really need is bigger butts

[Anonymous Coward]

No we need smaller butts so that we enjoy sitting on GREASED UP YODA DOLL even more.

better idea

[Gravis Zero]

how about managers stop playing games and start treating their teams as people rather than "assets".

Re:better idea

[Anonymous Coward]

"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.

Re:better idea

[Anonymous Coward]

Oh, stop being such a whiny little bitch! You're working for psychotics. Pick a different line of work if you don't like it, or start your own shit, whatever, just quit your bellyaching!

What is needed: kill competing projects

[Anonymous Coward]

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)

You're doing agile wrong!

[Anonymous Coward]

Politicians would actually make great scrum stake holders, (and terrible scrum developers of course, which is what I think the op was directed at) they know what they want and the deadlines are really from the scrum master.

Also politicians would be good at scrum because they all talk the same domain speak. Most agile projects that DON'T involve a Web product fail cause the teams don't have the same domain knowledge. Hence why while fails, it focuses on the software view and that it. It throws system engineering out the door... Makes sense as syseng is more expensive than sw dev.

Re:You're doing agile wrong!

[Lije Baley]

-1 Offtopic for mentioning Scrum. This is a discussion about agile methods, not one about a religious cult.

Re:You're doing agile wrong!

[Anonymous Coward]

You're an idiot. Scrum is a type of Agile. Talk of Scrum is good here in this thread.

Re:You're doing agile wrong!

[Anonymous Coward]

You're an idiot.

No, you're slightly misinformed.

Scrum people claim to be agile. They also claim that you have to follow all the processes of Scrum together otherwise you aren't doing scrum. What Agile says about this is clear

Individuals and interactions over processes and tools

as long as scrum is designed so you have to follow all scrum processes, scrum is not an agile process. It might be sensible to discuss why scrum people think they can get away with claiming to be agile and why the want to do that, however scrum is opposed to agile so we shouldn't be discussing it as an example of agile.

Agile What Now?

[Trails]

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?...

Re:Agile What Now?

[Anonymous Coward]

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:Agile What Now?

[HornWumpus]

In the real world Agile is more often an excuse than a methodology.

Re:Agile What Now?

[scamper_22]

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 Agile or not.

And we don't operate inside that system in isolation.
Business, QA, Product, accounting, portfolio management, sales, architecture, security, finance... are all there. Like it or not, most of that is still project based; much more suited to waterfall and heavy upfront design.

Agile, like evidence based policy or the rest above... cannot and should not be used to escape humanity. You cannot escape politics.You cannot escape 'the public'. You cannot escape You cannot escape the struggles for money and power.

Since developers, like scientists are pretty bad when it comes to games of power/politics (as I am), the result is predictable when you throw in a game of Agile that is essentially, putting you directly in the ring.

You have to have some strong leaders that have created a company of Agile for it to work. Most often this from the company founders building in that way or a really really really strong company wide initiative. If you don't have that, you're going to end up worse than Waterfall. You're going to end up in a mess.

Re:Agile What Now?

[Hognoxious]

Well so is communism.

Hey, roman_mir, GTFO of my account!

Re:Agile What Now?

[phantomfive]

-evidence based policy

That doesn't always work fwiw

Re:Agile What Now?

[Anonymous Coward]

You don't live under Agile, you and the customer make the Agile.

Re:Agile What Now?

[Anonymous Coward]

This is part of the problem, I believe. Any software development technique should be sufficiently robust that it offers the path of least resistance. In other words, people perform to the SDLC because that's the easiest thing to do. It should be easy to follow and hard to screw up.

A lot of the new methodologies don't seem very robust. There is plenty of anecdotal evidence of shops claiming to be "This" or "That" type of shop and yet still having significant project failures.

A strong methodology ought to be idiot resistant, at the very least.

Re:Agile What Now?

[david_thornley]

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 two, given a charismatic leader and a certain amount of isolation, and is bad if it's imposed on any larger scale.

The problem with agile is "proof it works."

[gestalt_n_pepper]

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:The problem with agile is "proof it works."

[Anonymous Coward]

My problem with agile is the daily meeting crap. I got into computers because I don't want to be around people. The only way I want to daily meet with people is if I'm operating the guillotine to execute them.

Agile was thought up by lonely insane managers who finally thought up a way to force people to talk to them.

Re:The problem with agile is "proof it works."

[Snotnose]

If you have daily meetings your manager is a moron who doesn't know how to manage.

Re:The problem with agile is "proof it works."

[Pseudonym]

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:The problem with agile is "proof it works."

[Lotana]

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 entry-level positions.

Re:The problem with agile is "proof it works."

[Ash-Fox]

If you have daily meetings your manager is a moron who doesn't know how to manage.

You're a moron that isn't familiar with Agile methodologies. From his description, it sounds like his team are using a variant of scrum Agile and I should point out that in the case of scrum, the team manages it self, the manager is out of the way or plays the role of product owner, which has a very limited influence on meetings.

Re:The problem with agile is "proof it works."

[Ash-Fox]

Agile was thought up by lonely insane managers who finally thought up a way to force people to talk to them.

In my experience, most managers seem to want to avoid the daily stand ups, even though they're supposed to be just 15 minutes at most.

MAKE UP YOUR MINDS

[PopeRatzo]

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

[david.emery]

"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:MAKE UP YOUR MINDS

[Anonymous Coward]

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:MAKE UP YOUR MINDS

[PopeRatzo]

"Agile" is -whatever you want it to be-,

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:MAKE UP YOUR MINDS

[Anonymous Coward]

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 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.

Re:MAKE UP YOUR MINDS

[fustakrakich]

God, it sucks to have to work at a corporation for a living.

Just take the money and run...

Re:MAKE UP YOUR MINDS

[Cpt_Kirks]

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:MAKE UP YOUR MINDS

[trjonescp]

"Agile" is -whatever you want it to be-, and that's part of my problem with it.

My favorite definition doesn't prescribe any rigid methodology rules at all, but rather a set of values[1]. In fact, one could even follow a waterfall methodology and just make some adaptations in the spirit of some of the Agile Manifesto values.

[1] http://www.agilemanifesto.org/

Re:Report on the shooting you fucks

[Anonymous Coward]

how did you learn about the shooting? It wasn't here. So go back to wherever you learned about shooting and talk about it there.

Not everything needs to be everywhere.

Don't blame Agile...

[QuietLagoon]

...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 development process.

Re:Don't blame Agile...

[tomhath]

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.

Re:Don't blame Agile...

[Anonymous Coward]

...For example, "A key success factor for agile projects is the ability for every team member to talk expectations down at every possible juncture. . . . . use that time to lower expectations!

I read the article and I can't figure out if it is serious or a parody written by some who used to write for The Onion.

A few more gems:

A key success factor of an agile project is the project lead’s ability to move quickly, glomming on to whatever hot topic is going to be easy to sell to corporate leadership. Agile’s proclivity for producing demos can make it downright sizzle-icious. So make sure there’s a cool demo for each sprint.

Agile projects are most effective when the environment is changing quickly and a big-bang release — any big-bang release — will involve a lot of waste.

The eternal meetings...

[Anonymous Coward]

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 tomorrow" questioning.

With 0 productivity getting done during a stand up meeting, at least 25-35% of the the day is shot to hell in the finger pointing session.

Re:The eternal meetings...

[Anonymous Coward]

My problem with Agile is the stand up meetings.

Stand up meetings are a part of Scrum which is a methodology which has very little to do with agile. They are mentioned exactly nowhere in the Agile Manifesto. Which is not to say that short (max 20 minutes) stand ups aren't a useful and good idea. It's just that this is a perfect example of how the thing that's wrong with Agile is that almost none of the people complaining about agile are actually doing agile.

Re:The eternal meetings...

[Pembers]

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 fair, I have been on agile teams where the stand-up meeting would last 30 to 45 minutes and tended to turn into a design meeting, with two or three people doing most of the talking. This was either because we hadn't understood the requirements well enough at the start, or had just got lazy and not done enough of the design upfront. The scrum master should've set up a separate meeting for the design work, or just told the rest of us we could leave once the design discussion started. I suspect the reason he didn't was because he was partly responsible for the design, so it was convenient for him to have just the one daily meeting. (Or he was coming up to retirement and had stopped caring about not wasting other people's time...)

Now, if someone is constantly using "I'm blocked" as an excuse to not do any work, that's a matter for their manager, not the team or the scrum master.

Re:The eternal meetings...

[Dutch Gun]

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 down to reasonable levels and keep the information *very* succinct, which some people admittedly have a hard time with.

If anyone listening is involved with such hellish meetings, you need to start holding your meetings standing on one leg, or perhaps in some awkward posture that can only be held for about 10 or 15 minutes. And bring a two minute timer. No individual report should take longer than that.

I'm pretty sure I'd just walk out of a meeting like that after 20 minute or so, or else bring along a laptop so I could get some actual work done. I suspect I might not last long in such an environment. Fortunately, I haven't had to.

Re:The eternal meetings...

[Hognoxious]

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.

Re:The eternal meetings...

[Anonymous Coward]

Then you're doing it wrong.

This. If your stand up meeting takes longer than 15 minutes per day then it's not performing its intended function. Individual speaking time must be limited to 1 minute maximum and preferably less. If there are too many people for each person to have at least 30 seconds then you need to break up into smaller teams and have the leaders of those smaller teams report back to a higher level person. If the matter cannot be resolved in 30 seconds of talking, then it's tabled and the interested parties can huddle after the standup or arrange a separate meeting with the team leader to sort it out. On rare occasions, when a mater concerns the whole team, it can be acceptable to extend the standup after the normal time has expired, but this should not be a common occurrence; otherwise, you're still doing it wrong.

Re:The eternal meetings...

[Pembers]

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:The eternal meetings...

[Anonymous Coward]

Daily live status update meetings make no sense to me in a world where everyone sits at a computer, and has access to project planning software and electronic chat systems. Luckily in the one place that used this epic waste of time I was able to convince them of that.

Re:The eternal meetings...

[Aighearach]

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:The eternal meetings...

[Pembers]

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 know yet what features it will have, but we promise they'll all be really good!"

Re:The eternal meetings...

[david_thornley]

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:The eternal meetings...

[Pembers]

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.

The wrost is LEAN

[Anonymous Coward]

Managers THINK research, design and development is PRODUCTION like MANUFACTURING, it is certainly not. It is "research, design and development". Applying LEAN from Toyota to a "production line" is NOT "research, design and development".

Best thing to do is simply, get a better manager who realises what we do is NOT PRODUCTION. Production is when you repeatedly PRODUCE an ITEM. We RESEARCH, DESIGN and DEVELOP.

Being AGILE is fine, being LEAN is fine, being treated like a CHICKEN BEHEADING PRODUCTION LINE is NOT ok.

Key success factor

[Anonymous Coward]

Of any project is delivery of the goods.

Civil contruction has that handled neatly.

Sure the schedule can overun, the project my end up costing more, but in no point there is the sense that nobody knows what is going on.

And normally ("grain of salt here"), the building doens't collapse midway of the construction.

Now on software projects...

But does it really work?

[l0n3s0m3phr34k]

If the process works better than others, should the users hurt feelings be a reason to abandon it? Unless you just handing users some beautifully finished product and don't ever have to "bother" them, their going to "hate" anything that involves any additional work. End-users originally hated the Start/Taskbar. Users hate changing passwords. Users hate IT in general. Mac users "Hate" windows. But if a process actually works better, is more efficient and delivers better than others, screw 'em. At least that's what my inner BOFH says lol.

Re:But does it really work?

[Anonymous Coward]

You don't really know what agile is about or how to measure its success do you?

Hint: It's NOT "a process"..

Management

[mycroft16]

We use Agile in our office and for the dev team it works pretty well. Our problem comes from the management not actually having a clue about software development, despite our best efforts to educate them. We still deal with insane feature creep from above and delivery promises before we've even been informed of the new feature.

Re:Management

[PPH]

I've fund that it helps to think of management as an implementation of UBI. Paying someone regardless of whether or not they do any constructive work.

A BASIC Explanation of Agile

[Anonymous Coward]

10 GOSUB TellThemWhatTheyWantToHear
20 GOSUB BlameThoseBeneathYouForFailure
30 GOTO 10

Playing down expectations on video games...

[__aaclcg7560]

As a lead video game tester for three years, I had to talk down the expectations on the delivery schedule. The original schedule is based on what it would take for the developers to get every milestone bonus on time without any inevitable delays taking place. I usually add a month to the original schedule and a +/- two week window for code release, and my schedule have proven accurate nine out of ten projects. (The sole developer who submitted a 256-page design doc — most design docs are promises on napkins — got their video game done on time.) The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.

Re:Playing down expectations on video games...

[phantomfive]

(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:Playing down expectations on video games...

[Hognoxious]

I believe that is called a perverse incentive. One of my favourite mannijmunt konsepts.

Re:Playing down expectations on video games...

[Ash-Fox]

As a lead video game tester for three years, I had to talk down the expectations on the delivery schedule.

I used to e-mail this picture to some people when I got fedup of trying to manage expectations.

Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.

Heh, I'm used to seeing people treated like shit in consultancy and nobody has an expectation of bonuses.

Re:Playing down expectations on video games...

[NormalVisual]

The developers always get pissed off when I remind them that I don't get bonuses and I'm not obligated to care about their bonuses. Most of the inevitable delays come from them trying to get their bonuses instead of fixing the problems in their code.

Maybe the bonuses should be tied to code quality instead of schedule, or some combination of the two.

Half agree

[raymorris]

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 certain requirements requires a certain amount of time. That can't be changed by management fiat. Regularly attempting to complete projects in less than the required time can only result in one of these three results:

A) Projects are frequently not completed on time.

B) Shortcuts are used regularly, duct tape that makes the next project take longer, while compromising reliability and security.

C) Workers are frequently asked to work long hours, resulting in turnover as well as the same problematic shortcuts as b).

Once in a while, there is an externally imposed deadline - taxes have to be filed by April 15. In such cases, you can either limit the scope and only do as much as you have time
to do, or choose from the three failure modes above.

Pretending otherwise may appear to work for a while - the product is delivered. However, by shorting time, the work was necesarily shorted - testing wasn't done, code was copy-pasted from Stackoverflow without understanding what it actually did, or perhaps to make deadline the programmers used code you have no license to use. These things will come back to bite you.

The way to quality software, reliable software that can be maintained with reasonable manpower, is to recognize that it takes as long as it takes. You can rush it no more than you can rush the growing of crops. Is this inconvenient for management? Absolutely! And the job of management is to figure out how to get the best possible results from real world, non-optimal conditions.

  In fact, software development management requires talent because not only can you not dictate how long it will take to achieve a predetermined set of requirements, you can't even reliably predict it! Development is a process in which most of the work moves along at a steady pace, but the trouble spots can take unpredictable amounts of time. Yeah, that makes it hard for management. That's why management is paid five times as much as production - because they have the skills to deal with uncertainty on a significant scale.

Re:Half agree

[Anonymous Coward]

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 acquisition, push vs pull, replication vs xml messages, nothing was decided. Just a magic box that would get the data from them to us, to take one example.

We're supposedly "agilish" but the first four sprints have already been planned by our project manager and only the last one delivers a product, it's not agile. It's just really, really bad waterfall. I can assure you that if we 2+ years ago just got permission to start doing anything, we'd within a few months have prototyped up a few more solutions and made way more decisions based on facts and feasibility instead of now when the whole thing is based on conjecture - by people who won't be doing the coding. Best part? On Monday I'm going to announce my bits on the first sprint will be delayed, the ones still refining the spec doesn't have the list of fields we'll so there's no message format so I can't finish the receiving code. Which means we won't receive data as expected so the whole plan will fall apart.

I'm not saying Agile would solve all our problems, because there's no much dysfunction here... but a waterfall project can deliver fuck all in 3 years and that's okay. If an Agile project doesn't deliver anything that can be considered Done, even on a tiny fraction of the functionality in 3 months, I'd call it a failure. And then we could at least fail early, before all the architects and visionaries and early project managers have moved on to create the next disaster leaving us with the clean-up on isle we're-so-screwed. And my project manager is of course trying to make shit roll downhill by pushing us to make something of this mess because we're going to fail, the only question is how badly.

Re:Half agree

[Anonymous Coward]

I absolutely agree that the Agile theory that you don't find out the requirements before you begin work is stupid.

There are several manifestations of this:

• I don't want to write down any documentation or even a minimal plan before I write some code.
• it is impossible to find out the full requirements before you have tried putting out some code.
• We should not waste too much time on planning before we deliver some product.

The first one is truly stupid, and in this you are right. This is "agile" used as an excuse to do bad work. There is nothing in the Agile Manefesto which says you should not plan. It does say "Responding to change over following a plan" but it has a very clear statement "That is, while there is value in the items on the right, we value the items on the left more.", or put another way there is value in following a plan, something which seems to have escaped the notice of quite a number of cowboy coders who try to use agile to cover their incompetence.

The second one is just, inherently true. You should put emphasis on the word full. Very often you have to actually try something to see what is wrong with it and how you need to fix it. Very often you find that you can solve a slightly different problem at 1/10th of the cost of the original one and actually have a happier customer. There are lots of ways of dealing with this - "prototypes" - which don't work because they mostly avoid addressing the truly hard problems - "spikes" - which are often useful as a way of finding out about new ideas but which can only be done well when you are close to solving the problem anyway and so on.

The third one follows as a consequence of the second. You need to plan "just enough". That's more or less easy to define. Your time and effort spent planning should be paying back in saved time developing later. This will vary from project to project, from situation to situation, however its totally critical to say that most commercial fixed price projects spend far too much time on the initial planning and end up hamstrung by that plan where they would have done much better to do a much smaller plan, a much smaller delivery and then an iterative investigation of what to do next.

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.

I've also seen this, however I see it mostly in "almost agile" development. There's a whole bunch of stuff around this that you have to buy into together. You should be specifically building your system so that your software is easy to change. This means that yes, you put in work and then throw it away, but you always do that with the "simplest thing that could work" which means that the amount of that work is small and that when you do the next iteration you know exactly what your actual requriements are and choose better than you would have done at planning time. You have to be willing to work on making it easier and easier to change your software both by making the code cleaner and by making sure you have the right tools around it.

Re:Half agree

[Dutch Gun]

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 too much you don't know until you get into the meat of a problem and run into unexpected design or technology issues. You just can't plan in your initial design for those because those are unknowns. Only your second iteration can possibly account for those previously unknown factors. It's hard as hell to throw work away, but it's far more painful in the long run to work around fundamental problems that you wish could have been solved earlier in the design phase.

Beyond that, though, it sound like you've got experience with a work environment that has a lot of issues beyond any methodology problems. Long work hours, poor quality control, lack of reasonable management... no magic formula is going to fix such an environment besides a fairly radical shakeup of the company culture.

Re:Half agree

[Anonymous Coward]

Once in a while, there is an externally imposed deadline - taxes have to be filed by April 15.

Actually, no, they don't have to be filed by April 15. You can request an extension — no questions asked — until August 15. And even then, if that's not enough time, you can request a second extension, often approved, until October 15.

Re:Half agree

[Lotana]

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 prototype and write it properly.

I hope like hell that my experience is the exception and not the rule.

 

Re:Half agree

[Dog-Cow]

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:Half agree

[Aighearach]

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 before writing the actual software. Consultants can do the same thing, they're just gone by the time it matters and so they don't "have" to care.

Re:Half agree

[Hognoxious]

Silly question - why don't they stagger them through the year, by something like birth/founding date?

Re:Half agree

[david_thornley]

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 refactor then, we would have had considerably more trouble later.)

Re:What we really need is bigger butts

[umghhh]

This is just about the only thing that can help - big butt.

Meanwhile back in the real world...

[Hognoxious]

the proper response is to give the user insight into the trade-offs of a new or changing requirement.

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:Meanwhile back in the real world...

[tomhath]

Yes, they want a pony. Which is why you tell them they can have the pony, but they have to trade the puppy to get it. Everyone understands budgets and schedules. If you just tell them you're too incompetent to develop what they want they'll believe you and offshore the work.

Re:Meanwhile back in the real world...

[Hognoxious]

Everyone understands budgets and schedules.

No they don't.

If you just tell them you're too incompetent to develop what they want they'll believe you and offshore the work.

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.

Agile was just terribly named

[NotSoHeavyD3]

I mean I think I get where the agile dogma was trying to go but they decided to make something they could sell to business higher-ups and by doing so gave management just enough room to completely fuck it up. From what I can see what I consider agile is really 4 principles

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 means the one that wants can't be silent either

Trust - Both sides have to believe that the other knows what they're doing because if they don't everyone is screwed. (That means no micromanagement. I'm always surprised how often people doing agile fuck this one up.)

Respect - Don't waste either sides time or resources. This is in opposition to talking but the point is if you want your developers to do their work don't waste their time with tech support. Builders also shouldn't waste the owners time with stupid question about minutia.

Reflect - every so often go over what did and didn't work and what could be done to improve and you really need to act on those things. (For example I've worked at places that didn't automate releases and didn't really want to check if this was a problem even when we brought it up.

Anyway in most cases what's called Agile is really cargo cult agile. (It looks like agile but things are done for the wrong reasons.)

The primary purpose of agile

[Anonymous Coward]

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 workforce to the next group of fresh-faced college grads, nobody is capable of long-term planning or real design.

What's the issue?

[Anonymous Coward]

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."

It might not be how I would express it, but what exactly is wrong with the sentiment? A development team is only able to do so much, and generally will never have done everything that the business would like from them. When you have more to do than you can possibly do, making the business prioritise and maintaining reasonable levels of expectation is important. Would users really hate a development team that manages expectations and scope creep MORE than they hate dev teams that commit to unimportant shit and give completely unrealistic deadlines and then deliver late and without the critical features?

Building roof before foundation

[nerdyalien]

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: Building roof before foundation

[Anonymous Coward]

I beg to differ ... A year or two ago, we delivered a large server project on time and with the best quality in my company's history - 12 agile teams worldwide. You can do it if you do it for real, not just window dressing

Re:Building roof before foundation

[Anonymous Coward]

I have the feeling you confuse "agile" with "we don't do planning, design and generally any kind of thinking if avoidable".
If you know your stuff is badly tested, you need to put testing on top of the list, if your documentation sucks, put writing better one on top, if your frameworks need to be properly designed and cleaned up, assign someone to do that.
If instead you make agile "everyone does what they want plus what customers should loudest about, and everything else is ignored" it can't end well. Especially if you don't have a balanced team with people that simply do what has to be done. Not sure such a barely-functioning team would work all that much better with any other development method though.

Re:Building roof before foundation

[Cpt_Kirks]

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:Building roof before foundation

[Ash-Fox]

For an example, because there is no centralised architectural thinking or planning, every developer goes wild and build their own architectures...

Doesn't like something you could do in SCRUM or Lean Agile unless you weren't following them properly.

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).

I've successfully used it on massive teams with fewer issues than waterfall, V model etc. in my consultancy life. I think your experience of Agile has not been wholesome based on your descriptions.

Also, yes, I have seen Agile done poorly a lot. But, I see Waterfall, Prince2, V-model, Extreme Programming etc. done poorly as well.

Re:Building roof before foundation

[Ash-Fox]

We sent to three week sprints, to allow extra time for QA.

Decouple manual testing from your development sprint (make sure you a proper CI with test automation in place and strict TDD/BDD policy. Failing TDD/BDD implementation fails that functionality).

Have your QA team manually testing the solution delivered one sprint behind to deal with issues like pesticide paradox through the use of session based testing. This also means the QA team will likely be able to perform more extensive testing.

Which means we cram even MORE CODE onto QA the last few days...

Yeah, that won't be an issue on my advised testing approach.

Agile doesn't kill projects

[Anonymous Coward]

People kill projects. https://www.youtube.com/watch?v=BKorP55Aqvg

Two approaches to learning requirements

[raymorris]

> 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. It's frequently tried, and rarelt effective.

With option (b), I might get 90% of the requirements up front, and have those in mind from the very first moments that I start thinking about a design. I'll also get a rough idea of what categories of additional functions or requirements may come up in the future. Often, I see how the requirements could be simplified by removing a redundant or unnecessary part of the existing process. The point is, I get 90% of the requirements up front.

With option (c), you design and build something that meets 10% of the requirements. When you try to deploy it, you learn about another 10%. So you scrap it and build something that meets 20%. You try to deploy that and learn about another 20%, so you shove twice as much functionallity in wherever it will fit, creating a bit of a mess. You deploy that and find out about another missing 20%, so you pile that 20% on top. Then you learn that the 40% that's still missing is the important part, so you rip out the guts, keeping the gui, and shoehorn the new guts into the old gui. Now you meet 80% of the need - still less than the 90% you could get the first time by sitting down and watching users work before you design anything. And your 80% code is an unholy mess from shoehorning new stuff in at each stage.

Agile = Lazy

[Cpt_Kirks]

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

[theshowmecanuck]

The purpose of business software is to support the business. Not vice versa. Businesses requirements have scope and deadlines. Software developers are responsible for telling the business how long it will take to achieve the scope, and work with the business to set the expectations and deliver on time and budget. Business needs almost always involve far more than just the development shop: advertising (which means customer expectations... which can kill a company when it doesn't deliver) and regulatory complianc are two big ones that come to mind. The original AT&T failed miserably to deliver software the FCC said was required to provide cell phone number portability which caused huge fines to be levied against them, backlash from customers, and their stock to drop so that Southwest Bell could buy them out and become the "New AT&T". Development supports the business and agile doesn't support hard set/business due dates.

Agile is the same as always

[rickb928]

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

[melted]

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: you get the behavior you reward, for better or worse. All this daily meeting bullshit would just get in the way of adults doing their work.

Re:What we really need is bigger butts

[Aighearach]

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

agile marketing buzzwords

[Anonymous Coward]

"agile" is just the current meaningless buzzword that the current crop of consultants are using to fool morons with MBA degrees into pouring money into consultants that should have been spent on their actual teams.

There's nothing new here. These buzzwords come along every few years. There's some new hype launched around some old idea masquerading as a new idea and wrapped in some TED-worthy or Steve-Jobs-worthy tech talks with PowerPoints etc.

There have been lots of these, and there will be more as long as pointy-haired bosses (hat tip to Scott Adams) are around. I remember the tidal wave of hype about "fuzzy logic" where everybody was rolling-out products that used fuzzy logic and consultants were making money talking about it, lots of people were pretending it was some big new idea.... then people realized that at its core it was basically replacing if(x==5) {...} else {...} with something like if(x5) {...} else {...} and then noticed that they'd always been doing that where appropriate already..... and you just don't hear much about "fuzzy logic" anymore. KAPOOF! Fad destroyed. Consultants off to think-up new buzzword.

oddly, slashdot mangled that comment

[Anonymous Coward]

very carefully wrote second stupid example as "if(x lessthan 5) {...} else if(x greaterthan 5) {...} else {...}" saw that it looked good in preview, and than watched it post in a broken manner. (the escaping of the lessthan and greaterthan worked in preview but not in post) [head scratch]