Slashdot Mirror

Our dev and DevOps teams use Agile so there's a ridiculous two week minimum delay for any fix since you have to add the JIRA issue to a new sprint before you can fix it.

Wow, Agile is making you not agile. Good thing you are following the agile manifesto by putting people before processes.

First, this is the first headline I've seen where the answer is an unmitigated "YES!!!!"

2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)

What's funny is how Agile took notes of people that were successful in releasing software projects and got the message so entirely absolutely wrong. It never was "Waterfall" or "Agile". Strict waterfall works, but it is expensive. You may have heard some of the success stories, anything done for NASA for one. Working on such a contract can be excruciating and boring, and truly leads to the misconception that all programmers are merely cogs, because in such a project merely being a medium level syntax proficient programmer is all that's required.

But back to the point - truly successful projects in the internet time-based world required faster turn-arounds than waterfall allows. It requires active management leadership, and quicker feedback loops to make up for the removal of the heavy front-end design and specifications phase. The guys that wrote Agile seem to have glommed onto a few of the traits from successful projects without paying attention to the context within they were used. Just IMNSHO. (while I respect Dave Thomas, he was so so so wrong on Agile and from what I gather he seems to concur more with the underlying basis of what I stated above) So now we're going back to a more sane project leadership based system, or at least those that are successful have done so.

What rules are you talking about? The agile manifesto specifically says, "we value Individuals and interactions over processes and tools." It sounds like you are too focused on rules, and have lost sight of what Agile truly is.

Beyond the headline, here's what he says:

1) The team itself should choose the process because imposing process company-wide by business execs is bullshit. If you have a consultant come in and impose a method, that's reverse of what should happen.

2) The agile manifesto is good. (tbh it's actually kind of funny how many people are "doing agile" without ever having heard of the manifesto itself. Kind of hard to keep the core principles of the process if you don't even know they exist.)

3) All you need are three principles and those are, "release code often" "keep your code clean," and "push back against managers imaginations" by focusing on reality: what state the code is in now.

Again he reiterates, if process is imposed from above instead of chosen by the team, things will go wrong. He's kind of echoing Fred Brooks here, who said, "The teams need a process, but they choose it on their own."

There is, though. Right there at the top it says, "We value individuals and interactions over processes and tools." Is Agile a process? Primarily it's not. Ask your consultant what they are doing to value individuals over processes. Watch the blank look of fear, followed by a stream of BS coming out of their mouth.

> Is it diversity, or is that other team just really shit?

That's a fair question. I charitably assume they don't suck, they just work *differently*.

> I don't think the Agile development methodology is related to any particular ... or cultural group

The Agile Manifesto, which basically defines Agile, is short and easy to read:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

http://agilemanifesto.org/

The first and second sentences say it's about values (social / cultural.values) including helping others develop software. Agile is about "Individuals and interactions over processes". Everyone I've ever worked with from other cultures has said that the emphasis on individuality and de-emphasis on process is the #1 striking difference about US work culture. Other cultures don't put "individuals over processes" like that, the #1 characteristic of Agile is a very American characteristic. (Also a bit feminine - on average, females value "interactions" and "collaboration" than men typically do).

"Working software over comprehensive documentation"

        "Whatever works" isn't a cultural thing?

"Customer collaboration over contract negotiation"

Collaboration vs negotiation is very much a cultural thing. Also, surveys show women in the US tend to very much dislike negotiation and prefer collaboration. Men tend to be much more comfortable with negotiation. This came up on Slashdot a few months ago.

"Responding to change over following a plan"

Again, being flexible versus following a plan is very much a cultural thing.

It seems to me Agile isn't just "related" to a culture, Agile IS a culture. California culture. It's not even a great fit for Texas culture, not to mention Pakistan or Colombia.

Read the Agile Manifesto some time, and tell me whether your company's practices fit in. It sounds to me like you're prioritizing processes and procedures over people and interactions, and not paying attention to working software. If you completely reverse the first bullet point in the Manifesto, you're really not doing Agile.

I've seen Agile work very well, producing good software on time with the developers feeling good about it. That's because we paid attention to the ideas in the Manifesto.

It may be that it's very hard for management in general to actually perform Agile, but there are places where it does work.

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

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

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

Can someone tell me how "agile" went from being an adjective to a noun?

A bunch of guys found that their software development was going quite well and wrote the agile manefesto to explain and gave it a name "Agile Sotware Development". After that lots of people wanted to pretend that what they were doing already was the same thing. They all claimed that "Scrum is an agile methodology" and that "this is agile". Needless to say they deeply perverted the main aims of agile.

AAAARG!!! I can't believe that Atlassian is making so much on this crap. JIRA is the WORST POSSIBLE CHOICE for an Agile environment. The very first value of the Agile Manifesto is "Individuals and interactions over processes and tools". (Agile Manifesto)

Repeat after me:

• Scrum is not Agile
• "Individuals and interactions over processes and tools"
• if something is desribed as an "agile process" then the people doing it don't understand agile
• "Responding to change over following a plan"
• if you insist that you have to take all the parts you are not doing agile

Repeat after me:

