What's the deal with 'agile development'

[Monster_Munch]

I'm hoping to switch jobs sometime this year and I've noticed that a lot of job postings mention you must be familiar with agile development methodologies. I'm not really familiar with it at all. I think the methodology we practice at my current employer (or attempt to practice) is the IBM Rational Unified Process. I'm more of a code monkey to be honest but I have written some design docs and UML diagrams before.

Is agile something I can bluff in interviews? Or do I actually need to read up on it?

 

[LumbergTech]

i googled it for you....basically the same stuff they told me when i learned about it in school

from wikipedia: http://en.wikipedia.org/wiki/Agile_software_development
Individuals and Interactions – in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.
Working software – working software will be more useful and welcome than just presenting documents to clients in meetings.
Customer collaboration – requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.
Responding to change – agile development is focused on quick responses to change and continuous development.[6]


Twelve principles underlie the Agile Manifesto, including:[7]

* Customer satisfaction by rapid delivery of useful software
* Welcome changing requirements, even late in development
* Working software is delivered frequently (weeks rather than months)
* Working software is the principal measure of progress
* Sustainable development, able to maintain a constant pace
* Close, daily co-operation between business people and developers
* Face-to-face conversation is the best form of communication (co-location)
* Projects are built around motivated individuals, who should be trusted
* Continuous attention to technical excellence and good design
* Simplicity
* Self-organizing teams
* Regular adaptation to changing circumstances

 

[HumblePie]

All it means is that a code monkey you are going to now be required for constant meetings as the customer usually doesn't know exactly what they want until they see you whip something up using some really vague general ideas. Then everyone starts narrowing down what they really want. You can be meeting with your "customer" daily or at least weekly.

Same old same old with just a new name spin to make it seem like it's cooler than it really is for management. As a code monkey it just means you get to deal with feature creep ALL THE TIME and it has to be accepted.


But usually development means you are sitting at a computer with another programmer working together on the same project. Sometimes they are typing code and sometimes they are. That is part of it as well.

 

[DaveSimmons]

It's the new flavor of Rapid, Iterative and Xtreme development, aka the new new silver bullet.

I guess it's different than RAD-I-XP in formally accepting that for many projects:
- It often costs more than it's worth to fully spec out an application before development starts, outside of aerospace and military.
- Users don't fully know what they want in an application until after they use it.
- Delivering a subset of the original plan then adding more later is what usually happens anyway, so you might as well plan to do that from the start.

And it sticks with the idea that, like Voltron, you can bolt together weaker developers to make one stronger developer.

 

[brandonb]

Agile is closer to what a hobbyist may do. It's basically a no direction, no management, no design plans (well nothing elaborate, maybe very high level)... You are then told to make it work.

 

[Markbnj]

Ha, love these replies, and agree with all of them. When all you have is a silver bullet, everything looks like a vampire... or something.

 

[degibson]

When all you have is a business degree, every buzzword looks like the next big technological revolution.

I.e., Agile programming.

 

[Cogman]

When all you have is a business degree, every buzzword looks like the next big technological revolution.

I.e., Agile programming.

Well, it is more a problem with being human. "This new technique will solve all the ills of the old techniques! You should totally use it!" You see this line of thinking for new stuff everywhere. Nobody is immune. Dieting, Marketing, programming, anything. Fads exist for everything.

I consider this part of the reason that we have so many different programming languages. There are large enough groups of people that believe that their way of doing things is absolutely better than the status quo.

 

[BoberFett]

But usually development means you are sitting at a computer with another programmer working together on the same project. Sometimes they are typing code and sometimes they are. That is part of it as well.

That's pair programming, which may or may not be used as a part of agile development.

 

[linkgoron]

Why all the hate for agile development?
I just think the word agile sucks, and iterative/incremental development is a better word. Agile in itself is just a subset of development methods.

Either way, Agile development usually means Scrum, but XP, Lean, Crystal etc. are all considered "Agile Methodologies".

Agile is closer to what a hobbyist may do. It's basically a no direction, no management, no design plans (well nothing elaborate, maybe very high level)... You are then told to make it work.

