Agile

[TridenT]

I don't really get what it is. Anyone got some good resources to educate myself? I'm willing to check out the library for some books too, but I would like to get ones that are relevant.

I'm also interested in learning Ruby on Rails. So, if I can combine the two...

 

[brandonb]

Agile as in software practices? Like Scrum, UML, etc?

Agile is another way of saying there is no software practices. If programming requirements (such as UML) was a religion. Agile is the athiest equvilent. It's no different as if you were at home programming as a hobby. Your own rule apply to writing code and thats about it.

 

[sourceninja]

Agile as in software practices? Like Scrum, UML, etc?

Agile is another way of saying there is no software practices. If programming requirements (such as UML) was a religion. Agile is the athiest equvilent. It's no different as if you were at home programming as a hobby. Your own rule apply to writing code and thats about it.

That's not really true at all. Most places that use agile use it with a process like KANBAN or SCRUM. There are coding standards, reviews, etc. What is different is the design model. The goals are allowed to change with each sprint coming a review or the project and ideas being injection from stake owners and testing.

 

[beginner99]

in a very simplistic way it's the opposite of waterfall and the hallmark of waterfall is, that you first fully specify the system and then start to build it afterwards.

In agile you have more interaction with the costumer, show them some prototype application and then act on the customers feedback. The advantage here is that most customers don't really know what exactly they want and hence it's impossible to specify it up front. This is mainly for applications in business processes.

In contrast a system fro controlling a nuclear plant, you sure know what you want and what the system must be able to do up front.

 

[pauldun170]

http://java.dzone.com/articles/adopting-agile-3-%E2%80%9Ceasy%E2%80%9D-steps

http://www.versionone.com/Agile101/Agile-Development-Methodologies-Scrum-Kanban-Lean-XP/

http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

 

[Markbnj]

I like brandon's answer, even though I agree it's not strictly true. Let me be equally cynical: agile is the latest silver-bullet methodology guaranteed to allow suits to order people to start building stuff before they really know what they want.

Ask yourself this: would you build a house using an "agile" methodology?

 

[sourceninja]

I like brandon's answer, even though I agree it's not strictly true. Let me be equally cynical: agile is the latest silver-bullet methodology guaranteed to allow suits to order people to start building stuff before they really know what they want.

Ask yourself this: would you build a house using an "agile" methodology?

If I was building it virtually, yes. Physical objects and code are not the same.

 

[MrChad]

Agile has to do with project management, not specifically with software development.

In a traditional waterfall project, you spend a lot of time gathering and documenting requirements. The business requirements are translated into a functional design document, which in turn gets translated into a technical design document. Developers build the software against the technical design document, testers validate the software, then you go live.

The problem with waterfall projects is that business users don't get to see the product in action until late in the project cycle. At this point, the cost of changing the app (especially a major change) is significant.

Agile seeks to address this problem by breaking the project into smaller project cycles. I'm most familiar with Scrum, so I'll use that as my example. You divide a project into a series of "sprints" (2 weeks, 4 weeks, or 6 weeks long). You have a product backlog (a giant laundry list of high-level features that the business wants), and for each sprint the business and development teams decide what items on the backlog will be built within the sprint (based on business priority and development and testing complexity). Within the sprint, each of the "user stories" (items) on the backlog are elaborated (gathering the detailed requirements), developed and tested. The business gets to see the application 1 or 2 times within the sprint, and any changes that come up get added to the backlog to get prioritized for future sprints. You keep doing sprints until the product gets to a point where it's ready to go live.

 

[Markbnj]

If I was building it virtually, yes. Physical objects and code are not the same.

What makes them different? If I tell my crew to start building a basement from cinderblock, and then realize in one of my scrums that I need poured cement to handle the load from the piano my wife just decided to buy, and ask them to rip it out, will that be less expensive than paying a development team to redo work on a large system?

I bet it won't.

Edit: should have said "more expensive" above, but hopefully the point came through.

 