• Scrum is not Agile
• "Individuals and interactions over processes and tools"
• if something is desribed as an "agile process" then the people doing it don't understand agile
• "Responding to change over following a plan"
• if you insist that you have to take all the parts you are not doing agile

Many organizations implement "Agile" without understanding it. Agile is not a methodology. It is a philosophy, expressed by http://agilemanifesto.org/ . The intent of Agile is to rewind back to what worked during the 70s and 80s. The authors of the Agile Manifesto are all people who were around then. It is well documented that large software projects with detailed up front requirements have a very high probability of failure. Agile merely advocates a return to common sense, including:

1. 1. Dividing the work up into smaller loosely coupled projects, and small features that can be implemented individually.
2. 2. Allowing requirements to change, in recognition of the fact that users often don't know what they need until they see something working.
3. 3. Testing as you go, instead of all at the end, based on acceptance criteria.

In the case that you describe, it sounds like acceptance criteria were not defined well.

Well run Agile projects do not abandon quality or non-functional requirements, detailed requirements, or design. What is different is that these things are allowed to evolve over time, through a process of refinement; but if no one is orchestrating that process, then indeed junk will be produced.

Many organizations are confused about how QA relates to Agile. Agile does not dispense with QA. If you search online, you will find a-lot of discussion of that. It is true that some in the Agile community do not understand the need for QA, but the more experienced and rational ones do. I can offer the following four-part article on Agile testing the way that it is done in many real organizations that do it right: http://www.transition2agile.co...

What do meetings, code reviews and the other things you mention have to do with agile? Nothing!

I suggest you read at least http://agilemanifesto.org/

Nothing of the stuff you are so scared about is required or intended if you do an agile "process".

If you don't make releases in short circles it is your own fault.

I don't have another developer watching me Never had that in an agile team either ... what do you mean with that?

Applying one methodology rigidly to every single project is also not Agile. The Agile manifesto says "Individuals and interactions over processes and tools".

From what I've learned in the last three companies I worked for that used agile, agile means that an ungodly amount of time is spent in meetings and constant, meaningless record-keeping. God, I hate agile. It gets in the way of doing good, timely work.

They should probably start off by reading the Agile Manifesto...where it talks about the values of agile development - one of which is to value Working software over comprehensive documentation. Sounds like they have the wrong focus.

Mediocrity is not uncommon, and there are way too many people in the development end of things that shouldn't be. I've been dealing with these clowns for almost 20 years now - and this very topic is what is driving me to retire early and do something else with my time, instead of the endless death marches to nowhere.

Obviously the manifesto is so short on details that it can be interpreted in many ways.

Short on detail but long on words. Compare it to the Agile manifesto which has few words, but communicates the ideas very clearly. When you read that, you understand the underlying principles of agile. This manifesto has more words, but still manages to clearly get its idea across.

When it comes to the manifesto linked in the article, as you mention it is short on detail. Specifically, who doesn't want to have a responsive system? Have you ever met anyone who said, "I think I will build a website. I want it to take 15 seconds for the pages to load." Saying you want your site to be responsive is so generic as to be meaningless.

The part that really makes me laugh is the part where they say it will have no bottlenecks. That has been the goal of designers since the day of Von Neumann. He was certain he would design his computer without bottlenecks. Once again, it's something that everyone wants.

The biggest thing they have that isn't generic there is that they require message passing. That seems like a weird requirement to me, but I'm sure they have a reason.

Nobody else pointed this out? Come on guys.

This is AGILE.

This is what most of us get from pointy-haired bosses in corporations that just heard of this "agile" thing.

This is a great way of describing Scrum, but I would be more clear about the fact that Agile != Scrum. Agile is the abstract base class (or maybe even just an interface/protocol) described by the Agile Manifesto: http://www.agilemanifesto.org/ and Scrum is a subclass that implements/extends Agile.

That said, the yardstick analogy is great and I'm going to use that right away in a class I'm teaching about Scrum!

Thanks!

PS. BSP below...

What you're failing to recognize is that there is little incentive to work beyond what you're told to do.

You're right, agile probably won't work well in an environment where people don't care about the quality of the product they're delivering. I don't know that BDUF actually works better than this, but I do know that agile won't work.

I feel bad for your experience moving to agile--but it sounds like the real problem is that you went from a good management structure to a really crappy one. The fact that you weren't given time by your product owner to do the things you felt needed to be done is a huge red flag, but the same thing could just as easily happen with more traditional processes if you're manager started micromanaging.

If however your product owner is human, then it's likely your dev team would do better by actually making the decisions as a team.

I am not aware of anyone who would deny this. If your management thinks agile means that you don't make decisions as a team, then you're going to have a hard time. If you're product owner thinks that title makes their opinion on priority the only one that matters, then you're going to run into huge problems. I would argue, however, that the potential for those kinds of problems is not unique to agile methodologies, and that if you can get people to really buy off on the agile manifesto, you're unlikely to have that particular problem.

This isn't to say that agile teams won't have any problems--making software is fundamentally a social problem, so it includes all the messiness that real social problems have (see xkcd 592).

Just ignore the trolls. Sometimes even me. Responding to them doesn't do any good unless you just occasionally enjoy a good flame war for the fun of it, in which case you need to be lots ruder than that.