You've been doing it wrong.

I also won't consider it "new"... But that's me.

 

[Markbnj]

Why all the hate for agile development?
I just think the word agile sucks, and iterative/incremental development is a better word. Agile in itself is just a subset of development methods.

Either way, Agile development usually means Scrum, but XP, Lean, Crystal etc. are all considered "Agile Methodologies".


You've been doing it wrong.

I also won't consider it "new"... But that's me.

I don't think it's a matter of hate for agile development, per se. I can only speak for myself, but my problem is not with the ideas of agile, it's with the legions of suits and consultants and gurus who are always looking for methodology-based ways to "fix" programming, when the problem with programming is that we get shitty requirements from people who don't have a clue what they're asking us to do.

Until the people who commission new software systems regularly give them even half the care and attention (and flexibility on schedule and cost) that they would give a new addition on the back of their McMansions, as far as I'm concerned they can take whatever their latest shiny bullet is and lube it for ease of insertion. And that goes triple for patent absurdities like pair programming.

 

[Monster_Munch]

Either way, Agile development usually means Scrum, but XP, Lean, Crystal etc. are all considered "Agile Methodologies".

I've seen a few places advertising a position for a Scrum master. I guess that's the team leader in agile speak.

I really just want to write code, but I also don't want to be trapped on the < £30k salary that entails. So I feel like I have to start thinking about how to transition to become a "senior" developer instead of just a regular developer.

How did you guys go from junior to senior?

 

[KIAman]

The biggest requirement for agile methods is for you, the developer, to be extremely flexible and can put on many different hats. It is a mentality that everyone can do everything, and must be good at it. It is also vitally important that the stakeholder has bought into the agile method as well.

You must be a good bunsiness analyst to strangle the correct requirements out of the customer. You must be a good systems analyst to turn those business rules into technical and non-technical requirements. You must be a good project manager to break down the requirements into manageable chunks and give good estimates and assign resources and time. You must be a damn good programmer to hammer out a WORKING prototype within a day or two. Then you must put on your business analyst hat and present the prototype to the stakeholders and start the iterative cycle over again.

In short, if you're a mumbling stapler-guy programmer, you will fail at agile methods.

 

[KIAman]

I've seen a few places advertising a position for a Scrum master. I guess that's the team leader in agile speak.

I really just want to write code, but I also don't want to be trapped on the < £30k salary that entails. So I feel like I have to start thinking about how to transition to become a "senior" developer instead of just a regular developer.

How did you guys go from junior to senior?

You write code... yay. <-- junior

You'll eventually realize that anybody can write code, you move up a step. <-- midlevel

Once you start learning how to write CORRECT code, you move up a step. <-- midlevel transitional to senior

Once you can consitently mentor others how to write CORRECT code, you move up a step. <-- senior, lead

Once you harbor an environment for others to move up in this type of progression, you move up a step. <-- lead, technical manager, manager

 

[BoberFett]

...and when you realize that the business world is insane, you become a consultant and make a metric assload of money by repeatedly creating and solving problems.

 

[Cogman]

...and when you realize that the business world is insane, you become a consultant and make a metric assload of money by repeatedly creating and solving problems.

Or you could just make 1/2 a metric assload of money by just repeatedly creating problems (the easier route) .

 

[mosco]

I've seen a few places advertising a position for a Scrum master. I guess that's the team leader in agile speak.

I really just want to write code, but I also don't want to be trapped on the < £30k salary that entails. So I feel like I have to start thinking about how to transition to become a "senior" developer instead of just a regular developer.

Generally a scrum master isn't a developer.

Agile isn't for everyone or every group. Alot of people have a problem with it because they just want to go to work, code, and thats it. But there is a place for a lot of agile methodologies and personally I really enjoy the interaction and team work that goes on. I am working on a project right now using agile methods and it's been great.

 

[iCyborg]

Alot of people have a problem with it because they just want to go to work, code, and thats it.

Funny, because I thought those would be the people who would have more problems with a more conventional approach with distinct phases and longer cycles

 

[GodlessAstronomer]

