Comment On The Great Pyramid of Agile

Many years back, I got hooked in to whole the Atkins Diet craze. And like most dieters, it didn’t work. I lost weight and slowly gained it back over the next few years. The reason that Atkins – and all the other fad diets – fail is because they try to avoid a simple, painful truth: short of altering body physiology, the only way to lose weight is to eat less and exercise more. [expand full text]
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Re: The Great Pyramid of Agile

2007-05-29 07:28 • by Markus Schaber (unregistered)
I fully agree that a good process won't help to get success when the developers are not good enough, but the other is also true.

Having braindead processes will hinder good developers, and you have the warranty that the project won't succeed.

Re: The Great Pyramid of Agile

2007-05-29 11:22 • by Trumpi (unregistered)
I see a lot of people bashing this article because they think that it bashed Agile Development. I did not get the impression that it was bashing Agile, but maybe I'm missing something.

I think that the article says this: people think that they need this thing called "Agile" and they then adopt a new process. However, there are still people in the team who are not educated in Agile techniques. This is actually un-Agile, because Agile favours people over process.

I found myself in a job where Agile was used as a marketing term to prospective clients. What I found there was that Agile meant no documentation and no process. Again, this is not Agile -- clearly there were people there who knew about this term "Agile", but did not know how it worked.

Re: The Great Pyramid of Agile

2007-05-29 11:45 • by Peter Hundermark (unregistered)
The analogy used, like most between software and building, does not work well.

Software is complex. Change is endemic. Therefore the process employed needs to be appropriate. This turns out to be a system with a feedback loop and a short cycle time. It allows stakeholders and the development team to work inspect small increments of built software and adapt as they understand more and as the environment changes around them.

It's true that bad developers will deliver cr*p software. This will be true for every process. With a transparent, agile process you will get the bad news soon and you can then do something about it. With waterfall you'll p*ss bucketloads of money into the project before you find out it's doomed.

Perhaps the lesson for agile evangelists is to stop using the same old, bad analogies.


Re: The Great Pyramid of Agile

2007-05-29 11:51 • by tamosius (unregistered)
Re: ...and the overwhelming majority of software developers (i.e. the less-than-good folks), Agile methodologies simply cannot work

One of the Agile methodologies *requirements* is to have *less but better* developers.

Re: The Great Pyramid of Agile

2007-05-29 13:24 • by Laura (unregistered)
Agile is actually pragmatic. Instead of playing games and pretending we are going to be able to get everything right the first time and forever after in one or two iterations, with full documentation (that of course will never become obsolete)....we accept the reality that the path to hell is paved with good intentions. Build what you need now, extend it as it is used because after your first release (no matter how thoroughly planned) users will want to add to it and/or change it and/or will have decided they didn't actually need it and/or will now see what the planning was all about and now want to introduce the actual features they needed. Create as much documentation as you need now, instead of a bunch of diagrams that will become obsolete nearly immediately. Test driven by the way is a design methodology, not a testing methodology. BTW I love the criticism that Agile doesn't produce enough documentation -- ask the person who offers that up how much documentation they produce with the methodology they prefer and the answer is usually little to none.

Re: The Great Pyramid of Agile

2007-05-29 14:26 • by sammy (unregistered)
Perhaps I’m being a bit unfair nitpicking an Agile analogy. After all, the Agilistas contend that it works well and have whole handful of success stories to show for it. As for the cases of failure, the answer is overwhelmingly, “of course it didn’t work; the project didn’t have enough good people.”

And therein lies the problem: most developers are not good. By the very definition of the word "good," most people are average, below average, or just plain suck. There’s a word to describe products designed for the masses that work only for some: defective.

I started off being pretty jazzed about this post, but the farther I've gotten into it, the more disappointed I've grown.

Alex, you're asserting that Agile(like) development methodologies are "defective" because they only work for good programmers.