BTW; what rubs me up the wrong way about Sarah's posting is really this

However, none of them address the factor that has the biggest impact on the quality of your codebase: Other People.

Ever since Knuth designed web and espoused Literate Programming there has been no possible way for a person properly educated in CS to not know that the main problem of software is communication with other human beings. I mentioned agile a bit glibly (it's a 1st post; it has to be fast and funny) but I really mean it as a strong comment to this overall. Agile software development process which was designed very much to talk about how people work together and the founders of it put this very explicitly in their manifesto.

Even those two movements are themselves just statements of ideas other people had done often before. Either Sarah is ignorant of this or she deliberately picked a bunch of methodologies which are trying to solve different problems and ignoring the ones which are related to her topic. Either thing would be a bad sign. If you are just getting into this subject then you should start reading up around the many interesting ideas related to this that have been around before. Recent (since the 90s at least) programming language design has been very much based around the idea of programming languages as human to human communication.

The benefits it promises come only from the synthesis of ALL its components.

Yes, yes, we've heard it a thousand times, if an agile project fails, it must not have been truly agile. Probably isn't a true Scotsman, either.

There's a big difference here. The problem with the No True Scotsman fallacy is that there isn't an agreed-upon definition of a True Scotsman before you start. However, there is a widely agreed-upon definition of agile. The very first paragraph of the "principles" page behind that link reads:

We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

I would contend that software that does not perform a useful function by itself is not valuable. Therefore, this project which has never delivered software which is useful, is not following the "highest priority" of the most widely-cited description of Agile. It is therefore quite clearly not correctly following the requirements of an Agile project.

It may well be that it would have been impossible for this project to be Agile. This is not something new; it is widely known that not all project types are appropriate for Agile development. See for example this page, which states:

When You Should Not Use Agile Project Management ...
When the project cannot be broken down into components for the purposes of client, user or customer input and testing throughout the project i.e. a process that cannot be changed or implemented a piece at a time but must be changed in one go

Sure sounds like a description of this project to me.

If this happens, it's because you aren't following a key agile principle, which is to deliver working *useful* software on a regular basis. It's the first damned paragraph of the "agile manifesto principles" document:

We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The software isn't valuable if it can't be used.

Now I'll happily admit that in some cases, this is impossible, but the point is that these cases are not examples of cases where agile has failed; they are examples of places where agile actually cannot be used, and therefore whoever has been running them has only partially implemented an agile process. Partial implementations of agile processes are, unfortunately, doomed to failure. The agile process consists of a set of mutually reinforcing practices that, if any are neglected, can all fall apart quite quickly. This says nothing about whether agile is realistic for the rest of us, because *most* software projects don't have constraints that mean a reasonably-sized team cannot have a working system that is doing something useful within 4 weeks (which is about the longest an agile process will usually let you go without delivering useful software).

Author is obsessed with the random encounters idea but effective teamworking is hardly mentioned at all. In my view Agile is what's killing telework.

Your post is related to what I was thinking: if there is no expectation for anyone else to maintain his code, then I don't see the problem from the complainers perspective. Of course, that doesn't help the company if he gets hit by a bus.

The agile manifesto may also be useful to consider:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

He might be focussing on delivering working software - and less about documentation or process. The management of this company might see his performance as a good thing relative to customer satisfaction...that is until he gets hit by a bus and a zero day vulnerability emerges from the depths of the gaseous mud bog that passes for his code base...

To me agile is just the latest buzzword. When I started my career then years ago it was "extreme programming". My first team claimed to be using it despite no pair programming or other practices I would associate with it.

To me "agile" is the way that many in house systems have been developed for years. It is only recently that the word agile has been applied to them (lets face it, almost everyone claims to be using agile these days).

My current work is to develop and maintain the in house database system used my a high throughput sequencing centre. We don't officially use agile, but looking at the agile manifesto http://agilemanifesto.org/principles.html, the way we work conforms to most of the principles laid out here. Regular frequent meetings, getting the software into the hands of users as soon as possible, frequent feedback, adapting to changing requirements. I haven't changed the manner in which I work over the years, but now I seem to be doing "agile" (more or less).

Bro, the agile movement (or buzzword) is almost as old as the XP movement (or buzzword.) "Extreme Programming Explained" was published in 1999 while the first Agile Manifesto draft was written in 2001, attempting to encompass similar methodologies of the vert late 80's and early-to-mid 90's. Back in 95, people were already (and rather empirically) were implementing lightweight methods moving away from rigid variations of iterative/spiral models (or waterfall if you were unlucky.)

Not sure how you can say Agile is the latest buzzword if you started your career at the dawn of XP.

Also, whether they are buzzwords or actual methodologies, that depend on the practitioner. I've seen people saying they are agile because they have no process or even source control. "Who cares about that, code and deploy directly on production. We are Agile!!!" At the other side of the spectrum, you have fundamentalist Agile-libans for whom they need to do every single religious step of Agile or XP regardless of the circumstances, like forcing people into pair programming irrespective of work culture.

In both cases, Agile (and XP) are just buzzwords, one for justifying shitty work, and the other to subordinate work objectives to mindless following of magical mantra.

Real software engineers do trade-offs, choices, pick stuff that work, and drop those that are not applicable. I've never seen effective Agilistas/XP practitioners that use every single thing in their manifestos just because.

Good software engineers will make things work be it with XP or Waterfall. Bad software engineers will fail regardless of methodologies.

In reading the comments, it's clear that many people don't know the roots of agile software development. In short, agile (note the lower case) development is basically a set of of principles laid out by a group of very talented developers in the late nineties in their agile manifesto:

http://agilemanifesto.org/

Note that the manifesto makes no mention of Extreme Programming, Scrum, or any of the other capital-A Agile methods. Instead, it focuses on observations about what made their software projects successful. Itpecifically doesn't prescribe any specific methodology, but rather encourages communication, iteration, and excellence in design and engineering. The last two points come from this section of the manifesto:

"Continuous attention to technical excellence
and good design enhances agility."

The manifesto very much allows for, and even encourages, design. It also assumes that the practitioners are already experienced developers who know how do design software and know how much design is needed before coding. Unfortunately, the most Agile methods traded experience for certified training and the 'technical excellence' portion was lost.

I've worked with many talented teams and have seen agile work time and again. Of course, all of those projects did have design, documentation, and tests. But, all those artifacts were developed using the same principles in the manifesto.

-Chris

Well said. People like to talk about SCRUM and whatever else but don't want to discuss the core it's built off. It all comes down to:

do the right amount of analysis up front to have a true understanding of the problem you're trying to solve with said project
make sure you have talented individuals who also were part of looking at and understanding the problem
start with a high level design of the overall "system"
divide and conquer in an iterative fashion
review ever few days, weeks, months, whatever is appropriate for the parts/project
keep to at least basic standards and adjust them as needed

And continually adjust as needed with always your eye on the real Problem you are trying to solve through interaction with clients

That's it! I've done many projects this way. Either being a member or leading and have never had issues. We've always delivered on a proper solution that we can then extend and tweak as business needs also change over time

In reading the comments, it's clear that many people don't know the roots of agile software development. In short, agile (note the lower case) development is basically a set of of principles laid out by a group of very talented developers in the late nineties in their agile manifesto:

http://agilemanifesto.org/

Note that the manifesto makes no mention of Extreme Programming, Scrum, or any of the other capital-A Agile methods. Instead, it focuses on observations about what made their software projects successful. Itpecifically doesn't prescribe any specific methodology, but rather encourages communication, iteration, and excellence in design and engineering. The last two points come from this section of the manifesto:

"Continuous attention to technical excellence
and good design enhances agility."

The manifesto very much allows for, and even encourages, design. It also assumes that the practitioners are already experienced developers who know how do design software and know how much design is needed before coding. Unfortunately, the most Agile methods traded experience for certified training and the 'technical excellence' portion was lost.

I've worked with many talented teams and have seen agile work time and again. Of course, all of those projects did have design, documentation, and tests. But, all those artifacts were developed using the same principles in the manifesto.

-Chris

What do we do? We talk to each other. Emails, IMs, the occasional skype call, and very rarely a face-to-face so we can whiteboard. It's all ad hoc, entirely as needed, and only the people who need to be present are invited.

Individuals and interactions over processes and tools

You're doing Agile right.

There's nothing much wrong with a 10-15 stand-up meeting, if that's all the time you're going to be spending in meetings and if it suffices to manage your projects. The point of doing meetings as stand-up meeting supposedly is to keep them short, but you'll be surprised how often they're not being time boxed.

I'm sure your stand-up meetings are being done in the name of "agile". And let me guess, you're suddenly buried with additional procedures, processes and tools, right? Read the original agile manifesto. It's likely that what you're currently doing isn't agile. In fact, if it is what I think, It's the exact opposite of agile. But you might want to be careful in pointing that out.

1970 - Waterfall, 2000 - Iterative, 2010 - Agile

Wow, it would be hard for those dates to be less accurate. Phased software development was described at least as early as the 50s, and by 1970 the "waterfall" method was being criticized (by Royce most publicly in what Wikipedia credits as the first formal presentation of the method) . The history of iterative goes back to the 50s with the name being applied in the 60s and was (in my world of medical software development) in common usage in the 80s. The Agile Manifesto was created in 2001 and was the result of meeting about a variety of already existing agile processes.

As a last ditch attempt to not get totally labelled off-topic: my very best DM ever was an awesome storyteller, but wanted to appear to be "always following the rules". He would roll dice and do table lookups, which he would then completely ignore in creating a story. He only told me this when our group disbanded. He also saved my character's life several times "just because I loved the way you play him."

I take a dim view of uppity managers claiming methods like Agile, XP, Scrum and blah blah blah make two shits of a difference when you are not granted autonomy.

And what about when you are granted a reasonable amount of autonomy?

It also seems like these things are becoming buzzwords, while forgetting their roots. I find I still agree with the Agile Manifesto, though I'm as skeptical of trendy managers as you are.

The AC posted a quote from the Agile Manifesto

In the agile world blaming is largely seen as counter productive - in Scrum you make the fact that you "forget" to do something visible as soon as possible by interaction with the "culprit" on a very frequent basis.

In the more classical way of working you do a lot of book keeping so that after months or even years you will be able to blame somebody for doing something wrong. That is butt covering, isn't it? It doesn't help preventing or solving the problem in the first place.

Perhaps it could help learning from past mistakes then? In theory perhaps, my experience is that people rarely dig into that kind of data to solve current problems.

I was fired from a job because of Agile...

You were fired because of incompetent idiots in management and possibly on the technical team as well. Nothing about Agile says "make programmers do things they haven't the skills to do". Nothing about Agile says "don't help fellow programmers". Nothing about Agile says "let programmers fail". Not all agile methods agree, but Extreme Programming, for example, would have had you pairing with someone who knew Java better than you did. The Agile Manifesto says:

Through this work we have come to value: Individuals and interactions over processes and tools

I think your former employer showed a value of process over individuals and interactions. Any good team would have had people helping you out.

I've managed or worked as a developer on several projects where we were "Agile":

• One where I was lead architect and pushed Agile with the team, one by one. The project ultimately failed, but the team made more progress in six months than they'd made in the previous two years.
• One started as a management push with the guy assigned to promote it starting his pitch "I don't really believe in this, but...." (really, he had a slide with those words on it). It was used as an excuse for cowboy coding. We did "eXtreme Programming" - with no tests, no stories, and no pairing. Miserable failure.
• Ran a startup with Agile (XP) all the way and a team committed to it. We built exactly what our customer (marketing) wanted and nobody wanted to buy it.
• Was brought in to save a flailing project. Used some Agile methods so we could start demonstrating incremental progress. The goal never changed, so Agile's ability to deal with changing requirements wasn't helpful. The ability to demonstrate small, concrete progress was hugely valuable. Project released on the revised schedule we targeted when I came in. Buffed up the code enough to sell it (and the hardware it supported), which was management's goal from the beginning. Probably could have done it without Agile, but lack of information about where we were (nobody really knew how much work was left when I got there) made Agile helpful.
• Built an online system using the (then) newfangled Ruby on Rails. Customer took the "change" thing to heart so much that they were often reversing decisions made at the previous weekly meeting. We put change management into place that talked directly about what features they wouldn't get as a result of each change (really simple, just a piece of yarn on a blackboard, stories above the yarn were doable in the time/effort available, below weren't). Customer didn't take the Agile acceptance stuff seriously and would take 6-8 weeks to look at our releases (which by agreement with them were every three weeks). We managed that aggressively, added our own testing staff and delivered successfully.
• Did a prototype for a web system using Agile. Requirements changed radically week to week. Prioritized aggressively and delivered minimal working code as quickly as possible. As a result of the prototype, the client got angel funding. None of the prototype code was used for anything other than Angel demos.

