Re: An interesting rebuttal of "agile"

... I placed limits on the scope and schedule of our software releases. Until this point, my team and the NIH had boasted about their ability to release new software daily, claiming that this release rate reflected their flexibility and agility. I was convinced – and was later proved correct – that this daily rate was symptomatic of the lack of process control.

To my mind, software goes from a development build, to a milestone build and finally to a release build.

Each of those stages needs more rigorous QA than the previous level. I can imagine a team that would produce a development build every day. I can't imagine a milestone build every day, and a full release, every day, is ridiculous.

For me, agile development means that you can get a framework of the application up in a few days or weeks, and that bugs can be fixed and new features can be added fairly easily. It doesn't mean daily releases.

The only exception to this that I can imagine is if you have some kind of rolling development going on, where teams leapfrog each other, and the releases are from alternating teams. I'm not sure that's practical in the field of software development.

This sounds like some CIO's 'idea' of what agile is -- someone who hasn't done actual development in 5-10 years, or maybe has never done software development, but 'knows' what the right approach is.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Comment on Re: An interesting rebuttal of "agile"

Replies are listed 'Best First'.
Re^2: An interesting rebuttal of "agile" by chromatic (Archbishop) on Mar 17, 2008 at 17:35 UTC
To my mind, software goes from a development build, to a milestone build and finally to a release build. ... Each of those stages needs more rigorous QA than the previous level. Why? I prefer to move QA into the development process itself (from the design stage through implementation and to exploratory testing) in order to avoid all of the falderol around different types of builds.	[reply]
Re^3: An interesting rebuttal of "agile" by Corion (Patriarch) on Mar 17, 2008 at 17:39 UTC
If you have the resources to constantly do user acceptance testing, all the power to you. But there are others who have to live with restrictions such as limits on available resources, yet still have to provide a process that enables them to put software releases into production.	[reply]
Re^3: An interesting rebuttal of "agile" by talexb (Chancellor) on Mar 19, 2008 at 03:21 UTC
I prefer to move QA into the development process itself (from the design stage through implementation and to exploratory testing) in order to avoid all of the falderol around different types of builds. If you have the resources to do a full, soup to nuts QA run through at every step of the development process, then, in my opinion, you're either overstaffed or some people need reassignment. In my opinion, you need to do a development build when you've completed a significant piece of code and need to 'draw the line' somewhere; that's at the discretion of the development team. About the only QA that happens on that build is something like a) check that all the files are there; b) check that all the tests pass; c) check that it installs and runs through a few basic user acceptance tests and is usable for further development. A milestone build is the next level up, and requires an actual collection of features and bug fixes that may end up being a release. That's probably triggered by the project manager. All of the development testing is performed, as well as more rigorous testing of the new features and bug fixes by an internal QA person. A release build is a really, really clean milestone build that's been tested even more throughly. Code reviews have been done on the changes, and perhaps an outside QA team has also tried it out and liked it. This is blessed by the director of development. A release build is one that's finally released to the client. Alex / talexb / Toronto "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds	[reply]
Re^4: An interesting rebuttal of "agile" by chromatic (Archbishop) on Mar 19, 2008 at 05:27 UTC
About the only QA that happens on that build is something like a) check that all the files are there; b) check that all the tests pass; c) check that it installs and runs through a few basic user acceptance tests and is usable for further development. I'm not going to waste my team's time wondering if the code works and is acceptable to the customer by throwing a binary wad over the wall to a bunch of pixel-clicking monkeys once a month, or once a quarter, or whenever. I want to know that we could take whatever's on the trunk and hand a CD to our customer within two hours, and he or she will be happy with the results. Any development process with a wall between QA and developers has at least one huge flaw, in my opinion -- it takes way too long to know if you've built the right thing.	[reply]
Re^5: An interesting rebuttal of "agile" by talexb (Chancellor) on Mar 19, 2008 at 13:42 UTC
Re^6: An interesting rebuttal of "agile" by chromatic (Archbishop) on Mar 19, 2008 at 18:21 UTC
Some notes below your chosen depth have not been shown here


Perl Monk, Perl Meditation
	PerlMonks