Either you think that the use of some kind - pick one - of methodology helps, or you don't. But, your paean to better education and quality control in the corps of developers out there aside, you can't seriously mean that these methodologies are "defective" just because it can't help bad coders.

By that logic, an F-22 is defective because I can't fly one, and a Ferrari Enzo is defective because the proprietors of shady game companies wrap them around utility poles.

Re: The Great Pyramid of Agile

2007-05-29 16:25 • by Sheik Yerbouti (unregistered)
As other people have pointed out, I stopped reading when I reached the idea of a pyramid with a square base. This is indeed a WTF, but probably not in the way that the author meant it. I suggest enrolling in an Agile programming class involving cubical blocks of concrete, the whips of overseers, and associated UFOs.

Re: The Great Pyramid of Agile

2007-06-02 09:06 • by Stallina (unregistered)
139825 in reply to 138543

Good developers write quality software (by definition). If a shop moves to Agile, it needs fewer overall developers, which means it can afford for all of its developers to be good. That is, as long as that shop is willing to invest in those good developers up front.

The problem with Agile is the opposite of the problem with RUP -- RUP provides some protection from bad developers, but also can prevent good developers from doing their best; Agile allows good developers to do their jobs effectively, but doesn't protect against bad developers.

Like everything else, a team must choose the right tool for the job -- if you have bad developers, and you can't get rid of them, don't try to use Agile. You'll fail.

Or, worse, you'll "succeed" in creating horrible (but up-to-spec) software.

Very good point, but...
Really good developers are extremely difficult to find. In my company there are around 200 software developers, 6 or 7 architects, 10 managers/team leads, and i know around 60 of them. Now how many of them are good? None. Well there used to be one, but he stayed for less than 1 month then quit.

From my experience (with a total of 6 employers), i can only remember one company who had a handful of really good people.

Birds of a feather flock together.

So what about me? I am NOT a good developer, but i know where i need to improve and am working hard at it. The only reason i'm staying in my current job is that it allows me to experiment with lots of stuff i want to learn. The sad thing is that not a single person around me could see the light.

Re: The Great Pyramid of Agile

2007-06-07 12:34 • by John (unregistered)
It's all about design. If you have people who can do it, then up-front design is obviously the right thing to do. Good up-front designs do not remove flexibility and responsiveness, they actually improve it due to greater understanding of the problem domain.

If you can't do design, then choosing between agile or waterfall is like choosing whether to barf in the sink or the bath - either way you'll end up with a mess to clean up and a bitter taste in your mouth.

Software people who can't do design like to hide that fact so they advocate methodologies that provide impressive looking results early on and then paint over the cracks that show up later using religious sounding dogma.

PS captcha is "stinky". How appropriate. Put those Kent Beck books back on the shelf and start learning engineering, people!

Re: The Great Pyramid of Agile

2007-08-22 16:03 • by Tony (unregistered)
150700 in reply to 138540
True, you do need good developers to write good code, and that's a key point, but what about everyone else you need to build a successful system, like testers, prodcut analysts and customers? Everyone seems hung up on developers. What are you going to build without input and how many of us have written code that works and integrates without rework. I'm not hung up on agile, I've seen it work and fail, but I am hung up on teams and eliminating waste in development efforts and that seems to be missing in the thread

Re: The Great Pyramid of Agile

2007-08-22 16:09 • by Tony (unregistered)
150704 in reply to 138571
I hope you're kidding. I'd like to see more talk 'about what needs to get done' and less code until you understand what you're doing. I think we have a few too many lines(*1000000) of unused or complex code floating around out there.

Re: The Great Pyramid of Agile

2007-10-02 11:34 • by David Longstreet (unregistered)
I thought you would enjoy a paper I wrote and presented at several conferences.

Agile Methods and Other Fairy Tales

The link is http://www.SoftwareMetrics.Com/Agile


David Longstreet
Software Economist

Re: The Great Pyramid of Agile