What I've learned:

There is No Silver Bullet. Agile is a tool that can work on projects that hit the sweet spot. If you haven't got a clue, Agile won't help you. If you know exactly what you're building, Agile's flexibility will be of no benefit. If you are doing fixed price bidding, you need to be careful about the definition of "done".

Agile principle #2 (from http://agilemanifesto.org/principles.html): "Welcome changing requirements, even late in development." Other methodologies typically draw a line in the sand to recognize the costs of changing requirements late in development. They don't often forbid crossing that line, but they encourage people to honestly evaluate the trade-offs involved in changing requirements.

You're not supposed to follow #2 at the expense of all the other ones. Look at #3 from the same link: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." To do #3, you have to deliver something. If all you're doing is constantly responding to #2, then you'll never get to #3. Therefore, to "evaluate the trade-offs involved in changing requirements" is a necessity in Agile, too.

Agile principle #2 (from http://agilemanifesto.org/principles.html): "Welcome changing requirements, even late in
development." Other methodologies typically draw a line in the sand to recognize the costs of changing requirements late in development. They don't often forbid crossing that line, but they encourage people to honestly evaluate the trade-offs involved in changing requirements.

Teaching depends on the skills of the individuals doing it. No process or method can create that skill. Processes or methods can only ensure that skills that are there can be applied, but without the skilled and talented individuals, the effort is doomed.