A lot of uneducated people weighing in on this one.

 

[Cogman]

A lot of uneducated people weighing in on this one.

And what are your thoughts on the subject?

 

[EagleKeeper]

From working on a couple of recent Agile projects.

1) Rather than a large project; small components are planned that can be attacked/completed in a short time cycle 2-4 weeks.

2) Each component is tracked closely in terms of progress and problems

3) The first couple days of a cycle are used to identify components and assign to team members. Estimate is made on the complexity of the component and assigned a weighted value. Team also creates estimates on available time to work on components.

4) There can be multiple components assigned to a given team member. One does not want the team lead to be overloaded though.

5) Daily or close to that freq, the team reports their status and identifies any issues.

With luck, they will have matched the selected components with available time within the cycle.

A couple of issues that I have spotted:

6) The cycle time can be to tight, not allowing proper analysis of the components effort.
This creates an unreal expectation of what can be accomplished. By the time upper management sees the workload, they do not expect that there will be any adjustments.

7) The cycle time may not allow full comprehensive testing. A simple unit test may be done and the work checked in which can break the overall system during a full test.

8) One cycle in a series should be dedicated for full regression testing.

9) Pressure is created via #5 to meet schedule no matter what. This leads to mistakes being made #7

10) Slop time must be accounted for when planning the schedules. Depending on how far the project is matured; maintenance issues may pop up that will require handling. Unless there is a dedicated team in place for such; that time impacts the planned component implimentation time.

Procedures/tools being changed mid stream or between cycles will have a drastic impact of results; much more than expected.

 

[KIAman]

From working on a couple of recent Agile projects.

1) Rather than a large project; small components are planned that can be attacked/completed in a short time cycle 2-4 weeks.

2) Each component is tracked closely in terms of progress and problems

3) The first couple days of a cycle are used to identify components and assign to team members. Estimate is made on the complexity of the component and assigned a weighted value. Team also creates estimates on available time to work on components.

4) There can be multiple components assigned to a given team member. One does not want the team lead to be overloaded though.

5) Daily or close to that freq, the team reports their status and identifies any issues.

With luck, they will have matched the selected components with available time within the cycle.

A couple of issues that I have spotted:

6) The cycle time can be to tight, not allowing proper analysis of the components effort.
This creates an unreal expectation of what can be accomplished. By the time upper management sees the workload, they do not expect that there will be any adjustments.

7) The cycle time may not allow full comprehensive testing. A simple unit test may be done and the work checked in which can break the overall system during a full test.

8) One cycle in a series should be dedicated for full regression testing.

9) Pressure is created via #5 to meet schedule no matter what. This leads to mistakes being made #7

10) Slop time must be accounted for when planning the schedules. Depending on how far the project is matured; maintenance issues may pop up that will require handling. Unless there is a dedicated team in place for such; that time impacts the planned component implimentation time.

Procedures/tools being changed mid stream or between cycles will have a drastic impact of results; much more than expected.

That's a pretty good view into agile. Your #9 will happen on your first 2 sprints, maybe your 3rd. After that, everyone should be normalized to each other and have a good sense of who's good at what and how accurate estimates are. After that, it shouldn't ever happen.

Also, pressure is the last thing an agile team wants. Hell, a lot of them stress the importance of an 8 hour day to keep the team in good spirits and health.

Your #10 shouldn't happen. The SCRUM master's job is to make sure that never impacts the team.

The important aspect of agile is to keep the team in the same room. Information boards should be set up to keep track of backlogs and sprints. Communication is instant between team members and everyone is held accountable for their work, but in a positive, fun, energetic manner.

Like I said, mumbling stapler programmer guy will fail at agile.

Edit: OP, you can always become agile certified and even scrum master certified.

 

[Kirby]

scrum master sounds like it belongs in D&D

 

[heymrdj]

scrum master sounds like it belongs in D&D

"Scrum Master casts parallel array initialization on your lvl 2 programmer"

 

[Markbnj]

A [Scrum_Master00] casts Requirements Changed!
A [Scrum_Master00] hits you for 1672 damage!
You have died!