2007-10-11 15:08 • by Game programmer (unregistered)
We tried agile at a game company, and it bombed. Talk about tying up the hands of the superstar programmers, bogging them down in meetings, having them code to be ready for presentation instead of for customers. BLEH!

It bombed big time... Mostly due to some people that couldn't stand others not doing things their way and trying to dominate the desgins and meetings. People just ended up with argument fatigue and gave in until they found another job to go to.

Re: The Great Pyramid of Agile

2007-11-18 02:21 • by First and foremost... (unregistered)
First and foremost, it *is* possible to build a square pyramid sideways. Adding to two faces would add to its nice, square base.

Re: The Great Pyramid of Agile

2007-11-25 22:59 • by Brian Berenbach (unregistered)
When I was an architect, many years ago, I built software based control systems and simulators for power plants. The systems would be installed during an outage, and if the startup of the plant was delayed, penalties ran about 1 million dollars per day. Needless to say the systems were in and up on time.

What I have seen that causes failures (major overruns or cancellations) in big systems of all kinds is a lack of engineering knowledge. That is, the management of teams, the engineering of complex systems, the writing of unambiguous, correct and complete specifications, these are things that are neglected in university and consequently not understood by the computer science and other technical staff suddenly thrust into management positions.

Furthermore, understanding how to successfully build large/and or complex software based systems is learned by OJT, not be reading a book or spending a week getting a certificate. If you have never apprenticed at a senior level on a large successful project then your chances of succeeding in a senior management position of such a project are drastically reduced (near zero). While no one would expect an architect to read a book on bridge building and then manage the construction of a large bridge over a river, in the wonderful world of software, such assumptions are commonplace, e.g. i read Booch's book, so I am all set to build a big OO system.

I see agile as grasping at straws. That is, it is the placing of the seal of approval on a fudge, a grasping at straws.

Yes, agile will work, where the final product is very, very malleable and the staff is small, e.g. people sitting in a room talking to each other. Other than that, agile cannot work by definition. A software architecture is a complex thing, as the amount of code that is written goes up linearly, the effort to refactor goes up exponentially. That is, unfortunately, the way it is.

The only thing to date that has saved agile from a really, really bad reputation is the fact that the good lives on, and the bad (and believe me there is a lot of it) is buried with the accounting losses.

And that, ladies and gentlemen, is just my opinion.

Re: The Great Pyramid of Agile

2007-11-30 09:21 • by Pro-Pyramid (unregistered)
No analogy is perfect. The pyramid analogy is a useful tool for convincing people that conventional Waterfall methodologies are particularly problematic. Agile is an interesting alternative, all the same it's not specifically mentioned in Mayo-Smith's Information Week article.

Re: The Great Pyramid of Agile

2007-12-10 22:11 • by Kelli (unregistered)
165914 in reply to 138519
wow this is guy....screw this shit!

Re: The Great Pyramid of Agile

2007-12-16 21:50 • by Mayo-Smith was ahead of his time. (unregistered)
Mayo-Smith's article doesn't mention Agile and predates the Agile fad by several years.

You have to be good first at programming

2008-01-09 00:49 • by Andy Wong (unregistered)
Agile is good for understanding requirements and assist the customers to understand their own requirements. Agile can not help your programming and design skills. You have to be good first at programming and design, then you might be able to get benefits from agile practices.

Re: The Great Pyramid of Agile

2008-02-20 16:01 • by spinLock (unregistered)
Loved the message, but this part is just plain wrong: "the only way to lose weight is to eat less and exercise more."

The reality is that 'modern' food makes the vast majority of us fat (I know, I used to be in that majority). Now that I'm back to fresh fruits & veggies & home-cooked meat, I'm in the minority again.

Exercise is good of course, but if you're using it to maintain a healthy body weight, then see the above paragraph. I'm finally slim again, and haven't raised my heart rate above 100 bpm in probably 2 years.

Re: The Great Pyramid of Agile