A parallel I see is to software engineering. There are now decade long efforts to find the right process or method that you can then plug cheap, low-skill developers in and get good software. All of these have failed. Process can only help those already good to work without as little hassle as possible, but process cannot compensate for lower skill levels at all. Stupidly, management does not want to see this and still regards developers as interchangeable resources. Even when the creators of a particular process clearly say that the process is far less important than the people applying it (e.g. with Agile, see here http://agilemanifesto.org/), management does not want to listen.

I suspect that it boils down to a question of ego. Those managing software creation (or managing education) typically have a perception problem where those doing the actual work are perceived as less important than those managing it. In fact it is (rather obviously) the other way round. This may also be a principle problem of our day and age: Management that does not understand it merely has a supporting role and serves to create conditions for others to do what is really important. I fear that without radically different selection of management based on psychological profiles that prevent those seeking power from getting into management in the first place, neither problem can be solved.

Hey Guys I've been working on a software company that uses Agile Methodologies for software development for more than 8 years now. And let me tell you something about Agile and Scrum, for those that didn't get the full grasp of the concepts: Agile is a software development methodology that focus on iterations to rapidly getting working software, over process, tools and extensively comprehensive documentation, and also focus on the end users feedback during the software development iterations of the working software, to respond much faster, and within budget, to changes. This is a very short description of the Agile Manifesto that you can find on the web. The benefits of the Agile Methodology is not for manager to keep track of the coders productivity and control team or individual KPIs, but to focus on what it's important: to get working software that responds to the market/business or end users real needs. So instead of having a full and comprehensive 200 pages requirement's document at the beginning of the project, and take 1y and a half to deliver the first running version, you get a smaller and lighter version of the overall requirements, and present smaller working demos of the software every 2 weeks or 3 weeks, giving the change of the end users and the business itself provide their feedback, allowing to change the application in the next iterations, and with new requirements that usually didn't match the 200 page requirements document of the beginning of the project afterall. Regarding Scrum, Agile Software Development Methodologies is much more than just a 10 to 15 minutes scrum of the ongoing work. Scrum should be a very short status meeting to address how to overcome technical difficulties from the current iteration, and not just present a "how the project is going" report to managers. The Scrum Master is not necessarily a manager, but usually, due to it's experience, can also be a team leader. But it's main role in a Scrum is to drive the scrum, and focuses it to what's really important for that iteration to guarantee that all developers are aligned an on scheduled for the working (demo) software version. Usually, in the scrum, the Scrum Master shouldn't care if the developer has been coding fast or not, but he needs to provide immediate decisions or action items to address any presented problem. And even though this is definitely all about programming, adopting Agile Methodologies must be wide spread throughout at least the team using the methodology, but in the end, for the entire company R&D. In this blog there's also more information on the basic steps that a company should take to adopt the Agile Methodology, a concrete approach for Enterprise Rich Web Applications Using Agile Web Methodologies. In the end, the team or company, doesn't necessary needs to adopt all sets or rules and guidelines of the Agile Methodology. Like the methodology it self, it can be an iterative and ongoing process. Cheers

Read up on Agile.
As a programmer I have felt the most empowered, gotten the most enjoyment, and positive feedback, by working in an Agile scrum team.

I second this; the agile process works quite well. If you're new to the process, attend a scrum master course.

It emphasizes transparency and makes problems apparent much earlier than traditional processes.

See: http://agilemanifesto.org/

I'm reading lot's of ragging on Agile here. Maybe you guys should actually f*cking read the agile manifesto. It's only a few sentences after all. You'll notice that it's actually quite a good thing that tries to rid the software devprocess of bloat and get close to the people for whom software is written.

Whenever I've used agile with the right people, it was a breeze getting the job done. It's basically common-sence systematically applied to software developement in my book.

Yes, I know, another fanboy touting how great Agile/Lean is... But seriously, I am an embedded developer for Flight Management Systems. I have been doing a lot of soul searching in this area. I have to tell everyone that the principle of Lean and Agile really do make sense, in particular for design documents. For the development we do, we are bound by DO-178B so we have to have some design "documentation" because there are objectives defined that require proof of compliance. The rub is that out of the 60+ objectives defined only 3 pertain to "design" (40 are for verification).
If you take the primary principle of Lean, which is "if work does not contribute to the final product it is muda {waste}", the exception to that "if work is required by an authority and does not contribute to the final product, do the minimum".
Now, take the Agile Manifesto into account which states "working software OVER comprehensive documentation" and to me, design documentation is a waste. We generate tons of useless design documents. We have tribal diagrams that supposedly tell me something about the system, but get out of date and require me to go to the tribal elder to decipher them. No, here is what I say (sorry it took so long to get to the point)

Design diagrams and documentation is needed, but only when you are crafting a new architecture and most importantly should only be used to get a code class/package architecture or development plan (which set of design patterns are going to be used, interfaces, etc.) Once the software takes form THROW OUT THE DOCUMENTATION and use a good tool to auto generated documentation from your software. Be vigilant about refactoring. If something breaks the design don't bolt on a fix. Refactor it, then regenerate the design.
Whenever possible, use self-documenting code or something that can auto generate code. We have a lot of interfaces and we get a little "ICD" happy (that's Interface Control Document). We have yet to realize ICDs can take any form and we should be using a form that can be used to generate a code module that represents the interfaces.
So in short (yeah right), design diagrams and documentation is a good place to start, but it is a means to an end. The end is good quality, well architected code. Oh, and spend your time doing some form of unit testing or something rather than creating useless design documents.

Of course, it's always entertaining to imagine how much better I could run the country. If you were going to pick an SLDC as a hypothetical model, I would prefer models based on Agile Principles, perhaps with some scrum. These would also address the concern of time. Some of the characteristics of such a system might be:

• The congress (as product owners) defines the intent (e.g. User Stories) and acceptance cases in brief non-technical terms. Perhaps the full congress must ratifies this brief statement of intent before some comittee continues to work out the details.
• QA moves upstream: There is immediate (judicial) review that validate that legislation meets its intent, does not violate the constitution and so forth. I don't ship incomplete features, congress doesn't ship bad legislation. No easter eggs in software or legislation. Some control that ear-marks are in line with the intent of an appropriations bill, and so forth. :)
• Remember who the "customer" of legislation is - "for the people". I preview my software very early on to ensure it works. Perhaps face to face demonstration and explanation of legislation to stake holders becomes required. For example, city lawmakers wishing to criminalize sleeping in public places would have discuss with stakeholders (the homeless) how to make this legislation workable. We can have fun with this one :)
• Congress might also set some high level acceptance cases for all legislation, which must be met. Beyond constitutionality, they might demand that all legislation is budge neutral.
• Anyone can submit to the backlog. An initiative process would differ and be lighter weight: Initiatives might mandate the acceptance cases, binding professional lawmakers to create legislation within those parameters.
• Prototype and pilot legislation. Perhaps congress could find volunteers among states to assist in this. Texas might like no child left behind, but Oregon thinks it has serious unresolved problems.
• Ranked priority for legislation. Congress prioritizes their issues and must pass the laws in order of priority. No holding that hard budget bill to the last minute.
• Direct quote from agile manifesto:
  Simplicity--the art of maximizing the amount of work not done--is essential.