[MrChad]

What makes them different? If I tell my crew to start building a basement from cinderblock, and then realize in one of my scrums that I need poured cement to handle the load from the piano my wife just decided to buy, and ask them to rip it out, will that be less expensive than paying a development team to redo work on a large system?

I bet it won't.

I think Agile is great for maintaining an existing product (fixing bugs, adding features, etc.). I find it frustrating for building a new product, because the short-sighted nature of sprints makes it difficult to design and plan the overall system architecture, especially in the early stages of development.

 

[brandonb]

I'm just reposting since my first post.

I actually think MrChad has the best answer about Agile and why it's used.

---------------

However, in most places I've worked. Nobody really looks at the project even with Agile development. I'd like to say it's more "work as you go." Or "lets change this on the fly to meet our current needs." There is no project management. When its supposed to be an iterative approach to development.

To put it into perspective. About a year ago. We started discussing a new project to meet a business need. I was brought in on the first meeting. You had 10 hens in the house clucking to the point you couldn't make heads from tails. No central "vision" or leader. Just a bunch of people in a room trying to convince each other of what would make the best product. Of course, each time someone would speak, they'd look to you as the engineer "Can you do that?"...

The answer always being... "Yes, given the time and resources, and if we talk through it to understand it all."

After a few meetings, I'd get the big picture of what they wanted. So I'd then start saying : "This is what the product needs to do..." Then of course, then light bulbs would appear on their head and say "Woo Woo. You get an extra Woo because if you could do that, it deserves the second Woo, and hardly anybody gets 2 Woos.", and most of them would be on board, and a decision is made to proceed.

During the time, the CEO comes in and says "I don't want to discuss this project forever. It's already been a few months. They have no clue what they want. We are just going to have to make it and change it as we go. Ready set go... I was this done in 2 months as we've already wasted enough time talking about it."

2 months later. Still making revisions. The back and forth between code and ideas. Getting feedback but still no real project here because you have to redo everything multiple times.

Then 2 months later and 2 months late. You start to be harrassed by the CEO about the project taking too long and you start to grumble alot to yourself about how much this method sucks and if they just would figure out what they want ahead of time, we wouldn't be 2 months late. At this point you start demoing the project. Everybody says "That's great! But we still need to do this to make it production ready." Of course that "need" is something new brought to the table that you never heard of before.

Now nearly a year after the original meetings started taking place (and 6 months overdue) the project is finished, and nobody wants to use it because they aren't used to it, and its so different than what they are used to, now we are sitting in a testing phase (pre production) for nearly 4 months while it sits mostly idle because nobody wants to give it a stamp of approval.

And with your login audit logs the most people in the original meetings haven't even loaded the project once to form their own opinion. Those same hens from the henhouse. In other words, we aren't talking about it, they aren't using it, they are not going through this iterative process of agile. They just want to cluck.

I'm not bitter. Not at all.

 

[BrightCandle]

A lot of people misunderstand agile, the principles and practices that come with it and what it is good and what it is not good at. But principally if your users aren't using the software and you are already a month in you are definitely not agile. Actually a better to start to think about it is reducing the time from idea to implementation to in the hands of the user, they guide future priorities by what they are using day to day. The point is to determine priorities based on actual experience, to allow and expect constant change.

If after a year your users are surprised and unfamiliar with the software you just did waterfall without the upfront design and analysis which rightly worked out worse.

