Agile development?

Hi!

I just started working on a new company and the first project I got (handover) had absolutely no documents, processes or anything. And when I asked why there are no design documents, data models etc they said we are working with agile development. I always thought this is cowboy programming... and I have always worked using classic waterfall and iterative development. My question to you, where do I get benefits of using this cowboy programming. The project has 1 programmer/architect (me) and one it-projectleader and one customer. The project is about 500 hours and is split into 3 phases.

As I feel it this project doesnt qualify for using agile development, because the team has no senior programmers, the requirements shouldnt change very much over time etc....

what do u think?


Henrik

"agile development"

Where do you from? I've heard the phrase for the last few months and seems to be a kind of buzzwork managment are currently using!

It has its benifits for the developer but also requires the developer to think (not somthing many programmers do - They prefer a spec and to code as told)

I like the idea of it but it could be frustrating taking work back and forth until it is correct!

Wikipedia has a good article on it.

While I've never worked anywhere that used the "Agile" buzzword, I have worked on a number of projects where this kind of development was normal and I've worked places where "the process" was king. I've found the agile places to be much more rewarding and enjoyable places to work.

It is different from "cowboy" coding since you should have a roadmap of requirements and rough, but useful, plans that tell you where you're headed. These probably won't be formal documents but make take the form of a long email or other collaberative informal document. Plus you must have close interaction between the developers and the business team sponsors of the project so that you can ask them questions and further refine your ideas and assumptions. Also, the short delivery iterations will keep you focused.

What you don't have is someone complaining that you didn't properly fill out section II, chapter 8, part 6, sub-group 7 of your technical design document. To me, that's a huge plus right there. Such tight processes are desirable when you're developing Space Shuttle software or other life and death situations. However, they get in the way if you're simply developing a new reporting program for the accounting department.

I've seen some downsides to this kind of development as well. If you stray from short delivery cycles and close interaction it can easily become a mess. If you have a project sponsor that you can't get a meeting with or who is out of contact for long stretches of time it can lead to project failure. If the project sponsors or persons within the development team like to play office politics the lack of a paper trail gives them additional power and this can lead to unfortunate situations.

One area where I differ from some 'Agile purists' is that I think some documentation is needed to avoid what I call the "Tribal Knowledge" trap where one or two developers control all the knowledge and can and often do use it as political leverage within the company. It also provides some security to the company should the "hit by a bus" or "programmer wins the lottery" scenarios play out. Some documentation, even if it's done after the fact and not perfect, complete or entirely consistant, is better than nothing at all.

Wow, I just realized that I do agile programming. I've never embodied a buzzword before....this is one of my proudest moments....ok, I'm over it.

There are times when this makes considerable sense to me, and the time is when you are doing something totally novel to meet a vague concept that somebody has asked you for. How often does this happen? Probably it is somewhat rare for most people, but not for a fish biologist.

Oh yeah, there's one big potential problem. I always encounter feature creep, as I keep thinking up nifty new ideas I could add. Since the people asking for the program usually just say, "Yeah, that would be cool." Things happen.

Agile development does not imply lack of documentation. That is the fault of developers who decided that the documentation was not required. We're using agile development here, which is a buzzword I know, and we faithfully document everything so that anybody can pick up our work at anytime.

Agile development is a purely management term in my book.

The project manager can focus on short deliverables and ask the client what they want next, code it, and then see if it fits the deliverable.

I wouldn't say it necessarily falls on how documentation is developed and implemented. Documentation should always be present regardless if the management technique is waterfall or agile.

I could categorize a rose as a flower or a plant, and yet both categorizations would be correct. It's all on how people conceptualize it.

Same applies to Agile vs waterfall. It is a buzzword created by consulting companies (to increase marketability - 'we use Agile!'). Yet, most shops implement waterfall and agile simultaneously or indepedently at any time without realizing it.