Sure, I think we all feel that way after reading this story. But the error could also lie with the Agency. If they are constantly asking for changes and new additions, what can the programmers do.

It seems to me that the idea of doing software as a project is purely fiction. Everybody knows that software has bugs, everybody knows that new features are needed as the landscape changes, and everybody knows that software can be made better. So why do people insist on this flawed idea of a project?

I've come to realize that properly specifying software in advance is unrealistic. People have a tough time thinking through what they actually need a system to do - nobody really knows what they want until they realize that what you have is not it. Then, they'll gladly whine about what's missing.

So I've come to embrace Agile software development as my strategy.

At my small, ASP software company, we don't sell software, we sell its utility. We manage information for school districts, and take all the work out. We do backups, upgrades, maintenance, etc. so the school district can get back to what they do best - teach.

We do upgrades very rapid-fire - often releasing more than once per week. We have a big, huge list of stuff we'd like to do, and as we move forward, we develop whatever's the next most important thing on the list. The list comes primarily from customer whines. We charge hourly rates for development, and basically refuse to bid by the job.

This lets us be VERY flexible as we learn more about the actual needs of the districts we work with - often changing specifications as development is happening. We don't focus on making things "bug free". We focus on fixing bugs rapidly, particularly when they cause a problem for the end user. This lets us get to what's actually needed by the customer FAST. And they LOVE IT!!!