Its good at keeping a team on what is important, its hard to fix big technical problems without buyin on the idea and pay down of technical debt. But it can work very well so long as the team has the discipline necessary (most don't). But its clearly not always appropriate, the less you know about what you need upfront the better an agile approach will be. The more fixed the spec is the less it helps and the more it hinders.

 

[Train]

Agile is a set of principles created by a group of the most respected coders in the biz. http://www.agilemanifesto.org/

Agile by itself is not a methodology. There are several methodologies you can use. The idea is you pick what system works best for your team/project or even develop your own hybrid. Common ones are Scrum or Kanban, more specifically to coding, you can use TDD, Pairing, continuous integration, which have roots in XP, which overlaps quite a bit with agile, as it applies to software.

Agile isn't new, or a fad. The manifesto was created in 2001, and really just put a name on a lot of emmersive success growing in various parts of the software indutry. Some of the methodologies even predate software. Kanban was developed by Toyota in the 1940's to make car factories more efficient, turns out tracking production of various parts across a large factory transfers well to tracking features through various stages of design/developmnet/testing/deploying.

 

[Train]

...snip...

I'm not bitter. Not at all.

That sounds like a description of everything agile ISN'T

I think one of the major goals of agile is to avoid waste. Doing a bunch of dev on an app that doesn't get used by the target users is the absolute worst kind of waste.

You have to get the early prototypes in front of them, drag them kicking and screaming if you have to.

 

[Markbnj]

Some of the methodologies even predate software. Kanban was developed by Toyota in the 1940's to make car factories more efficient, turns out tracking production of various parts across a large factory transfers well to tracking features through various stages of design/developmnet/testing/deploying.

Right, but Toyota builds cars that have been meticulously designed, prototyped, and planned down to the last fastener's position to within a few thousandths of an inch. They came up with Kanban to control the flow of materials and resources in a just-in-time manufacturing system. That system is a production process, where a given output always results from the ordered assembly of the specified components. The writing of a software system is not a production process. It's not a reproducible recipe for the assembly of components. It's a creative process of invention, and every time we undertake it we produce something which has never existed before. The best statement of software requirements that you've ever seen falls so far short of the production plan for an automobile that they aren't even the same animal.

 

[beginner99]

I think Agile is great for maintaining an existing product (fixing bugs, adding features, etc.). I find it frustrating for building a new product, because the short-sighted nature of sprints makes it difficult to design and plan the overall system architecture, especially in the early stages of development.

This sounds reasonable. As always the best is probably a sane mixture of both. IMHO before you write any code you need to get a general idea what the customer wants and understand the Process and the "basic discipline" behind it. With "basic discipline" I mean if you do something for a bank, you should know "basics" about banking and if you do something in biology research you should probably know what a gene is.

I'm just reposting since my first post.
---------------
I'm not bitter. Not at all.

Sounds like a project going on here for almost 3 years. luckily I'm not involved. I was at the very beginning but then my boss (probably wisely) decided to stay away form it. Anyway I made a simple "prototype" to show how the domain model should be. As a matter of fact I have basic understanding of the "subject" of the Project. Anyway took me about 2 days (using grails). I think they "bitched" around how the model even 1 years later. A lot was just political BS...I'm pretty sure my boss, me + a competent developer could have completed the project in 1 year at less than 1/3 the cost and it would be better than whats around now. Created from outsourced people in the east.

 

[Train]

Right, but Toyota builds cars that have been meticulously designed, prototyped, and planned down to the last fastener's position to within a few thousandths of an inch. They came up with Kanban to control the flow of materials and resources in a just-in-time manufacturing system. That system is a production process, where a given output always results from the ordered assembly of the specified components. The writing of a software system is not a production process. It's not a reproducible recipe for the assembly of components. It's a creative process of invention, and every time we undertake it we produce something which has never existed before. The best statement of software requirements that you've ever seen falls so far short of the production plan for an automobile that they aren't even the same animal.

Who says they weren't planned?

And I disagree that automobiles are more planned than software, have you ever seen an ADA system?

Cars have the added benifit of only being slightly changed from year to year, they aren't total rewrites. The difference between the 2013 Ford Taurus and the 2012 Ford Taurus is about as complex as the code for a single Patch Tuesday for windows.

 

[Saint Nick]

We use Agile methodology at my work...and needless to say it works for us. I sort of describe it as "develop develop develop show customer develop develop develop show customer develop develop develop acceptance maintenance" Lol.

 

[Markbnj]

And I disagree that automobiles are more planned than software, have you ever seen an ADA system?

I've never worked with Ada, but I agree that milspec system development is the most meticulously planned. But I disagree that the level of specificity reaches that of a blueprint for hardware construction. We can't get to that level of detail in software without actually writing the code.

 

[Train]

We can't get to that level of detail in software without actually writing the code.

All the more reason to throw "big design up front" out the window in favor of rapid prototyping.

 

[Train]

Speaking of Automobiles, I live in the Detroit area and all the Big 3 are HUGE on agile right now.

GM is converting nearly every department to agile. Ford is following suit. Extreme programming was basically invented at Chrysler in the 90's

And of course all the suppliers want to do what the big boys are doing. Several agile consulting/coaching firms are making a mint in the area right now.

 

[sourceninja]

What makes them different? If I tell my crew to start building a basement from cinderblock, and then realize in one of my scrums that I need poured cement to handle the load from the piano my wife just decided to buy, and ask them to rip it out, will that be less expensive than paying a development team to redo work on a large system?

I bet it won't.

Edit: should have said "more expensive" above, but hopefully the point came through.

There are time costs and material costs.

Construction is both time and materials. Development is time. Development can be fluid. In your example destruction takes time and materials as does construction. In software development we refactor, destruction is instant and construction is just time. But what happens after that. Two days later your wife wants that piano back, you are out time and materials of both construction and destruction. Developers just revert changes to a previous commit and merge that into the mainline. If you have good devs, this is minimal.

This is why you can't compare physical and virtual work. They are not even close to the same. Developer costs can be controlled (salaried instead of hourly, etc) material costs cannot, each revision means new material costs + the time costs. Next we will be trying to make car analogies about software piracy.

 

[Markbnj]

All the more reason to throw "big design up front" out the window in favor of rapid prototyping.

Which is fine, because nobody outside of the largest government projects even attempts to do "big design up front" for software, and they do it poorly. We're incapable of designing the construction of a software system up front because the parts we have to work with are too small and malleable. For any given statement of requirements there are an infinity of solutions, and any two developers are likely to come up with two completely different solutions that will nonetheless fulfill the requirements.

What we need for successful software projects is not "big design" but rather "complete requirements." The purchaser of our talents has to be willing to think through the behavior they want, and the applicable business rules, before we start building. I have problems with agile to the extent that it encourages business to just get started without thinking things through, on the premise that software is somehow magically amenable to change in two week increments. It's not.

 

[Markbnj]

This is why you can't compare physical and virtual work. They are not even close to the same. Developer costs can be controlled (salaried instead of hourly, etc) material costs cannot, each revision means new material costs + the time costs. Next we will be trying to make car analogies about software piracy.

The only thing that matters to someone who is paying to assemble any complex structure is time and money. It doesn't much matter whether the money is split between relatively cheap talent and relatively cheap materials, vs. expensive talent and no materials. The average large software system is harder to build, more expensive to build, less open to change, and more expensive to change, than my house. That's all I'm saying. We treat software as if it is some ball of playdoh that we can just keep massaging endlessly because it's just bits on a disk. That's false.

 

[Train]

Which is fine, because nobody outside of the largest government projects even attempts to do "big design up front" for software, and they do it poorly. We're incapable of designing the construction of a software system up front because the parts we have to work with are too small and malleable. For any given statement of requirements there are an infinity of solutions, and any two developers are likely to come up with two completely different solutions that will nonetheless fulfill the requirements.

What we need for successful software projects is not "big design" but rather "complete requirements." The purchaser of our talents has to be willing to think through the behavior they want, and the applicable business rules, before we start building. I have problems with agile to the extent that it encourages business to just get started without thinking things through, on the premise that software is somehow magically amenable to change in two week increments. It's not.

It sounds like you are advocating Agile, and you just don't know it.