Slashdot Mirror

Well, my take on it is that agile is not actually Agile.

ie, all the rubbish people do to pretend they're working in an agile way is just an excuse to do far less work and far more process. Just the opposite of what Agile is all about.

Alistair Cockburn said it in his Shu Ha Ri page - agile is about Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone

It is not about daily meetings, more meetings, more review meetings, postits in place of documentation, more meetings to discuss what postts to put in the meeting you're going to have the next day to confirm the postits you decided would be in the next planning process...

I think I should start a new agile methodology - the bugtracker agile system.

You have a bug tracker (where bug also means task, requirement, change or just plain bug) with as many bugs in it as you can think of to get the project going (should be easy - you know what you want after all). Then you tell your dev team - here's the bug list, get on with it. I'll be back in a month to see how you're getting on, you'd better have something to show me - tech docs at least if not some form of running product. If you have any questions, ask Dave the customer liaison chap (or tech architect fellow, or product owner bloke), he'll clarify any confusion in the requirements.

And that's it. Trouble is, I doubt I'd be able to sell many books or conferences with that. Pity, 'cos it works.

I did the IT support for a top ten engineering department for almost 10 years.

I half agree with TFA.

Most online tools (Blackboard here) are not that great about making it easy for the instructor to upload content and to migrate it between semesters.

About the nicest thing I could say is that having the grades online is nice.

Of course, things could have become better. It's been 2 years since I directly supported faculty in that matter.

The heart of the matter is the idea I've borrowed from the Amish. Their Ordnung.

What is the purpose of the technology? How does it affect the community?

If it doesn't really improve things for the instructor and the student (in the instructor's view mostly) then why use it?

Most faculty really just need a place to upload files to share with the class and that's about it (as has been mentioned earlier). They (or their TA's) still need to create and assign homework, quizzes, exams and project; and then grade all of that. Not easily automated.

Some (most in my opinion) transfer of knowledge is best done when you can interact with the person. I think this image best illustrates that (from Software Development as a Cooperative Game).

A technology has to be useful and have a purpose beyond itself.

I did the IT support for a top ten engineering department for almost 10 years.

I half agree with TFA.

Most online tools (Blackboard here) are not that great about making it easy for the instructor to upload content and to migrate it between semesters.

About the nicest thing I could say is that having the grades online is nice.

Of course, things could have become better. It's been 2 years since I directly supported faculty in that matter.

The heart of the matter is the idea I've borrowed from the Amish. Their Ordnung.

What is the purpose of the technology? How does it affect the community?

If it doesn't really improve things for the instructor and the student (in the instructor's view mostly) then why use it?

Most faculty really just need a place to upload files to share with the class and that's about it (as has been mentioned earlier). They (or their TA's) still need to create and assign homework, quizzes, exams and project; and then grade all of that. Not easily automated.

Some (most in my opinion) transfer of knowledge is best done when you can interact with the person. I think this image best illustrates that (from Software Development as a Cooperative Game).

A technology has to be useful and have a purpose beyond itself.

No, we do as a team get together to plan, but we do far too much of it That means that planning, not doing, is what we're spending all our time doing. Our agile processes are bolloxed up.

the concept of disappearing for 2 months to solve a problem is actually pure agile. It may not work for you, and it may not work for your organisation in which case it's not the process you want (agile doesn't mean - follow this exact process or else).

Alistair Cockburn (one of the original agile movement people) has this to say about agile:

One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words:

        "Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone."

That is agile. Really. The fact that agile can be other things doesn't detract from it. sure, you might not be able to do that, or you might not want to do that.. but it is still agile.

One thing that is definitely not agile is getting bogged down in processes. Agile is all about freeing yourself from the processes that prevent you from delivering what you're supposed to be working on. Planning, documentation (unless it's required by the business need), specifications, test plans, meetings, all of these things are overhead - you might need them, you might need to do them to some extent. But you must recognise that they are not what you're supposed to be doing and as such should be minimised.

Too often the planning and meetings take precedence over delivery. That's exactly what agile was developed to overcome. Take a look at the agile manifesto.

the quantity is also very important - if you have a team of 10 developers, you can't let them just go off working on their own thing hoping it'll come up with your customer's exact requirements.

Now, if you had an infinite monkey cage, then your options are more flexible and you can use the same development style as Anonymous.

But.. there is a way it does work - if you have a small team, of senior people, who are committed to your development goals... then you can put them in a room without supervision and tell them to make the requirement happen. That works, but it works by reducing the amount of interference, not changing the way people work. (BTW this is one of the Crystal Clear agile methodologies by Alistair Cockburn)

what you have does certainly sound similar to Alistair Cockburn's Crystal Clear methodology, in particular his ShuHaRi" system of determining the appropriate level of expertise/handoff required:

One member in the Crystal family of methodologies is Crystal Clear. Crystal Clear can be described to a Level 3 listener in the following words:

        "Put 4-6 people in a room with workstations and whiteboards and access to the users. Have them deliver running, tested software to the users every one or two months, and otherwise leave them alone."

I did, in fact, describe Crystal Clear in those words to a savvy project sponsor. He followed those instructions and reported five months later, âoeWe did what you said, and it worked!â

