Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Becoming Agile

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Books 193

IraLaefsky writes "The appropriately titled Becoming Agile: In An Imperfect World by Greg Smith and Ahmed Sidky offers a realistic path to the family of Agile practices which have become prevalent in software development in the last few years. This family of approaches to software development has been widely adopted in the past decade to replace the traditional Waterfall Model of software development, described in a 1970 article by Winston W. Royce 'Managing the Development of Large Software Systems.' The Waterfall Model stressed rigid functional and design specification of the program(s) to be constructed in advance of any code development. While the this methodology and other early formal tools for Software Engineering were infinitely preferable to the chaos and ad-hoc programming-without-design practices of early systems, these first tools ignored the fallibility of initial interviews used to construct initial design and often resulted in massive time and cost overruns." Read below for the rest of IraLaefsky's review.The Agile methodologies which are described in this text stress an iterative approach to software development, with the continuous involvement of users (or user surrogates). These iterations consist of several week periods (to at most two month intervals) where a concise partial design requirement, story, is translated to a complete executable version of the program which can be demonstrated to users, for their immediate and anticipated criticism and controlled feature addition. These practices have undergone various codifications since the Agile Manifesto of 2001. Among the more popular Agile Menthodologies are Extreme Programming (XP), Crystal Clear and Scrum.

In describing these development methodologies this practical handbook takes an approach sorely needed in descriptions of Information Technology (IT), it assumes that the purchaser is considering employing the technologies described within the context of a real corporate environment with existing strengths and limitations, an existing approach to the problems addressed, and cultural biases concerning the adoption of new technologies. This approach enables the book to be used as a virtual consultant, taking the experiences described in a case study based upon the authors' advisory experience, and the test of organizational readiness for adoption and needs for customization of the technology as true guideline for introducing these practices in culturally and technology appropriate fashion. During the mid 1980s I served as an internal consultant at a large insurance firm, at the time we were considering the introduction of Expert Systems methodologies into the IT organization. I purchased several handbooks which were intended to introduce this new from academia technology to companies in the financial industries. Most of these books did an adequate job of describing the nature and basis of this technology to IT and Business Analysts trained in existing technology. But, all of the available books failed to chart a path for an IT organization with traditional development practices to successfully migrate to the new technology and appropriately translate this technology for business management. Becoming Agile, introduces a new effective method for describing the risks, benefits and appropriate adaptation of a radically new technology to organizations with existing successful and unsuccessful software development practices and a particular business culture.

Important features of this guide include the Sidky Agile Measurement Index (SAMI) which provides guidelines in moving your particular organization to Agile practices, the non-religious presentation of multiple Agile methodologies and approaches (specifically XP and SCRUM), appendices on organizational readiness assessment, phased development within the Agile context, an overview of the Agile process (suitable for business presentation), and the author forum. The importance of recognizing that new technology methodologies such as Agile Practices must be introduced and carried out in the context of a specific organization, with its own strengths and foibles, cannot be overemphasized. Step-by-step directions and illustrations are given for choosing an appropriate target application for the initial introduction of these methodologies, and each stage of implementation and their possible stumbling blocks are carefully outlined.

That it provides the tools to introduce and adapt these practices in a variety of corporate cultures, with varying degrees of technical sophistication is an invaluable advantage over other Agile texts and will save the organization many thousands of dollars in consulting fees. My only minor nit with this exceptionally fine introduction to Agile Methodologies is that some of the illustration appear to have been formatted in PC-based tools such as VISIO and PowerPoint and require a bit of squinting to study in the smaller book format. With this trivial exception I would award this excellent guide and virtual consultant, an almost perfect nine out of ten review, and recommend it to any organization seeking to intelligently adopt Agile Practices.

The print edition is available at all retailers, while the ebook can be purchased exclusively through the Manning E-Book Storefront.

You can purchase Becoming Agile: ...in an imperfect world from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

193 comments

PDF of old paper was Slashdotted! (0)