An interesting side-effect of this methodology is that "feature creep" basically disappears - unnecessary features get pushed off because, even if they're cool, they're not what's "needed next" and so get filtered out.

When a change is needed, there's a simple evaluation of "is this important enough to do next?", and this evaluation filters out the crap ideas. Thus, problems like feature creep, bloat, and design by committee, effectively disappear as problems.

I can't stress this one enough!

As architect of a small software company, the most frustrating aspect of designing software is the knowledge and understanding that there's no way to know how to do it right until you deliver something that's wrong. People almost never seem to know what they need, but they do know that whatever they have isn't it, and they'll tell you why.

So, we have a very different tack, similar to Agile Programming. When we implement a new feature or functionality tidbit, we release very early - pretty much as soon as it more or less works without major errors, - with as much fanfare as we can manage on the cheap, and then wait for the feedback.

We're very up front about it, and openly welcome the feedback and ideas. This takes any conflict out of the relationship and turns it into a sort of partnership. Customers love being listened to, and feedback we get, in droves. When a customer sees THEIR idea implemented a week or two after they suggest it, even when it's something stupid-simple (such as having a particular button selected by default to avoid a common mouse-click) then they're your advocate for life!

It's that continuous, iterative cycle that's resulted in our young, 3-year-old codebase having eye-popping features, and remarkable stability. The software updates itself at the client's discretion, so nobody seems to mind much. They update as often as they like.

With this model, there is no due date. It takes me about 15 minutes to issue a release of our software. The idea of a "release" means almost nothing - we've done more than one in a day! (we've released 46 official releases in the past year alone, with too many "unofficial" releases to count)

Faced with this "impossible" situation, (I've lived "impossible" schedules for years now) I'd step UP the release cycle and start pre-annuoncing alphas/betas of the product the instant that something that appears demonstrable compiles and can be stuck on a dev server someplace. Invite comments and download. Call people to ask about feature X or Y. Let them know it's really early, and make sure that they have a place to bitch about the problems they find.

When you do, you'll be surprised how much of what you thought was required was, in fact, completely un-necessary - or at least could be put off until next March for a future release. But, you'll find some simple, straightforward ABSOLUTELY GOTTA HAVE that takes a man-month to code that the users would sacrifice their firstborn to have.

Agile software methods will find this "gotta have" pretty quickly. The waterfall model of software development would take a decade.

You decide.

This model won't work for all products and/or markets. And it's very important not to take away functionality that the customer previously had, or they get the feeling that you're taking something away, and that's bad. But for us, it's been very, very successful, and the relationship we have with our clientelle is very friendly, close and intimate.

PS: Maybe it helps that we're an ASP.

Oh, and the research isn't intended to make auto-driving cars for you and me. They want to create a way that cars do exactly the same test runs on test-tracks to check the settings of the car. The results would be more reproductible. If anything, this tech is to put test-drivers out of work ;-)

Which brings into mind something that I've really run into repeatedly as a software engineer - the difference between tests and reality. It's amazing what people do!

I've long been an advocate of agile software development methods such as Extreme Programming because of its ability to deliver software that works fast with minimal resource expense. However, the test-driven model of software (compose the test first, then write the software to match the test, then refine the test, wash - rinse - repeat) fails to account for the scenario unforseen by the test writer.

People can do some very unexpected things. For example,

1) They can double-click on a web link, as they've become accustomed to with everything on the desktop, causing it to be processed twice. (caused serious hell in one case)