2008-03-05 02:36 • by China (unregistered)
Good people can't always produce good code: as thedailywtf articles repeatedly show, there are many ways to impede good development. I think that the benefit and challenge of Agile is in removing as many of the impedences as possible while keeping the project focused.

Re: The Great Pyramid of Agile

2008-03-13 16:01 • by Jim Bolley, PMP (unregistered)
Agile has a Project Management Plan. They just don't want to write it down.

Agile has a Commumication Plan. They just don't want to write it down.

Agile has an HR Management Plan. They just don't want to write it down.

Agile has a Time Management Plan (Schedule). They just don't want to write it down.

Agile has a Scope Management Plan. (although different). They just don't want to write it down.

Agile has a Budget (Cost) Management Plan. They just don't want to write it down.

Do you get my drift? What is the common thread? Although they don't want to admit it, they do everything a Project Manager should do, they just don't want to write it down.

Re: The Great Pyramid of Agile

2008-05-27 03:42 • by Alex Glaros (unregistered)
I've been using a form of software development that I've learned on my own in the 1990's, that has some features similar to Agile. Can you please review it to see if it addresses some of Agile’s criticisms?


Alex Glaros

Re: The Great Pyramid of Agile

2008-05-27 09:04 • by Alex Glaros (unregistered)
196861 in reply to 196812
I've been using a form of software development that I've learned on my own in the 1990's, that has some features similar to Agile. Can you please review it to see if it addresses some of Agile’s criticisms?

Here’s the link:


Alex Glaros

Re: The Great Pyramid of Agile

2008-06-25 01:18 • by ELIZA (unregistered)
202279 in reply to 138567
I might buy into this analogy, if you were talking about building a pyramid on a former swamp that had been partially drained, in the middle of a continuous 7.5 earthquake. Because I don't know what kind of solidity your requirements and environment have, but that's approximately how mine are. Let's also throw in a request from the Pharaoh for a cubical tomb mid-project, because the market research says cubes are going places now and we can't afford to become #2.

It does occur to you that that would be specifying something that is apparently unachievable with the technology in question (ie, unmortared stone)

Re: The Great Pyramid of Agile

2008-07-05 04:58 • by Brill Pappin (unregistered)
204629 in reply to 138549
No, JamesKilton is correct.

It does work, but what he's saying (and I agree with) is that it's "a state of mind" or rather a *way* of thinking about and implementing the software you are tasked with.

Like most of us I've used several "methodologies" and as much "hacking" as anyone. but taken as a concept on how to write good code, Agile can help. The key however is getting the *point* of it rather than following some "agile bible" and that takes good people.

However, inexperienced people can improve if they have good people around to follow (true of anything and any method) and can do it quickly using agile ideas.

So far, I've been at many companies who claim they are "agile" but are no where close (somebody mentioned that sort of thing earlier) and in all cases it was because they just didn't get it... notice that I didn't say they were not good developers, just that they didn't get Agile; for those people and for those in this forum who don't get it (no shame on you), there is little point in trying to force yourself into the cold-press to conform... what your doing might be working for you, so keep your customers happy and keep doing it.

However, this is really all useless bunk anyway if we remember that most of the cost of a product is maintenance, the argument is only about ~20% of the cost.

We that understand Agile, will use *it* to keep our customers happy, as you will your own system.

Re: The Great Pyramid of Agile

2008-10-25 19:49 • by Emily (unregistered)
This is single handedly the worst methodology I've ever come across in all 10 years in IT consulting - especially on the large projects. Because where there are large projects, there are politics (I don't make the rules). This model acutally presumes it it can eliminate politics to produce results - and it does quite the opposite. Agile probably would works well for start-ups, but where there are large projects, there will be politics. This is a natural manifestation when there is a combination of expectation and dependence within a project. I work on an Agile project for a Fourtune 100 company, and will be leaving the project and possibly my job because of this crap practice. Just a trash fad which has made me hate going into work every day.

Re: The Great Pyramid of Agile