you see, if you have good developers you can do this. If you have crap one, you can't. That's pretty much what it all comes down to.

People have grown tired of these "young whippersnappers" fresh outa college with their executable UML and agile methodologies.

It's worth noting who invented those agile methodologies:

* Kent Beck, coinventor of extreme programming. No date-of-birth generally known, but worth noting he has been a professional developer since at least the late eighties. I'd guess he's in his late 40s by now.
* Ward Cunningham, coinventor of extreme programming, inventor of the wiki. 59 years old.
* Ron Jeffries, coinventor of extreme programming. No published date of birth, but has been programming professionally since 1962, so I'd imagine he's around 65.
* Ken Schwaber, coinventor of scrum. No publicised date of birth, but "a 30-year veteran" of the development industry.
* Jeff Sutherland, coinventor of scrum. No publicised date of birth, but a vietnam vet, so must be around 60 by now.
* Alistair Cockburn, inventor of crystal. No publicised date of birth, probably the youngest of this bunch as he looks mid-thirties in his photos.

Agile methodologies are far from being a young person's game, and looking at this bunch shows what over-35s can achieve.

Pair programming is a drastic waste of programmer time.

What you typically get is an alpha who overwhelms and neutralizes the work of his partner.

• Problem 1. The people on the projects were not interested in learning our system.
• Problem 2. They were successfully able to ignore us, and were still delivering software, anyway.

The fundamental characteristics of "people" have a first-order effect on software development, not a lower-order effect. Consequently, understanding this first-order effect should become a first-order research agenda item, and not neglected as a second-order item. I suggest that this field of study become a primary area in the field "software engineering" for the next 20-50 years.

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.

Cockburn's papers describe the evolution of his ideas on software development as a cooperative game.

Cockburn's papers describe the evolution of his ideas on software development as a cooperative game.

its OK, nor am I.. err, an anti-XP zealot that is :)

I just think that it goes a little too far in its quest to be lightweight.

Peer programming is not a good idea, IMHO, as you get better 'value' from code reviews instead. (kind of like peer review afterwards instead of during - and besides, any peer programming I know of, one person codes, the other yawns, watches out the window, daydreams of Sharon in accounts, etc)

No documentation is good - as long as there is documentation produced by other means.. auto generated by code comments for example. But zero docco is a very bad thing for a project overall.

Test cases for everything before coding.. good if the design stays the same, but there is no design up front for XP, so how do you code the right stuff? Only if you've designed the test cases properly, and then write the code to fit the test - XP doesn't allow you to do *enough* design up front.

All that's my opinion. All in all, I think that if XP is 1 (on a 1..10 scale) and RUP is 10, then I'd be really happy with a methodology about the 3-4 mark.

Cockburn has some comments about XP on his crystal clear site - read his 'balancing lighness with sufficiency' article. The single best thing he says is, use the methods that work for you and your team.

don't forget that UML usage is driven mainly by:

a) the UML tools vendors who say its the best way to produce quality in your projects
b) the people (managers usually) who believe all the stuff a) wrote.

Personally, after seeing UML used to get nowhere, I would always go for a lightweight development methodology (like XP which I dislike, or Crystal Clear)

This thread is turning out better than some others about Extreme Programming, like here and here.

I worked on a project that used XP for most of 2001. It was a liberating experience. We had two domain experts who also acted as XP coaches, which helped a lot. Our biggest problem was convincing some team members to suspend their disbelief long enough to give the XP practices a chance. At the end, we found we were about 50% more productive than similar, non-XP projects, despite spending a lot of time cutting excess code out of the project. About 20% of the source code was devoted to unit tests and mock objects to support the tests.

When budget-cutting forced us to halt development abruptly, we had 12 known bugs. 11 of them were GUI problems, which we could not easily unit test. We had 70-80% unit test coverage, most of it written under the mantra "write the test, then the code." This turned out to be a key factor in our code quality.

Having all those unit tests in an automated test framework gave us tremendous confidence to keep moving forward. This leads to the other key factor TDD provides a project: freedom from fear. Why worry about failing the regression tests at the next code freeze when you can run them every hour?

Our XP project convinced me that one big reason for quality problems in C-language software is the lack of automated unit test tools. Sorry, that's just another good reason to move to OO, even for embedded systems.

TDD is still valuable without the other XP practices. Short development iterations also deserve wider use outside XP.

For all the naysayers... Look, nobody is saying you have to abandon experience, judgement or common sense to use XP. What you have to do is immerse yourself in the experience -- add the flow of programming the XP way to the other tools on your belt. XP is a little harder than riding a bicycle, definitely easier than Tuvan throatsinging, and as hard to describe on the printed page as both.

That said, Kent Beck's testing book is pretty thin. It adds very little to what you'd get from reading Extreme Programming Explained plus the JUnit tutorial. To understand why people "get religion" about TDD, understand why people are religious about the most effective ways to get software development done. Two views that come to the same place from vastly different starting points are Alistair Cockburn's excellent book, Agile Software Development , and the "lean software development" material at Mary Poppendieck's website.