Anonymous Coward | more than 4 years ago | (#30115836)

Here's a little snippet. My secretary had it pulled up on his screen.

MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS
Dr. Winston W. Rovce

INTRODUCTION
l am going to describe my personal views about managing large software developments. I have had
various assignments during the past nit,.: years, mostly concerned with the development of software packages
for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced
different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have
become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.

COMPUTER PROGRAM DEVELOPMENT FUNCTIONS
There are two essential steps common to all computer program developments, regardless of size or
complexity. There is first an analysis step, followed second by a coding step as depicted in Figure 1. This sort
of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the
final product is to be operated by those who built it - as is typically done with computer programs for internal
use. It is also the kind of development effort for which most customers are happy to pay, since both steps
involve genuinely creative work which directly contributes to the usefulness of the final product. An
implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed
  to failure. Many additional development steps are required, none contribute as directly to the final product as
analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay
for them, and development personnel would rather not implement them. The prime function of management
is to sell these concepts to both groups and then enforce compliance on the part of development personnel.

I read through several pages and glossed through the rest. Good ideas consider how far this goes back. Definitely worth the read IMO.

fresh piss (-1)

Anonymous Coward | more than 4 years ago | (#30115884)

frist post

Methodology fads (5, Insightful)

davidwr (791652) | more than 4 years ago | (#30115892)

Every decade or generation management and process fads change. All of them have their faults and all of them have their benefits, and none are ideal for all situations.

I wonder what the fad of the 2020s will be?

Re:Methodology fads (3, Insightful)

truthsearch (249536) | more than 4 years ago | (#30115962)

I see changes in the software development process as more of an evolution than a fad. The needs of management and end users change, so the process changes with it.

Re:Methodology fads (0)

Anonymous Coward | more than 4 years ago | (#30116196)

I see changes in the software development process as more of an evolution than a fad. The needs of management and end users change, so the process changes with it.

Does it really change that much? I sell webdesign and software/database development in Bali, (Developing world) ... Is there really another way to go besides "
methodologies which are described in this text stress an iterative approach to software development, with the continuous involvement of users (or user surrogates). These iterations consist of several week periods (to at most two month intervals) where a concise partial design requirement, story, is translated to a complete executable version of the program which can be demonstrated to users, for their immediate and anticipated criticism and controlled feature addition."

feel free to contact me at admin@kintabantu.org

Re:Methodology fads (1)

AnotherShep (599837) | more than 4 years ago | (#30117130)

Ask again in ten years.

Re:Methodology fads (2, Insightful)

teh_commodore (1099079) | more than 4 years ago | (#30116120)

Most of the developers I know (myself included) should just be placed in a box with a spec sheet and left to code. All of this process mess is for the management and the "architects."

Re:Methodology fads (1)

truthsearch (249536) | more than 4 years ago | (#30116876)

That would make you a programmer. A software developer [docforge.com] is often involved in more than just programming.

Re:Methodology fads (2, Insightful)

pnewhook (788591) | more than 4 years ago | (#30117640)

That is a "throw it over the wall" approach which time and countless failed programs have shown *DOES NOT WORK*.

Re:Methodology fads (1)

cheshiremoe (1448979) | more than 4 years ago | (#30119298)

Agreed! Any time you get beyond small scale or low complexity, it fails to deliver on time, the features actually don't meet the business needs or the need have changed. You can't hit the moving goal if it takes a year and a half or more to get your project through the development cycle.

Re:Methodology fads (0)

Anonymous Coward | more than 4 years ago | (#30117848)

Architects are also developers. This agile process is largely concerned with how to get you that spec sheet in the first place.

Re:Methodology fads (1)

quanticle (843097) | more than 4 years ago | (#30119026)

But what do you do if the spec. sheet is wrong? What do you do if the spec. sheet is unclear? How about if you can't meet the requirements given by the time specified? Methodology answers all those questions.

Re:Methodology fads (1)

Austerity Empowers (669817) | more than 4 years ago | (#30116252)

I don't know, but 6 sigma has gone retro here. Here's to 2020 being late 90's dot com chaos!

Re:Methodology fads (1)

Alphager (957739) | more than 4 years ago | (#30116292)

I don't know, but 6 sigma has gone retro here. Here's to 2020 being late 90's dot com chaos!

Yeah, this time i will cash in and charge six figures for the 2020-equivalent of HTML!

Re:Methodology fads (2, Insightful)

Trepidity (597) | more than 4 years ago | (#30116324)

They even seem to come with the weird religious rhetoric, too, promising that if only you embrace $Methodology, your life will change. Well, except the ultra-oppressive ones like CMMI: it demands that you accept CMMI or be destroyed.

It seems to be a fact of life that these things are going to float around, so I guess what makes sense is figuring out which ones are relatively better or worse, and what ideas from them are relatively useful or not. As (excellent tech blogger) YosefK put it [yosefk.com] in a review of an Extreme Programming book:

This quote is right from the book cover. "Extreme Programming Explained. EMBRACE CHANGE." Does it freak you out the way it freaks me out? Maybe it's because of the cultural gap created by my Russian origins? Nay, I know plenty of English slogans I can relate to. Say, "Trust a condom". Beats "Embrace change" hands-down. Changes come in two flavors, good and bad. Should I "embrace" both kinds?

[...]

"The key to XP is integrity, acting in harmony with my true values The past five years have been a journey of changing my actual values into those I wanted to hold."

"Journey". Talking about being good. Do you like hippies? I like hippies more than nazis. I like XP more than CMM. But IMO the hippie world view and general style is suboptimal.

Re:Methodology fads (1, Informative)

Anonymous Coward | more than 4 years ago | (#30116534)

I miss the Extreme Programming fad.

Coding while bungee jumping was really cool.

Re:Methodology fads (1, Insightful)

Angst Badger (8636) | more than 4 years ago | (#30116326)

I wonder what the fad of the 2020s will be?

I'm almost certain that the language fad will be functional programming, unless of course something even bigger and sloppier comes along to counteract Moore's Law. The management and process fad? Who cares? Except for a lucky few, we'll all have to nod and smile and suck it up until the next silver bullet comes along.

Re:Methodology fads (0)

Anonymous Coward | more than 4 years ago | (#30118064)

> Except for a lucky few, we'll all have to nod and smile and suck it up until the next silver bullet comes along.

Agile may be the "gold standard," but it's no silver bullet.

Re:Methodology fads (4, Insightful)

b4dc0d3r (1268512) | more than 4 years ago | (#30116356)

The only Agile Programming method is to trust your workers, and give them what they need to get it done.

My company said it was agile, but every process was waterfall with the names changed. More gates, more reviews, more layoffs and offshoring.

I could support my application 100% and have time for other development, but instead I have to train other teams (10 people at least at this point) and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.

Trust your coders, give them access they need. Then, when someone inevitably breaks your rules, hold them accountable. That's the key. Don't change the rules for everyone so you can answer "What have you done to prevent this from happening again?" The answer should be "We enforced our current policies, the person has had all access stripped, then terminated, and a reminder sent out."

I can't do agile development if .NET has built-in limitations which require a change request to an offshore server admin support group that doesn't even work my hours. So I sit idly until the workday ends, wake up the next morning and realize the sa team wants more information. I just bypass the whole thing and develop locally, but I can't always demo locally. If I could configure the box myself, I'd be able to document what I did so I can make an implementation guide, but I can't even do that - the dev servers are locked down. I am expected to document steps that I can't perform myself, nor test. That adds time to development.

Trust your coders, work closely with them, and get something working. Then plan for changes, because there will be design updates as well as requirement updates.

It all boils down to hiring people who can code either quickly or generically, so that when something changes they can respond - and then allowing them to respond.

Re:Methodology fads (3, Interesting)

Anonymous Coward | more than 4 years ago | (#30116946)

Fully agree with you on this. What the Agile process has shown me so far is that its a very fragile process, where the management want to break down the developers to the point of making replaceable parts of even the very best programmers. Add the war room to the mix, keep poking developers to "what I did yesterday, what I'm going to do today, whats holding me back" daily even when there is no work planned, so that you keep every one in check, all the time. Every job in the world has some slack built in, so you get to try something new, learn a new tech, etc, but with not Agile. They treat you like a disposable contractor that can be replaced any time. Working in a war room is not only very distracting, but also makes it very hard to look for other jobs since answering phone is going to be hard without causing suspicion.

Re:Methodology fads (1)

quanticle (843097) | more than 4 years ago | (#30119096)

As far as answering the phone goes, it helps to give out your cell phone number to prospects, so that, when they call, you can step out of the room as if you were discussing a private issue with a friend or a family member.

Re:Methodology fads (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30117280)

As a technical writer, I can see producing user documentation in small software projects using Agile is possible, but my experience in large, enterprise projects is that Agile is outright hostile to multi-layered user documentation.

Providing estimates on how long it will take to write and produce podcasts DURING THIS SPRINT -- for a feature the developers may or may not deliver, ... meh.

Re:Methodology fads (2, Informative)

ducomputergeek (595742) | more than 4 years ago | (#30117370)

We're a small company, so we can probably get away with it, but I require my coders to show up twice a week to the office for regular meetings and then be available if something comes up. All our code is either in SVN or Git repositories depending on the project. (Our Java team likes SVN, the web development team likes Git. Usually one isn't dealing with the other). We just come up with a list of milestones and due dates and then I get out of their way. Once a new feature is added, we test for bugs, and usually the last week of the month is documentation.

Re:Methodology fads (1)

MartinSchou (1360093) | more than 4 years ago | (#30118594)

and produce enough documentation that they can fire me when I get too expensive and hire a homeless guy to replace me.

Or find someone who can quickly pick up the work, when you inevitably die horribly in a plane crash on New Years, when the commercial airliner experiences a catastrophic failure and both sets of stabilizers snap off, causing it to crash right into your living room.

It's terribly precise, I know, but hey - you were being overly paranoid.

Re:Methodology fads (0)

Anonymous Coward | more than 4 years ago | (#30116762)

Don't mistake a "fad" with just how things are done during a particular period of time, due to the knowledge and technology that was available then.

Traveling long distances by horse wasn't a "fad". Before trains, automobiles, and planes were invented, it was the only reasonable method available, even if we drive cars now.

Ruby on Rails is a "fad". Everything we can do in Ruby using Rails could be done using Perl, Python, PHP, Java, C#, and almost all other languages, using a variety of different frameworks. It's just that Ruby got lots and lots and lots of hype online from stupid college students, HR idiots and managers who were more concerned with being "trendy" than with efficiently producing high-quality software.

Agile methodologies are clearly not a fad. They have allowed us to build larger and more complex software systems using fewer resources. This was something we could not easily do before, using existing methodologies, and even today we have few alternatives.

Re:Methodology fads (1)

maxwell demon (590494) | more than 4 years ago | (#30118938)

Whatever it is, it will certainly (again) not replace whatever was in use before, but the waterfall process. Every method always is intended to replace the waterfall process. If the waterfall process survived so many alternate methods, it must be really good!

Waterfall (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30115894)

Waterfall crushes a piece of my soul every day.

Re:Waterfall (3, Interesting)

MadKeithV (102058) | more than 4 years ago | (#30116266)

Interesting history: The original description of the "waterfall" methodology was actually used as an example of *bad* methodology: http://en.wikipedia.org/wiki/Waterfall_model [wikipedia.org] .

Oh, THAT strawman (4, Insightful)

Moraelin (679338) | more than 4 years ago | (#30115930)

Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way. Ever heard of iterations? Right. Apparently the agile crowd still never heard that anyone else uses those.

Re:Oh, THAT strawman (5, Informative)

Anonymous Coward | more than 4 years ago | (#30116036)

I'm uncertain as to what waterfall means where you work...but despite loud protestations from several developers...where I work, it means precisely the caricature that we Agile folks oppose. And it's basically mandated that a formal, pre-planned, no-iterations "waterfall" approach is used, as per the guidelines pushed by PMI and CMMI. I wish you were right...but it ain't a strawman.

The strawman moonlights as a consultant (0)

Anonymous Meoward (665631) | more than 4 years ago | (#30116596)

Reminds me of a gig I held a few years ago. We had 2 software dev sites for a particular product line, one in the southeast USA where I still reside (5 developers) and one in Silicon Valley (about 20). A software manager out west, who fashioned himself to be a "player" (but who was really just a jackoff), decided that we needed a software methodology. He talked to a consultant. The consultant said that Agile was crap, and that as a publicly-traded firm we really really should get CMMI certification.

Of course, I did some research into this at the request of my manager as well, and found out that our group was really using Agile methodologies. We just didn't bother to label it. We had lots of testing, short tight cycles, stand-up meetings, and so on. And guess which group was the only one that met its target delivery dates?

Unfortunately, the company HQ was in Silly Valley, so guess who's opinion was echoed throughout the halls of the organization?

(Sadly, there's no ending to this story, since both teams, including myself, my manager, and the player, were let go before the plans could ever be hatched. Stupidity ran really deep in that company back then.)

What did I learn? Simple:

  1. Any moron can call himself a consultant.
  2. Only a moron heeds the advice of a consultant without question.
  3. You are not automatically smarter or more effective because your ZIP code begins with a 9. You may in fact just be a complete fucktard.

Actually, yes, it's a strawman (3, Interesting)

Moraelin (679338) | more than 4 years ago | (#30116604)

Actually, I hope you realize that -- since it's referenced even in the review here -- the 1970 article by Royce which described it (albeit not actually using the term "waterfall") was a description of a dysfunctional process which doesn't work right for software. That article wasn't a formalization of the waterfall model, but a critique of it. (And a modification to something that works better, at that.)

It's not even the only one. Several authors and books exist about making software development work, _long_ before there even was such a thing as the XP manifesto or the word agile.

So at the very least we have the first strawman: that we needed the Agile crowd to come along and wake us up to the fact that the waterfall doesn't work. It was widely known that it doesn't work, at _least_ since 1970. You know, the fun times before microprocessors and personal computers and when even Unix was still just a cutesy personal experiment.

The model actually doesn't come from computing but from RL construction and partially manufacturing. That's the place where the costs get prohibitively higher if you discover a mistake after you built the whole building. And while _some_ misguided MBAs have always tried to treat programming like a generic assembly-line operation -- including using methodologies like this one, which are utterly inapropriate -- it's hardly been the standard, de facto and de jure methodology in computing. The pretense that somehow if you're not doing a crap^H^H^H^H agile job, you're one of those using the waterfall model (never mind that it was discredited for 3 decades already) is the strawman that irks me the most. Yes, some islands of insanity exist. You have my sympathy if you work for one. No, it's not the standard in programming. No, we don't need a wakeup call or extreme methodologies to know it doesn't work. We knew that already. At least since 1970.

And in reality even the places which go somewhat waterfall-y... well, let's just say that any place that's ever had a change request or made a version 2.0 of a product, essentially has iterations. Not the best form of them, to be sure, but it is iterations. Requirements change after code has been written too.

Re:Oh, THAT strawman (2, Informative)

natehoy (1608657) | more than 4 years ago | (#30116622)

If your CMMi consultants are pushing waterfall as official CMMi canon, you might want to find yourself a new batch of CMMi consultants. CMMi is about being able to measure and manage your work, not about using a specific methodology to do so.

But a lot of it depends on the size of the company and the average project size. If I have an estimated 2-month effort and 4 programmers (all internal), it's unlikely in the extreme I'm going to deal with the complexity of an iterative model. Plain old waterfall fits that bill pretty well. If the project is a lot larger, I'm either going to break it into phases/subprojects (waterfall's "iterations") or go with a more flexible approach.

Re:Oh, THAT strawman (1)

pnewhook (788591) | more than 4 years ago | (#30117950)

I'm uncertain as to what waterfall means where you work...but despite loud protestations from several developers...where I work, it means precisely the caricature that we Agile folks oppose. And it's basically mandated that a formal, pre-planned, no-iterations "waterfall" approach is used, as per the guidelines pushed by PMI and CMMI. I wish you were right...but it ain't a strawman.

This is ridiculous. And shows a lot of developers simply dont understand processes.

1) nothing in waterfall mandates that it cannot be iterative. In fact it *must* be iterative, allowing you to jump up levels as well as flow down. Thew waterfall levels simply are to be used as milestone gates so progress can be measured. Companies simply cannot work with the 'just give me unlimited funds and resources, leave me alone, and I'll get you the product sometime" approach that some so called agile developers think that is what agile is all about. Grow up thats not going to happen.

2) Agile is nothing new. It basically describes a method to work together. Other engineering disciplines have been doing this for years and it is NOT incompatible with waterfall.

3) CMMI does not mandate a specific process. It just tells you to document what you are doing, follow that process, and feed back the results to improve the process. If you want to document waterfall, agile, or pull it out of your ass as your standard process, thats fine. CMMi doesn't care as long as it is documented, everyone understands it, and results are fed back to improve the process.

Re:Oh, THAT strawman (0)

Anonymous Coward | more than 4 years ago | (#30118446)

As the poster who claimed it wasn't a strawman...

1. I agree that this is ridiculous. However, it's also the reality in my $600M/y IT department.

2. I read Royce 1970. I agree it's a model for what doesn't work. Doesn't mean it's normally used that way.

3. Waterfall-ish approaches ought to be iterative. I agree. Enough phase-gating, Change-boards, and weight of documentation, however, and it becomes infeasible to go backwards up the chain. In addition to Agile advocacy, I've also pushed iterative methods (most of Agile's value comes from early prototyping for risk purposes)...and those don't float here either. Waterfall, 1 way.

4. Agile is effectively Lean process applied to software, but developed independently. Lean/Agile, and modern decision science note that it is usually stupid to make decisions before the "last responsible moment". Waterfall asks for LOTS of decisions to be made LONG before the last responsible moment.

5. In theory, CMMi doesn't mandate a specific process. In theory PMI permits rolling wave project management. In theory, you could do the same thing with C++ Template functions. In theory, theory is the same as practice. In practice, practice is different, C++ Template functions will bite you in the ass, and CMMi and PMI advocate Waterfall processes.

Re:Oh, THAT strawman (1)

pnewhook (788591) | more than 4 years ago | (#30118828)

Waterfall-ish approaches ought to be iterative. I agree. Enough phase-gating, Change-boards, and weight of documentation, however, and it becomes infeasible to go backwards up the chain

Waterfall is iterative. If your company implements it stupidly then thats not the fault of the process model, just your implementation of it. Each gate does not require 100% completion of the current phase before starting the next phase, you just need to complete enough to reduce the risk of proceeding. Good guidelies are PDR you need 60% of high risk design completed, CDR 80%.

Waterfall asks for LOTS of decisions to be made LONG before the last responsible moment.

No, noly the high risk. And if you can't decide on things like basic architecture early in the program, then you shouldn't be deciding the architecture.

CMMi and PMI advocate Waterfall processes

No they do not. They advocate documenting your process, then execute your process. The process you choose to document is irrelevant.

Re:Oh, THAT strawman (5, Informative)

Anonymous Coward | more than 4 years ago | (#30117952)

Shows what you know about PMI then. In fact, right up front in PMI's definition is that a project is "progressively elaborated."

Both are perfectly at ease with an iterative model, simply noting that

1) each iteration is itself a project (or at least: a project phase which requires most of the same initiation, planning, execution, monitoring & control and closing disciplines as a whole project)

2) if you're changing your mind as you go along, there's a real Risk that you'll have to rework earlier outputs to suit later decisions, with impacts to some or all project constraints.

But of course, handling Risk within a mature framework - like PMI's - you'll be able to assess this against the Risks of not doing this, and understand which - in any given situation - is the better option.

In fact, I'm still trying to see one Agile practise that is unique and couldn't be applied to any other project:
* Daily standup meetings? Check
* Ongoing stakeholder involvement? Check
* Defining tests as a way of validating Quality (ie that the product meets requirements)? Check
* Delivering end to end working software each release/iteration? Check
* Late changes in requirements? Check, but each one has a real decision about whether the impact of it is worth the benefit
* Trust of the individuals & Self-Organising teams? Check - good old McGregor's Theory of Y (as described in PMBoK)
* Co-location? Check

And far too often, I've seen Agile used as an excuse for cowboy coding and sheer laziness in producing any documentation (try getting your AMS team to support a complex system and diagnose a production outage based on Googlechat records); I've seen developers rush for it as a simple power grab (but hey, everyone thinks they should be in charge), which is slightly better than rushing for it because it's trendy; I've seen Agile projects swallow 10s of millions of dollars with no business benefit (and yes, I've seen waterfall projects do the same).

While Agile is a particularly useful approach when dealing with customers who genuinely can't know their destination until they're along the track of discovery, and so evolving requirements within the project lifecycle are really called for (User Interfaces being a major example), generally it's not development's responsibility to cover up for customers' failure to plan and decide.

And to anyone who's done a few Agile projects with teams of 5, or 10, or 50... come back and boast when you've done something *hard*. As the classic book on the PMP exam says: it tests from the perspective of a large project, that involves 200 people from many countries, takes at least one year, has never been done before in the organisation and has a budget of US$100m or more.

When you've done that kind of project, come back and complain about PMI's methodology.

Re:Oh, THAT strawman (1)

pnewhook (788591) | more than 4 years ago | (#30118430)

In fact, I'm still trying to see one Agile practise that is unique and couldn't be applied to any other project:

And far too often, I've seen Agile used as an excuse for cowboy coding and sheer laziness in producing any documentation

When you've done that kind of project, come back and complain about PMI's methodology.

An excellent response. FINALLY someone who understands correct methodology. Too bad you responded as AC, I'd mod you to the roof.

Re:Oh, THAT strawman (0)

Anonymous Coward | more than 4 years ago | (#30118136)

Sicne when does the PMI not cover iterations? You need to re-read PMBOK or STFU. (An I'm not fan of PMI but I hate FUD mroe)

Agile is a crock. It's a fantastic trick developers have used to get away with never having to promise to deliver anything specific in any given timescale. 'We're not sure what we're going to develop yet, or when we'll deliver it, but I promise you when we do deliver it it's what you want'. That's no use to anyone.

Waterfall has many faults but agile is not the solution.

And BTW - people shouldn't blame a project delivery methodology for an infrastructure control methodology. Other posters are complaining that servers are supported off-shore which slows dev right down. It's true it does - but that's nothing to do with agile or waterfal development techniques.

strawman strawman (1)

avandesande (143899) | more than 4 years ago | (#30118508)

We are a CMMI level 3 certified shop and use agile development.

Ah well... (2, Funny)

Anonymous Coward | more than 4 years ago | (#30116394)

When you use the Waterfall Model there's bound to be some splashback...

Re:Oh, THAT strawman (0)

Anonymous Coward | more than 4 years ago | (#30116598)

I don't see why people criticize C for poorly supporting object-oriented programming when there have been a number of languages that build on C that have supported it for years.

Re:Oh, THAT strawman (1)

deoxyribonucleose (993319) | more than 4 years ago | (#30118906)

Oh, right, yet another valiant effort at demolishing a strawman of the Waterfal Model... which never really meant the carricature opposed by the "agile" crowd, and wasn't applied that way. Ever heard of iterations? Right. Apparently the agile crowd still never heard that anyone else uses those.

Congratulations on never having been exposed to the literal waterfall. In other news, it's still very much alive and kicking, despite the intent of the original paper to promote the spiral (incremental) model. (Hint to moderators: change parent from +5 insightful to +5 painfully funny.)

Become Agile By (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30115938)

NOT using MicroCRAP [microsoft.com] .

Yours In Olenegorsk,
Kilgore Trout

The first step to becoming agile (5, Funny)

Fear the Clam (230933) | more than 4 years ago | (#30115942)

Put down the Cheetos, lard-ass.

Re:The first step to becoming agile (1)

L4t3r4lu5 (1216702) | more than 4 years ago | (#30116216)

Indeed. Everyone knows Ballet dancers get the hot chicks in college.

Here are a few criticisms... (5, Informative)

Spy der Mann (805235) | more than 4 years ago | (#30116060)

Re:Here are a few criticisms... (1)

pijokela (462279) | more than 4 years ago | (#30116532)

The first link bashed XP because the writer feels that it is possible to spec everything up front. When the specs are done right (i.e. by him?) they are correct and implementation will be a stroll. If it is possible to completely spec the software before hand then, yeah, there is no need to be able to change it and therefore agile is not needed.

The second link bashed something called "agile" and promoted something else called "google agile" that sounded just greasy. Sure it may work for Google, but how many companies look like Google? The funny thing is, he really doesn't describe google agile that much at all: where do the requirements come from?

Can I have better criticisms, please.

Re:Here are a few criticisms... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#30117278)

Agile has turned out to be the worst of Micromanagement. Make replaceable parts out of every developer. I doubt developers will be motivated to dig their own graves.

http://en.wikipedia.org/wiki/Micro_Management

Ah, a new entry (2, Insightful)

HangingChad (677530) | more than 4 years ago | (#30116092)

A new entry for you Buzzword Bingo cards. The big question is whether "Agile Computing" and "Agile Development" should be separate squares or lumped under "Agile"?

I vote for a single "Agile" square.

Ad hoc is best (5, Insightful)

etymxris (121288) | more than 4 years ago | (#30116098)

The best programmers utilize domain specific knowledge gained through years of experience to perform the project design and development tasks that make sense. Trying to generalize one model to fit all domains is doomed to failure. Mainframe COBOL screens work differently than web screens which work differently than low level screen drivers and so on.

If you're starting work in a new domain, no methodology is magically going to make things work. New domains of development require plenty of experimentation and failure. How to best build the project is going to depend on what comes out of that experimentation.

And above all, the most important factor is people. You need smart people. No amount of clever methodology is going to make mediocre programmers create a great project. And for smart people, SDLC usually stands in the way of what they already know works best.

Re:Ad hoc is best (1)

tedgyz (515156) | more than 4 years ago | (#30116974)

And above all, the most important factor is people. You need smart people. No amount of clever methodology is going to make mediocre programmers create a great project. And for smart people, SDLC usually stands in the way of what they already know works best.

Well said! In fact, in my 25+ years of programming I have found that methodologies are put in place for PHBs and the talentless. I recall when I took my first programming class the teacher insisted we must write the flowchart first. I found it easier to write the code and reverse engineer the flowchart. To this day I find the formal process to be an anchor weighing down creativity and speed of development.

From one end to the other (4, Interesting)

BlueBoxSW.com (745855) | more than 4 years ago | (#30116110)

So we've gone from over-designing systems to under-designing systems.

How about right-designing a system based on the complexity of the scope and the key personnel involved?

Is that crazy?

Re:From one end to the other (0)

Anonymous Coward | more than 4 years ago | (#30117298)

Because right sizing based on scope is damn near impossible; it's always a moving target.

Re:From one end to the other (1)

Wiseazz (267052) | more than 4 years ago | (#30118038)

The problem with right-designing (and I do like the designation, btw) is that having multiple methodologies can create confusion. Consider the corporate IT shop. Hundreds of IT folk of various skill sets working in an organization with strict auditing and quality controls. Repeatable, predicatable processes work best in this environment... pick one and stick with it as best as you can so everyone's on the same page. It's a trade-off to be sure, but in some environments you have to learn to work within such limitations for the greater good.

We are currently using Agile (Scrum) and Waterfall because we're in transition (to mostly Agile.) Agile is new to me still, but I cannot deny how the added transparency and shorter dev cycles have begun to streamline our development. Life will be better still when Agile is in full swing here and all involved have been properly introduced to the concept.

Agile is monthly waterfall. (1)

tjstork (137384) | more than 4 years ago | (#30116142)

Agile Development is a monthly waterfall. You have short cycles, but if anything, there is even MORE up front planning than you would get for each sprint than a waterfall model and precious little time to change if things need to be retasked.

The only real advance in methodologies as of late has been to include automated testing.

Re:Agile is monthly waterfall. (0)

Anonymous Coward | more than 4 years ago | (#30116802)

Automated testing, unit testing, integration testing, iteration (see FORTH)... has been used to develop projects for 40 years.
Nothing is new except the death-march philosophy and the ability of management to get the reports and keep the developers in paranoid servitude.
Feh. Fuck XP.

It's easy to stay fit... (0, Offtopic)

XPeter (1429763) | more than 4 years ago | (#30116144)

I eat whatever I want, whenever I want. But I also have swim practice two hours a day six days a week :)

Agile development in engineering? (4, Interesting)

140Mandak262Jamuna (970587) | more than 4 years ago | (#30116146)

Our company is trying to switch to Agile methods and have bought some software. Hoping to get training scheduled soon. But from what I see in the intro so far, all the examples are from GUI development or web support or IT where a large number of coders with very similar skill set is used to implement from the scratch a new application for deployment.

But our company software has a large installed base and we need to fix bugs in existing code and somehow graft new functionalities into existing architecture with full backward compatibility for old saved data. And the skill set of coders varies widely. There are just a couple who can even touch isoparametric element stiffness matrix code, to name just one example. I still dont know how agile is going to change the way those two guys work.

I see the advantages of early feedback, and early testing, testing partial implementations etc. But at some point for some kind of code development, Agile may not be the best way to do the code. And I am hoping the training will shed light on where I can use Agile and where I should stay clear of it. I don't want to jump on a band wagon because it is the latest and then have a minor revolt among my padavans.

Re:Agile development in engineering? (2, Interesting)

ZFox (860519) | more than 4 years ago | (#30116962)

For issues dealing with the existing code, I would recommend: Working Effectively With Legacy Code [amazon.com] , by Michael Feathers.

Re:Agile development in engineering? (1)

Uksi (68751) | more than 4 years ago | (#30118098)

I ask you that you go into it with an open mind. Agile stuff has been treated as an overhyped bogeyman (look at all the posts here) and understandably many of us geeks are very cautious to approach it. However, if you pull the layers of hype and bullshit away, you recognize that it's just a different mindset that guides the work. This mindset happens to work a lot better with people and software (I am now convinced of this).

I'm hoping that you have a good instructor for training. But also, I am hoping that you have access to that instructor for questions afterwards, because that's really the most useful part. Every kind of training I've seen presents idealized examples to some degree, but a smart instructor will be able to tell you how you can work your situation.

For example, for varied skill sets, once you make up your team, try to take on a mix of stories (simplified use cases) that *approximately* reflects the skills breakdown. For example, if you have only two people that can touch your matrix code, take only on one or two matrix-work-intensive stories per sprint. After all, you have to be realistic.

(However, maybe a third person on your team would like to learn this matrix code. By sitting that person down with the matrix code expert and going through several dev tasks together, that person may learn something and may pick up these skills. Sure, it will feel slower at first, but now you have greater versatility in your team.)

If you are primarily doing fixes, then just reflect that in your wording of the stories. For example, we had to do some work to improve the startup performance of our product. We came up with stories that said, "As an administrator, I want my server to restart in less than X seconds." When we did some loose estimates, we realized that this was too much work to fit into a one-week sprint. So we split it into "As an administrator, I want my server to restart in less than X seconds, on Windows" and "... on Linux." This is because after doing some investigation, we realized that there was a lot of different work to be done for Windows vs Linux. This is not a perfect split of user stories (you want to keep such platform details out as much as possible), but that's OK. Do what works for you.

I have resolved to myself that, if I can help it, I am never again going to work at a place that does old-school waterfall. My team right now is in the middle of a transition to a Scrum-esque approach. We are running into plenty of problems, our team members have varied skills and some are much more versatile than others (Etc etc). However, it's already a better situation than what we had before.

So far, I am enjoying working off a prioritized product backlog, concentrating on getting smaller features DONE DONE, working in short iterations (2 weeks), and having the team who is fairly open to "let's change it if it doesn't work".

For one, many times before, spend months nailing down a long list of requirements, estimating the whole freaking thing, arguing between product management and engineering, cutting things to try to fit a set of features into some deadline (based on start-of-project estimates). Our product management would fight to keep certain things in that were important but not that important (because they did not want them to get dropped until the next release, that was many many months away). The developers (including me) would sit there, pulling estimates out of our collective ass for a ton of features, with barely any information for some of them.

Then we'd write extensive software requirement specifications (SRS) based on what was agreed to be implemented. The QA would go off to write test cases based on those SRSs. Of course, the use cases in these requirements were too detailed in some respects and not detailed enough in others, and completely missing the boat in yet other aspects. But, since they were signed off as "complete", we spent the rest of the project following what was agreed upon in the beginning instead of adjusting to the new process.

NOW, with the new process, we only estimate maybe 2-3 months of work, and even those we do loosely, using relative sizing (this thing is way harder than this other thing, this other thing is much easier, etc), without doing detailed task breakdowns. We only do detailed task breakdowns for stories (think of them as simplified use cases) for the next two weeks. Those task breakdowns are pretty detailed (we try to split tasks until they can be done in a day or less), but, again, we only do it for 2 weeks worth (every 2 weeks). This spreads out the pain.

So the benefit is that we only take on the most important work first. We can only do so much stuff in the next 2 weeks or two months. So all this detailed planning happens only for the most important things that the product management cares about. Every 2 weeks, the product management can reshuffle priorities and that's ok! No problem, we'll take on whatever is required next.

Developers are liking this because they don't spend weeks and months estimating everything under the sun. Product management is liking this because they can shuffle things around as market conditions change or other information comes to light.

ALSO, focusing on done done done. We used to have this "code complete" date. So some features took way longer to get done (often due to unexpected technical problems... sounds familiar?) and some were quicker than expected. Since one or two people would be working on each feature over the period of 6 weeks or longer, and even then, they only had to report some progress over those weeks. The "code complete" (or "feature complete") date was the date by which all features needed to be finished. Then we'd test and fix any bugs.

So, of course, what happens is that if the feature had technical issues, some coders would rush to check in code without writing enough tests or really even just testing it enough. Often, they would compromise design just to get it in by the date. So often, we'd have poor, half-baked code checked in by this "code complete" date. Now, testing afterwards starts revealing issues. Sometimes, the issues require a design adjustment, but now it's too late to make that design adjustment because we are in this "endgame."

Of course, you can make an argument that a better developer would not call a feature complete without sufficient testing. This better developer should've gone to the manager and said "this can't be done by the deadline" and let the management deal with that. The reality is that in a typical larger corporation, we have a lot of not-so-better developers, who are content on just cranking out something that qualifies as "coded" by this "code complete" date.

SO, by focusing the team on having smaller features be really "done" AND demonstrable by the end of the iterations really forces any issues to the surface. The feature has to be fully tested and work or it's not done. Oh shit, we have technical issues that add work and means we can't finish functional tests for this sprint? Well, no functional tests, then it's not done. OK, so that comes up right away (or at the latest by the end of the sprint) and we can then deal with it by readjusting stories, tasks, etc (and everyone realizes that this is OK).

By talking about the process and how everything went every 2 weeks, we have a chance for people to complain. Because all agile processes encourage adjustment and feedback, you can try things one way for a sprint or another way.

Of course, all of this requires management and coworkers open to change. You will find that most are open to it.

AGILE is about Mangagement CONTROL (0)

Anonymous Coward | more than 4 years ago | (#30116152)

Not about actually getting stuff done. Its a new age GANTT chart remake that serves to generate a smokescreen for upper mangement about progress on technical projects. As a developer I can't fully estimate how long Schtuff is going to take to build but I can give you a firm idea of how long the next 3-6 steps will take. That unfortuneately sends traditional MBA weenies (like me) into apoceleptic fits.

The Spiral aka Boehm method still kicks the most ass as far I am concerned.

Sadly Agile and other silver bullet methods provide the means of producing better looking charts and really at some level of idiot manager its all about the slick charts, gradients in the powerpoints and how much ass you kiss. Results matter but if they don't like you they will resent you for doing good and making them look bad. As a result project managers become chart bitches and become List Management Engineers.

I'm also a huge fan of hiring fewer smarter people than huge crews of people because of channels of communication issues..

I'm fucking a ballerina (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30116182)

Does that make me agile?

Re:I'm fucking a ballerina (1)

hoggoth (414195) | more than 4 years ago | (#30116766)

No but if you were a fucking ballerina it would.

Evolutionary Prototyping (2, Insightful)

PIPBoy3000 (619296) | more than 4 years ago | (#30116346)

My preferred approach these days is what I think is technically called Evolutionary Prototyping. Basically you start with some rough requirements, make something to show people, get more refined requirements, and repeat. At some point when the product is useful, you go live, but in reality you're never done and just the time between deployments gets longer.

This approach is horrible for things that have to work perfectly the first time (e.g. rockets to Mars), but for web development seems to be a decent approach. It's also hard to estimate how long something will take, as the requirements aren't known up front. Still, it's what I've been using for years. I don't think I knew what it was called until our organization brought in a consultant to talk about this stuff.

Re:Evolutionary Prototyping (1)

Tridus (79566) | more than 4 years ago | (#30116688)

Yeah, this is the only type of approach that really works at my job. Most of the time the system owners and end users don't *know* what they really want at the start. They have a vague idea of a few things, and thats it. Trying to develop detailed specs has never worked out based on that, they agree to anything you put under their nose then in 6 months realize its all wrong.

Instead, start building based on what you do know. Refine that. Get a lot of feedback. People may not know what they want, but they know what they don't like.

At the end of the day, we've found that people are much happier with systems devleoped this way then ones done using a waterfall method. So it works well for us. YMMV.

Re:Evolutionary Prototyping (1)

gtall (79522) | more than 4 years ago | (#30117086)

Evolutionary Prototyping probably works well with small systems. With large systems, the sheer weight and cost of producing many prototypes is going to get in the way. Just testing a large system is a significant expense.

Another area it probably won't fly is security systems for organizations like NSA. You won't be going back and forth with those guys over some system, they'll simply conclude you have no idea what you are doing and your contract won't be renewed. All of your security mechanisms and overall design need to be seen before they commit to funding any kind of development. If you show them a prototype near the start, it simply won't fit into their scheme of wanting to see precisely what you think you are building first since they'll be needing to evaluate it with security in mind. What is a small detail to you is covert channel to them.

Bizarre Covers (1)

Tarlus (1000874) | more than 4 years ago | (#30116390)

I swear, between O'Reilly's [oreilly.com] animals and Manning's [manning.com] depictions of people from different eras and cultures, I'd say a picture of a guy with a dead bird tucked in his belt is the most random choice for the cover of a programming book that I've ever seen.

Re:Bizarre Covers (1)

Tablizer (95088) | more than 4 years ago | (#30118192)

a guy with a dead bird tucked in his belt is the most random choice for the cover

It fits the agile fad perfectly: you are told you can fly by stapling wings to your belt. If you crash, it's because you "didn't leap hard enough".

     

Yeah, it's great when you do agile (1)

NotSoHeavyD3 (1400425) | more than 4 years ago | (#30116454)

and everybody is theoretically supposed to be able to do system analysis, coding, and QA. That way nobody is unique and it's much easier for them to lay you off and swap some new cog into the machine. (Ok, so I just got laid off and I was on one of the agile teams. Actually we had a bunch of agile teams and they pretty much dumped most of the people on them and kept people who weren't on them because they had unique skills. I know, I should have seen that one coming.)

PyPy - crashing and burning with "agile". (5, Interesting)

Animats (122034) | more than 4 years ago | (#30116470)

The attempt to write a Python implementation in Python, PyPy [codespeak.net] , turned into a death march. The project has been underway since at least 2003 (when they had their first "sprint"), never produced a usable system, and the European Union pulled the plug on funding. But the project limps on. There's a released version. It's slower than CPython. There's supposed to be a "just in time" compiler Real Soon Now. (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.) Six years in on a compiler project, and no product.

The PyPy project is very "agile". They have "sprints". They have "flexibility". They have nightly builds. They have mailing lists and trackers. They support multiple output back-ends. They have about 50 contributors. What they don't have is a usable product.

Meanwhile, one programmer produced Shed Skin [blogspot.com] , which compiles Python to C++, with a speed gain of 5x to 50x over CPython.

When the problem is dominated by design and architecture, "agile" doesn't help.

Re:PyPy - crashing and burning with "agile". (4, Insightful)

Clover_Kicker (20761) | more than 4 years ago | (#30116856)

Yeah but I'm sure someone here can point to hilarious failures of any methodology, or tool, or language.

Let's face it, software sucks. Writing software is hard.

Re:PyPy - crashing and burning with "agile". (1)

Animats (122034) | more than 4 years ago | (#30118536)

"Agile" designs for the business logic part of web sites makes sense. The problems aren't technological. Writing an efficient compiler for a language that's never had one is a design and theory problem. A big team hacking away somewhat randomly won't cut it.

Re:PyPy - crashing and burning with "agile". (1)

pnewhook (788591) | more than 4 years ago | (#30118614)

Let's face it, software sucks. Writing software is hard.

No, *writing* software is easy. *Designing* software is hard. There are a lot of people are good at writing software that should not be let anywhere near the software design.

Oh and the second agile dogma is stupid (1)

NotSoHeavyD3 (1400425) | more than 4 years ago | (#30116522)

That one about working software vs comprehensive documentation. I mean what company was it where they actually had a problem with too much documentation. All my experience has been in IT people don't want to document anything and that dogma would probably make them think not only is it ok to not document but it's actually a good idea.

Re:Oh and the second agile dogma is stupid (0)

Anonymous Coward | more than 4 years ago | (#30119034)

And when you combine it with a fundamental lack of overall design, it's downright dangerous in a complex system - outright asking for brittle, spaghetti code. Hey, that's the result I live with every day.

Agile and embedded systems? (2, Interesting)

Anonymous Meoward (665631) | more than 4 years ago | (#30116624)

Who here has actually used Agile for embedded systems work? What were your experiences?

Is to become Fragile (0)

Anonymous Coward | more than 4 years ago | (#30116710)

Stupid methodology for control freaks. Micromanagement at its worst!

How to turn your skilled employees into cogs (4, Insightful)

composer777 (175489) | more than 4 years ago | (#30116846)

I think the appeal with agile development is that it removes any barriers that programmers might have, such as rigid milestones, etc, and basically allows management to do what they want in terms of setting goals. It also is appealing to management because the knowledge sharing implies that they can get rid of their most expensive employees after a period of time (once the knowledge has dispersed). Specialized knowledge is an anathema to management, as it means that you have to pay that person more, and it's critical to the business, it's harder to fire them.

We have to evaluate agile based on it's real world results, not what the books describe. In the real-world, agile creates a very high-pressure work environment, where personal space is non-existent, everyone is watching you, and your work is constantly on display. This pressure can produce productivity gains but I would say that in the long run these gains aren't sustainable. I think agile is a very poor fit for your average introvert, which, imagine that, describes most programmers very well. What I believe will happen is that over time the better developers will move to a work place where things aren't quite so agile.

In the mean time, throwing out such ideas as design first, is going to cost us, big time. I think that software quality will drop, but it won't be obvious, as "quality" and "productivity" aren't things that are easily measurable. Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity. No, I think the drop in productivity will become apparent when non-agile competitors clean their clocks, but then it will be too late.

Re:How to turn your skilled employees into cogs (1)

avandesande (143899) | more than 4 years ago | (#30118586)

Yes, coders who like to sit on their hands for weeks or months and play fantasy football instead of work don't last very long in an agile environment.

Re:How to turn your skilled employees into cogs (4, Insightful)

MartinSchou (1360093) | more than 4 years ago | (#30118772)

. Often times, managers walk through a room, and if they see a bunch of people typing away or debating some design issue, then they see that busyness as productivity.

Very true.

The biggest surprise I had in my professional life was when I was stuck on a particular problem. Completely stuck. So I tried doing other stuff in the mean time. Then I rand out of stuff to do. Posted on newsgroups and forums, but still no answers.

So I asked my boss if he had anything else I could do, while waiting. "Go play solitaire, read a book, go for a run. But not too far, and keep your cell on you if we need you."

He knew that some things cannot be forced. So I got paid to sit on my ass and read books for two days until the answer popped into my head. Sometimes the best way to be productive is to just sit back, relax and do nothing.

By any other name.... (1)

EternityRoad (1679646) | more than 4 years ago | (#30117120)

This sounds and kind of looks like another description of Rapid Prototyping or how a artist does a work of art. Do a bit.. Backup... Look at it from all angles. and continue on. When will these "Thinkers" realize one size doe not fit all. You need to think of "how to do the problem" along with "How to solving the problem"... This can work for "Project XYZ" thats so open would be a nightmare if you used structured programming. But structure would work very well creating a accounting package.. Been writing & building items since the early 70's for places and clients I have worked. Used about every system in the book so to speak. No one system can do all. That's why we dont have a few tools but unbeleviable amount. The right tool for the right job. Or as a Dr said to me. "The right juce for the right bug." Else not solving the problem.

Re:By any other name.... (1)

Maximum Prophet (716608) | more than 4 years ago | (#30118142)

But structure would work very well creating a accounting package.

I would hope so. Accounting is so formalized that the prototype essentially has already been written, it's in the way accounts would do it without a computer. The same rules have to be followed whether you are doing it by hand or machine.

You bring up great points. If a job is currently being done, and we want it to be done the exact same way, but cheap and faster, a methodical method would work well.
If, on the other hand, you want to create something that's never been done before, an agile methodology might work better. The key is being able to determine at each milestone if you are headed in the right direction, and if you get off the path, to get back on ASAP. (also people often assume that their idea is completely new, but it already been implemented somewhere else, better.)

The users are the problem (5, Insightful)

Maximum Prophet (716608) | more than 4 years ago | (#30117142)

My biggest problem with quick prototypes are the users that expect too much.

Me: Here's the prototype. It's black and white, but the finished product will be in full color.
Them: This menu item is supposed to be green.
Me: That's because the prototype is in black and white. We're just trying to get the text and spacing correct
Them: That item is supposed to be red...

Managing user's expectations during the prototype phase can be a full-time job. (:-(

Menthodologies (0)

Anonymous Coward | more than 4 years ago | (#30117180)

"Among the more popular Agile Menthodologies are "

What's a Menthodology? Is that a minty way of making software?

Not to be pedantic, but... (1)

heironymous (197988) | more than 4 years ago | (#30117248)

Royce was actually arguing against waterfall, but a poorly worded caption led to much misunderstanding. Waterfall is almost certainly the most expensive meme in history.

Rational (1)

cbreaker (561297) | more than 4 years ago | (#30117332)

There's plenty of different methodologies to writing software. IBM's Rational system combines project management, a feature request system and a code management system into an iterative development structure that I found to be very robust and fun to work with.

The idea is to start writing code now. Write the code, make sure your concepts work - and before it's been written into a budget and had time allocated to it. With each iteration of the development process, you can bring together more code and more features until you reach a release state.

Some things are better done the Old Way (limited scope project, etc) but for more major development cycles there are better ways.

Re:Rational (1)

pnewhook (788591) | more than 4 years ago | (#30118662)

The idea is to start writing code now. Write the code, make sure your concepts work - and before it's been written into a budget and had time allocated to it.

Oh God. that is NOT what Rational says at all !!!!

Re:Rational (1)

cbreaker (561297) | more than 4 years ago | (#30118860)

I really don't think I'm that far off. The idea is to start writing code as soon as possible so you can encounter and address problems as soon as possible as you build your application.

The idea is to avoid the three month design phase, only to find out that 25% of the things you designed for won't end up working for some reason or another.

Re:Rational (1)

pnewhook (788591) | more than 4 years ago | (#30118968)

First, it has nothing to do with budgets. Most companies you cannot even assign employees to a project without having a budget.

Second, you need to start your requirements first before coding. Without requirements, what are you going to code?

Re:Rational (1)

cbreaker (561297) | more than 4 years ago | (#30119302)

No, you missed the point. What I said was that it got you to start your coding to make sure your concepts will actually work - BEFORE you blow your budget out because it turns out you can't do something as originally intended. Traditionally you'd write up the whole project plan, budget time, resources, money, etc - before writing a line of code. In the Rational way, you do have to do some of that, but you can avoid the major pitfalls of budget (be it time, money, resources, whatever) under and overruns by proving the code very early on.

Yes, you need requirements. But those requirements can start light. "Application to provide unified authentication between sites and directories. Must connect to Active Directory." So, your programmers can start off with methods to connect to AD and either rule-in or rule-out various ways of doing that, putting you on the right track from the start and basing the rest of your work off of a known good starting point. As more requirements come through - via Requisite Pro or another method - you can begin refining the application and expanding it through iterations.

Huge Problems (1)

bodland (522967) | more than 4 years ago | (#30118168)

When companies move to agile style of programming (I call it Git'er done) they immediately see benefit with the speedy deployment of apps and processes. Roll the camera forward three to five years the failure to include data cleanup, loopback and redesign methods for "shortcuts and workarounds" becomes crippling. Apps that are implemented result of "git'r done agility" result in a cross platform spider-web of dependencies that is unstable and needlessly tied to one another. The entire business becomes trapped up in a giant ball of code that is unraveling in multiple places.

In the real world there is no discipline in undisciplined programming methods and deployment.

Re:Huge Problems (1)

Tablizer (95088) | more than 4 years ago | (#30118330)

That's what happens when "finishing" is given higher priority than maintenance. If a business wants to trade finishing sooner for future maintenance headaches, that's their prerogative. However, they should be made aware, in writing, that such a trade-off is actually being made.

The big flaw of Agile (1)

tjstork (137384) | more than 4 years ago | (#30118374)

Is that, everyone gets so caught up in "hours burned" for each scrum, that what is actually getting burned takes a back seat to the deliverable. I was on a sprint where I had no hours burned for three days, which really, really sucked. But at the end, I was the only one that actually had a product that you could do sprint demo with.

Stop with the "methodologies" already! (1)

DrVomact (726065) | more than 4 years ago | (#30118634)

While the this methodology and... The Agile methodologies which are described...In describing these development methodologies...non-religious presentation of multiple Agile methodologies...

The word method may be defined as "a systematic way of accomplishing a task"; near-synonyms include "procedure" or "technique". The word methodology means "a study of methods", or perhaps "a comparison of methods", or "a science of methods".

This substitution of the word "methodology" for "method" happens so frequently that one could argue this is just one of those shifts in English usage that happen now and then, and it's time to stop obsessing about it. I don't think this is such a case—I think if a writer uses long, pretentious words in place of simpler, more direct ones, then this should serve as a warning to the reader: stilted diction may serve to obscure a lack of substance.

Now, about the word "agile"...as a buzzword it's become quite raddled by excessive use. I'm surprised someone is brave enough to use it in the title of a book.

Agile vs. Predictive (0)

Anonymous Coward | more than 4 years ago | (#30119018)

Management buys into "Agile" because they think it means "fast" ... "We'll get our software developed faster!!! Run, Team, Run!"

The reality is that "Agile" means agile, not fast. To understand this, consider the difference between a bicycle (a very agile vehicle), and a 53' long 18-wheel truck (not even close to agile).

Which vehicle you want to use depends on what you need to do:

If you launch one space shuttle every five years, but it absolutely positively must work as planned the first time; then you use a predictive model (CMMI); because the process will force you to dot every i, cross every t, and sacrifice the proper amount of goats to the correct evil deities at the most auspicious times for doing so, and your shuttle will launch without blowing up.

If you've got a small online game, and you need to add new user-ready features constantly, and the end users are happy with "a little rough around the edges", then use an agile model (XP, SCRUM, etc.); it'll help you respond to user feedback in time for it to be useful.

You wouldn't use a bicycle to haul 50,000 lbs from Florida to Washington, and you wouldn't use a big rig truck to deliver hundreds of small packages to hundreds of different addresses in downtown NYC.

Why would anybody expect a software process to fit every kind of software to be developed?

Agile is good for GUI/web projects (2, Insightful)

saigon_from_europe (741782) | more than 4 years ago | (#30119106)

Scrum has one good point - show your code to your customer often and apply his comments. But that works only for GUI or web. I cannot imagine that in, say, medical software. For instance, one of my colleagues had to optimize crucial piece of code (some heavy math for CAT scanner). It took him several months. Only thing he could say to the customer was like "it is now two times faster" or "it is now 3.45 times faster". Not something you can really get some useful feedback on.

In another company, we were supposed to do a project for GE, and there was some serious GUI there, but their office was some several thousands miles from us and I really didn't know how we would make regular meetings with them as Scrum required. Also, they had some very elaborate specs and they did not see too much point of Scrum methodology. In some other situation, that project would be a perfect one for Scrum.

PS One thing I don't like with Agile evangelists is that Agile (Scrum in this case) is always right. It's either "what are you doing is not Scrum" or "you did not adapt Scrum to your needs", but its never the problem in Scrum.

Step 1 (0)

Anonymous Coward | more than 4 years ago | (#30119168)

The easiest way is to make sure you give yourself high dexterity. I recommend 16 or higher.

Methodology is like cooking (4, Interesting)

pcraven (191172) | more than 4 years ago | (#30119210)

Methodology books are like recipe book. Good chefs own many of them, and draw on the knowledge and ideas inside.

But buying and following a cookbook does not make you an expert chef.

agile is not 'yawn' you moron. (0, Flamebait)

unity100 (970058) | more than 4 years ago | (#30119356)

just look at microsoft. just look at how their products become outdated even before getting into the market.

there are still a lot of people who work in deep vestiges of corporate structure where this kind of old development shit is still taken as a reality of life apparently. you build code like you build a bridge, taking years and years of time and rigid structures built on other rigid components. and you are still getting paid.

the reality is, the place you are currently at is little different from an island stuck in time. it will change. reality will catch up.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...