2008-11-18 15:42 • by Mr Anderson (unregistered)
Agile is an often mis-applied methodology, and it seems everyone wants to bash it because it doesn't work. It does work, but it's rarely done properly.

It's not easy, and it's not a panacea. It doesn't preach 'no documentation' or delivery without planning. On documentation, it recommends that you produce enough (but no more). Same with planning. The key word is enough. If you don't have enough, you fail. You fail not because you chose a bad methodology, but because you took a simple methodology, cherry picked the easy bits and ignored the difficult parts.

Agile is simple, but not easy.

A better analogy might be power tools. An electric jig saw might make cutting easier, but if you're a crap carpenter it just means you screw up quicker (or lose more fingers).

Re: The Great Pyramid of Agile

2009-02-25 16:21 • by Mark (unregistered)
I wonder if you've become a Scrum master yet? I enjoy reading these types of articles. Damon Poole at Accurev was a Waterfallian as well and is now an Agile proponent. You should have a chat with that guy.


Re: The Great Pyramid of Agile

2009-04-30 19:23 • by Rick (unregistered)
>>Andy Wong said:
Reply Quote

Agile is good for understanding requirements and assist the customers to understand their own requirements

The above is not true at all! On eof the principle of Agile is to make the story requirements vague and ambiguos so that open to the discusions.


2009-07-23 13:51 • by ������ʳ (unregistered)
��������<a href=>������ʳ</a>�����ν�����ʳ����ҵ������ʳ�ȵȡ�Ȼ��������ʳ��������ʳ�ճ���������˵�ġ�������ʳ��������ָ��ҵ������ʳ���Ͻ�ˮ���Ǻ���<a href=>��ˮ</a>��ҵ�Ż���վ,�ṩ���Ͻ�ˮ���żҽ罺ˮ��������˽�ˮ����ɳ��ˮ,������ˮ,��ɽ��ˮ��ȫ����Ľ�ˮ��Ϣ��վ.�й�<a href=>��ԭ����</a>�������ۺ��ԵĽ�ԭ������ҵ��վ,�����Խ�ԭ����ý�顢��ԭ���״��⡢��ԭ�����г��Ƚ�ԭ�������ºͽ�ԭ����������ȫ��������ݽ�ԭ���׷�,����԰��<a href=>��ԭ���׷�</a>ˮ��,ȫ����ԭ���׷۾Ƶ��Ż�Ԥ������ԭ���׷���·,��ԭ���׷۳���ָ��,��ԭ���׷����϶����й�<a href=>��ԭ������Ĥ</a>ý������Ϊ��ԭ������Ĥ��˾����ԭ������Ĥ��������ԭ������Ĥ��ҵ�����ҵ�ṩ���Ͻ�ԭ������Ĥ�����ṩ<a href=>��ԭ������</a>��ƣ����ὺԭ��������Ʒ���й���ԭ�������������һ��Ѱ�ҽ�ԭ��������еĵط����ṩ���м�ֵ�Ľ�ԭ��������ƽ�ԭ������Ʒ��̳,<a href=>��ԭ������Ʒ</a>�ɹ�,��ԭ������Ʒ�ͺ�,��ԭ������Ʒ����,���ԭ������Ʒ,��ԭ������Ʒ,��ԭ������Ʒ����,�󹺽�ԭ������Ʒ,�й���ԭ������Ʒ,��ԭ������Ʒ��Ϣ
�ӽ���������,<a href=>�ӽ�����</a>��վ����,�ӽ���������׬Ǯ,����ӽ����ش���,����ӽ����ع���ϵͳ,����ӽ����ع������

Re: Flawed assumptions

2009-08-21 08:30 • by Me, myself and I (unregistered)
282963 in reply to 138573
Nick Radov:
This editorial seems to be based on flawed assumptions. If you're just building yet another pyramid, then sure it makes sense to do the design work ahead of time and then implement it in a methodical way. The "pyramid" problem has been solved several times before, perhaps on a smaller scale, and the basic issues are well understood.