2) Make extensive use of the back button, even when it makes no sense to do so, then causing duplicate entries in a multi-stage process.

3) Click "OK" on a bright red, dire warning with bolded letters and even type "I UNDERSTAND" in all caps, without ever reading anything, and then complain bitterly about the result.

I've seen all of these, and many more, and have learned that what constitutes a "bug" is very, very VERY relative to what the user expects. The software could work perfectly to spec and design, and pass immense testing, and be exactly what all involved agreed was just critical - and still be perfectly and totally unusable.

Thus, my focus has shifted slightly from XP to so-called "Agile Programming - less emphasis on formalized testing and more emphasis on user feedback. Our software has a software development turnaround cycle of about 1-2 weeks. We implement few fixes or features, test to a "reasonable" standard, and kick. Wash, rinse, repeat. Expect any new development to be adjusted or refactored 3, 4, 5, even 10 times after release.

We've kicked out some 46 releases of our software in the past year alone. The software updates itself in just moments, and the update is voluntary - if the user doesn't want to, they click "OK" one time when they start the program.

Reviews in our industry of our product have been rave. It works!

Determining whether something is "Agile" depends on the etymology of the term. In a general sense, anyone can come up with their own fitting description, though the colloquial use of the term refers to any method that adheres to the direction in the Agile Manifesto, and follows the principles behind the manifesto, all of which was crafted by the Agile Alliance (of which Beck is a founding member).

You'll note one of the principles is "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." It doesn't really matter if those intervals are "every day" or "every 2 weeks", so long as there is some kind of rhythm. You say XP was not designed in this way, and I strongly disagree. Kent had 3 day iterations on one of his Swiss projects circa 1999-2000, and was working on moving it to 1 day iterations. There is nothing inherent in XP to mandate a period for iterations, other than there must be a period. If you do it "whenever there's stuff to show the customer", you lose rigor in your ability to measure and control the process. The latter could work, of course, but it's just less repeatable.

And as for whether something is "Agile" or not, the person I usually turn to is Alistair Cockburn, probably the most experienced software project anthropologist out there. While he's critical of XP, it certainly is considered agile. So I must disagree on your point. Judging by the vehemenance of your claims, I doubt I'll be able to argue further, thus we'll have to leave it at that.

The big difference between agile methods like scrum and extreme programming as compared to other methods like RUP or waterfall is how they treat the "iron triangle" of schedule, quality and scope. Agile methods specifically say: sacrifice scope in favor of super-high quality and fixed very short schedules. Scrum, for example, recommends that teams produce potentially shippable software every month. Potentially shippable doesn't mean every feature under the sun, but it does mean that it should be production-quality. As for large organizations adopting agile methods, there is definitely a transition period where the focus is on getting used to the monthly cycle and gradually increasing quality from the organization's norm to a much higher standard. Sometimes this can take a couple of years. This type of schedule does cause a huge amount of pressure... but every agile method that I know also encourages a sustainable pace including very little overtime work. I have worked on many agile projects over the last nine years and every time the benefits have been clear and compelling. Nevertheless, it is possible, like with anything else, to screw it up and have a bad experience with an agile method. Pair programming from Extreme Programming is a great example of this. It is a fabulous way to increase quality without sacrificing productivity. Yet it is also such a huge change for many developers that it needs to be adopted with great sensitivity. If it is imposed, then people will rebel against it and cause it to fail. Same with agile methods in general. I've seen them work too many times to not be a believer, but if one's first experience with an agile method is a disaster, it can be pretty hard to see how they might help: be more effective, more humane and more fun. I strongly recommend that people check out the agile manifesto and the agile work axioms to understand the underlying ideas behind the agile methods.

The OSI layer was (and, for the most part, still is) a pre-code spec. Most successful specs, in particular IETF specs such as the TCP/IP suite, are *post code* specs; they were written after or concurrent with code that implements the spec (this is an IETF requirement).

Specs written before coding commit software development projects to a higher degree of complexity in a single stage of software development (specification). This additional complexity results in an increased risk of software defects in that stage and in later stages, and, independently, increased costs to implement and maintain the software.

Simplicity rules software development. Software projects succeed or fail exactly because they do or do not prioritize simplicity first. Humans are cognitively mal-adapted for comprehending non-simple systems. Exploring the spec formally (by coding it) helps humans understand complex systems. Specs are not bad, so long as that spec is code.

These are some of the tenets of Agile software development.

So, I release early, I release often, and I listen closely to the feedback. Users get what they want, and I get what I want.

http://agilemanifesto.org/