Where agile really becomes necessary is when you are trying to build something innovative that no one has done before.

You're right. But 80% at least of all code that's written is just interface code to database applications. What's so innovative about that? That's why I think it is only correct to assume agile methods are good only for a quite small part of the overall mass of software development projects - something you could call research. This is why I argue on using agile methods on a large scale - while they'll benefit research projects, they only decrease controllability and predictability for reinventing the wheel projects. And especially for projects of the latter type business aprpeciates predictability and controllability, especially at the cost of flexibility, and even at the cost of actual monetary cost.

Re: The Great Pyramid of Agile

2010-02-09 04:41 • by LED display (unregistered)
<A HREF="">LED display</A>
<A HREF="">LED Signs</A>
<A HREF="">LED Message display</A>
<A HREF="">LED Message Signs</A>
<A HREF="">LED board</A>
<A HREF="">LED curtain display</A>
<A HREF="">LED Soft curtain</A>
<A HREF="">LED soft display</A>
<A HREF="">LED display</A>
<A HREF="">LED Signs</A>
<A HREF="">LED message display</A>
<A HREF="">LED outdoor display</A>
<A HREF="">LED fullcolor display</A>
<A HREF="">LED board</A>
<A HREF="">LED message signs</A>
<A HREF="">LED panel</A>

Re: The Great Pyramid of Agile

2010-02-09 04:43 • by LED display (unregistered)
<A HREF="">LED display</A>
<A HREF="">LED Signs</A>
<A HREF="">LED Message display</A>
<A HREF="">LED Message Signs</A>
<A HREF="">LED board</A>
<A HREF="">LED curtain display</A>
<A HREF="">LED Soft curtain</A>
<A HREF="">LED soft display</A>
<A HREF="">LED display</A>
<A HREF="">LED Signs</A>
<A HREF="">LED message display</A>
<A HREF="">LED outdoor display</A>
<A HREF="">LED fullcolor display</A>
<A HREF="">LED board</A>
<A HREF="">LED message signs</A>
<A HREF="">LED panel</A>

Re: The Great Pyramid of Agile

2010-02-16 18:08 • by greg (unregistered)
Coding priests should give up on agile and turn to improving stamina and spell damage.

Re: The Great Pyramid of Agile

2010-09-18 07:21 • by Allan (unregistered)
322503 in reply to 138519
Re "evolutionary" software: the one thing evolution has in it's favour is TIME - and LOTS of it!

I believe you need to "bootstrap" evolution by having a fair degree of understanding of the customer's requirements early on (and by "fair degree of understanding" I do not necessarily mean 100%, but 80+).

One can't keep on breaking down and re-starting (re-trying?) every time you find out something new from the customer.

That's like evolution-by-failure: "something" will eventually result from all the retry-and-mishap-cycles... even if it takes a few million years...

Ans that is what software development seems to be suffering from.

Re: The Great Pyramid of Agile

2010-12-18 09:28 • by cindy (unregistered)
find for all kinds of watches and handbags

Re: The Great Pyramid of Agile

2011-10-19 21:28 • by John Quincy (unregistered)
If you haven't seen this video... it is very funny and yet so factual:


Re: The Great Pyramid of Agile

2012-03-18 00:06 • by Mark (unregistered)
377104 in reply to 138591

So you're saying most developers now are a bunch of sloppy H1 B's who can't write code, say isn't so ! I guess you get what you pay for !

Re: The Great Pyramid of Agile

2012-06-24 22:36 • by Buck Ofama (unregistered)
"Good people can build good software, no matter what methodology they use."


I was lately turned down for a Sr Jave dev role. Although the manager told the recruiter he wanted to hire me, later his dickhead weenie tech bully nixed it, ostensibly because I was "uncomfortable" with agile dev. Doesn't matter that the manager had previously told me they are working toward agility, but have a long way to go.

Re: The Great Pyramid of Agile

2013-11-20 12:34 • by kim johnson (unregistered)
421716 in reply to 138514
I was a developer for 10 years and hated process and management and people who didn't know anything running things.

The next 20 years I was a QA Director and I Was the guy doing the stuff I hated back then.

My conclusions after 30 years in the business and doing it both ways:

Small internal projects can be done fast and well with really good people and little process. Sometimes it gets screwed up. But it's usually small, didn't do too much damage (hopefully), and can usually be fixed fast.

But Murphy's law was created for Big Projects. Documentation (that useless stuff that tells you exactly what a system is supposed to do, how exactly it will be designed and tested) is GREAT (and cumbersome) on big complex stuff because everyone (painstakingly) knows what the hell they are doing and what to expect. And yes it takes MUCH MUCH longer and is a lot of paperwork.

Theory 1: I think there is another reason for Agile: to get rid of dumb, bossy managers. Who needs them making everyone's life miserable, calling meetings all the time, tracking stuff they don't even understand, and they can't even code themselves because everything has changed and they only know stupid COBOL! OK. OK. Well get rid of them and see what happens. I heard stuff like, "its supposed to work that way! That's the way the code was written", or "the true documentation is the code!" (but a) who else can read code but the developer and b) what if it was coded incorrectly?)

Theory 2: I think American culture consists of cowboys roping calves-rugged individualism stuff - "Look what I did!" Asian culture (e.g., Toyota)seems to me to be suited to working together closely as a GROUP. So we Americans have to, (for God's sake!,) change our mindsets, I think, to work in a group setting. That's why things seem to creep back to non Agile all the time, in my opinion, and why there is so much resistance to Agile. Should we go against our DNA? -or find ways to work with it instead? (Personally I'd rather row my boat downstream as opposed to upstream).

What I think is good about Agile:
- a POD-like space for collaboration and easy access to people BUT
- cubicles to do your quiet, hard thinking stuff (And be an individual too who can make a personal phone call in private).
- coming up with test cases during requirements and having the staff to do it (e.g., start an Acceptance Test document and get the code written to these test cases so it doesn't kick out at the end)
- automating early if you can (but it took us 10X longer to write automated test scripts compared to manual, and sometimes you couldn't even do it at all! Our automation (with 2 of 7 testers DEDICATED to it full time) was completed after the release went out and was just used for future release regression testing, mostly.

What I think is needed for Agile to work-
-exact requirements
-exact test case documents
-test EVERYTHING built,
-no late deliveries of code since it could break a lot of stuff already tested
-and after the last code is written test it again for anything even possibly suspected of being broken by a change.

Well, this goes against most of Agile!

WHY do I suggest this? Because users of software hate bugs-it screws them up royally- clobbers their files sometimes, stops them dead sometimes, requires them to get on the phone to figure out what to do. They also hate stuff that takes a long time to deliver, too. But I've seen more user infuriation and rework with bugs. We had to work around the clock looking for workarounds, finding and fixing bugs, and praying the fix didn't break something else. Who want's that? How do YOU like it if you download something and it blows up??

WARNING: After putting detailed, long processes in place you get award meetings and plaques when the 1st couple releases finally go out flawlessly, then people don't see bugs anymore, then think you can cut down on the processes since we don't have bugs anymore!!, and go back to crap releases again with new management installed to get it out fast (like it should!), then turn on you and blame you when it reverts to buggy (You didn't test it!!). Advice here: don't bother unless you get great management commitment to quality and the process you decide on (whatever it is: Agile, WaterFall or Water-Agile-Fall) - put it into a Quality Policy signed by the President if possible, and put it on the main hallway wall. Get signoff on a documented process too by him or her.

TIP: Management loves documented process so they have understanding of how things are done in their organization (and can modify something if they like): lots of brownie points for this!

Good luck whatever you decide.
« PrevPage 1 | Page 2 | Page 3 | Page 4 | Page 5Next »

Add Comment