Why Agile?

  • (2 Pages)
  • +
  • 1
  • 2

16 Replies - 2011 Views - Last Post: 18 February 2015 - 03:41 PM

#1 NecroWinter   User is offline

  • D.I.C Regular

Reputation: 38
  • View blog
  • Posts: 347
  • Joined: 21-October 11

Why Agile?

Posted 14 February 2015 - 09:26 AM

Im not sure why my company has decided to go with Agile development. Im pretty suspicious of corporate types, but it seems like the reason comes down to one of two reasons

1. Agile by name only sounds like its better to the suits who dont really know anything.
2. It allows programmers to do the thing they were warned about in college, that being writing a program before you actually know what you need to do, which leads to awful, awful code.

I'm open to the idea that my company isnt doing agile correctly, and that agile isnt bad. But from what I've seen its been kind of a disaster for everyone involved. But then again my company being disorganized and stuff isnt exactly new.

Can someone enlighten me? I see agile as a buzzword in a lot of job postings, I hope its not as bad as what Ive seen because it seems fairly common.

Is This A Good Question/Topic? 0
  • +

Replies To: Why Agile?

#2 tlhIn`toq   User is offline

  • Xamarin Cert. Dev.
  • member icon

Reputation: 6535
  • View blog
  • Posts: 14,450
  • Joined: 02-June 10

Re: Why Agile?

Posted 14 February 2015 - 09:33 AM

Let's start with what your understanding of agile development means. Its hard to 'enlighten' without knowing what your perspective is.

How do you think it works, what do you think it means, how would you describe the new proposed work flow for your development team?
Was This Post Helpful? 0
  • +
  • -

#3 Atli   User is offline

  • Enhance Your Calm
  • member icon

Reputation: 4241
  • View blog
  • Posts: 7,216
  • Joined: 08-June 10

Re: Why Agile?

Posted 14 February 2015 - 09:37 AM

There is a reason why Agile is so popular these days. When used correctly, it does work very well.

Of course, if you use it incorrectly, it'll fail... like everything else will.

Quote

2. It allows programmers to do the thing they were warned about in college, that being writing a program before you actually know what you need to do, which leads to awful, awful code.

If that's what's happening in your company, then you're doing it wrong. I'd suggest sending the leaders of your project/teams to a seminar or two on how to do it correctly.
Was This Post Helpful? 1
  • +
  • -

#4 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 2942
  • View blog
  • Posts: 11,425
  • Joined: 03-December 12

Re: Why Agile?

Posted 14 February 2015 - 09:44 AM

It may be a buzzword for your company, but it sounds like you don't understand it either. Agile is preferable to most over waterfall. It acknowledges and allows for changes and gives deliverables at known intervals. I don't know what industry you are in, but change in requirements is a big issue in most. That is where agile is most intuitive.
Was This Post Helpful? 0
  • +
  • -

#5 NecroWinter   User is offline

  • D.I.C Regular

Reputation: 38
  • View blog
  • Posts: 347
  • Joined: 21-October 11

Re: Why Agile?

Posted 14 February 2015 - 09:52 AM

the thing about my company is that we get sent to so many seminars, and have so many meetings that it all kind of gets lost. The company is constantly biting off more than it can chew.

In my experience, Agile mostly means theres sprints (in my case, 2 week sprints) where in the first week we do mostly design, then in the second week we do development. Basically calling shenanigans on the original design document, and allowing the developer to update it. Qa can also come in and tell us to make a change, and the problem is that it can really fly in the face of the code base thats already there, this results in the entire team constantly scrambling to get things to match whatever the requirements are that day and when you have to maintain the code its genuinely bad code that was written to get in done before the end of the week, not to be of decent quality.

View Postastonecipher, on 14 February 2015 - 09:44 AM, said:

It may be a buzzword for your company, but it sounds like you don't understand it either. Agile is preferable to most over waterfall. It acknowledges and allows for changes and gives deliverables at known intervals. I don't know what industry you are in, but change in requirements is a big issue in most. That is where agile is most intuitive.


Of course I dont understand it, why else would I make a post like this? Im trying to see if its Agile thats the problem or the way my company is doing it.

EDIT:

When I say calling shenanigans on the original design document, I only mean that in the case where a design document is done. Which doesnt always happen.

This post has been edited by NecroWinter: 14 February 2015 - 09:57 AM

Was This Post Helpful? 0
  • +
  • -

#6 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11651
  • View blog
  • Posts: 19,801
  • Joined: 19-March 11

Re: Why Agile?

Posted 14 February 2015 - 09:58 AM

"Agile" is mostly a brand name for a particular collection of practices that smart developers have been using in various combinations since programmers started working in teams. Yes, it's usually a buzzword - you can't just take a "team" (another buzzword) and pour some Agile sauce on it and expect it to work. But if you understand the ideas gathered up under the heading of "Agile development" you'll find that they make sense - or at least, that there's some way that you can put those ideas together to make sense for you. And if you start doing this you'll find that it generally makes for a better, smoother flow of development.

Since it sounds like this "agile" move is happening at your workplace, whether you like it or not, you get to choose who you want to be - do you want to be the one who's sitting in the corner mumbling about how this sucks, and it'll never work, and I don't know why we're doing this whole meeting every morning thing anyway what a waste of time, or do you want to take some initiative and learn what Agile actually is and figure out how to make this work best for your group?
Was This Post Helpful? 0
  • +
  • -

#7 astonecipher   User is offline

  • Senior Systems Engineer
  • member icon

Reputation: 2942
  • View blog
  • Posts: 11,425
  • Joined: 03-December 12

Re: Why Agile?

Posted 14 February 2015 - 09:59 AM

2 weeks is a small sprint. The other issue I see is, QA should not be dictating requirements, only testing that the code does meet them.


A change in requirement should not mean a complete overhaul of code base either.

You might want to grab a book on software development the agile way and see if you may steer them back on track, or at least so you can educate you and your team on proper strategies.
Was This Post Helpful? 0
  • +
  • -

#8 NecroWinter   User is offline

  • D.I.C Regular

Reputation: 38
  • View blog
  • Posts: 347
  • Joined: 21-October 11

Re: Why Agile?

Posted 14 February 2015 - 10:03 AM

The thing is, if agile works and isnt about disorganization then Im not convinced the leaders on my team understand it well enough to do what they need to do to make it work from their perspective.


if agile is something different than what Im being told to do, then I feel like I would need to do everything my own way, which on a development team would be bad without agreement.

Im torn, and thats why I came here. Im trying to figure out if agile is really what im experiencing or if they simply dont get it.
Was This Post Helpful? 0
  • +
  • -

#9 NecroWinter   User is offline

  • D.I.C Regular

Reputation: 38
  • View blog
  • Posts: 347
  • Joined: 21-October 11

Re: Why Agile?

Posted 14 February 2015 - 10:08 AM

View Postastonecipher, on 14 February 2015 - 09:59 AM, said:

2 weeks is a small sprint. The other issue I see is, QA should not be dictating requirements, only testing that the code does meet them.


A change in requirement should not mean a complete overhaul of code base either.

You might want to grab a book on software development the agile way and see if you may steer them back on track, or at least so you can educate you and your team on proper strategies.



I think the only reason QA is dictating requirements is because we're going through a phase where we're replacing a big chunk of some older code, and theyre throwing in some stuff that is either neglected in the original design discussion/document or is something that people wanted added in the first place.

the most common form of miscommunication is finding out that our interface agreement should handle something like an array of items instead of just one, but we often find that out a day or two before its completed. I dont know if this is related to agile though, as every team ive talked to is always scrambling to get things done.
Was This Post Helpful? 0
  • +
  • -

#10 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11651
  • View blog
  • Posts: 19,801
  • Joined: 19-March 11

Re: Why Agile?

Posted 14 February 2015 - 10:17 AM

View PostNecroWinter, on 14 February 2015 - 11:52 AM, said:

the thing about my company is that we get sent to so many seminars, and have so many meetings that it all kind of gets lost. The company is constantly biting off more than it can chew.


Agile can help you with this. Agile estimating techniques are good ways of making well-founded estimates of what you can get done, and when, and of letting the customer choose from reasonable options.

Quote

In my experience, Agile mostly means theres sprints (in my case, 2 week sprints) where in the first week we do mostly design, then in the second week we do development.


Erm, that doesn't sound like a very Agile approach to me.

Quote

Basically calling shenanigans on the original design document, and allowing the developer to update it


This sounds like you've got a sort of adversarial relationship with the customer. That's probably not helping much. Maybe it would be better if you had a chance to review the design and ask questions about it before you get it dumped on your desk? This ought to be part of an agile development cycle. "I have a question about that story where the customer frobnicates some set of widgets... what happens if the boojum is a snark? Won't that cause a problem?" "Oh, you're right, yeah, let's move the tri-lateral phasers to the other snood" "Hm, yeah I think that'll fix it" "Great, you just saved us two weeks of development cycle, thanks!"


Quote

Qa can also come in and tell us to make a change, and the problem is that it can really fly in the face of the code base thats already there, this results in the entire team constantly scrambling to get things to match whatever the requirements are that day and when you have to maintain the code its genuinely bad code that was written to get in done before the end of the week, not to be of decent quality.


QA is ordering design changes? Definitely something's wrong there. In most cases, QA exists to enforce the existing design, not to change it. This sounds like someone's doing it wrong. Of course, it's possible that QA might notice something about the design that isn't good, but that means they should feed that back to whoever has final ownership of the product. If Joe QA Guy doesn't like a particular part of the design, that might be useful feedback, or it might be that Joe goes through a certain set of steps dozens of times in testing, but the average user is going to take those steps once in their life, and this is not important. That's for the product owner to decide, not Joe and not you.


Quote

Of course I dont understand it, why else would I make a post like this? Im trying to see if its Agile thats the problem or the way my company is doing it.


So far, I think your company is doing it wrong. I've seen this before. I worked at a company that had "standups" that were scheduled to take an hour and always ran over by at least half an hour, because they turned into design meetings. That's a good example of "doing it wrong". That's not Agile's fault, though.
Was This Post Helpful? 0
  • +
  • -

#11 djjeavons   User is offline

  • D.I.C Regular
  • member icon

Reputation: 114
  • View blog
  • Posts: 417
  • Joined: 09-January 09

Re: Why Agile?

Posted 14 February 2015 - 10:23 AM

I'm a big proponent of agile so I'm gonna add my 2c worth.

First off. If your company has followed a standard waterfall approach to development then agile will feel very very foreign to you and will cause suspicion. Agile is both an approach to development and an organisational culture shift.

Let's take the organisation out of the picture for a moment and just concentrate on the dev team.

An Agile dev team is cross functional, this means that it is capable of delivering what it has committed to within a sprint (more on this in a moment). In order for that team to meet this commitment, they need both the skill and the motivation. The skill comes from the manager hiring the right people for the job at both skill level and team fit (think web dev and you need UX, Graphics design, front end, middle and backs end devs with some QA). Then you have to allow that team to meet their commitment, this means making them empowered to do do whatever is necessary. Whether that is changing their working environment (teams moving desks, collaborating more or less whatever) or committing to less if they feel the task are complex.

This generally doesn't resonate well with the organisation unless they have been trained as well hence the organisational shift. Managers, sales teams, marketing, the whole shebang really need to understand Agule for it to work within a business. This is the hardest piece.

If your company is really serious about Agile and invest in both training, time and cultural change then you will love it and your business will no doubt benefit. If Agile is just focused on the dev team and nothing else you will fail.

In terms of commitment to a sprint. You have a backlog of stories that need to be developed, these may well be documented requirements or loose wishes but at some point there will be a priority session and an estimation session. These sessions usually end up with either an estimate in effort or an agreement that more thought is required. It is the responsibility of the Product Owner with advice fro the delivery team on the priority and the dev team is responsible for estimating the effort using techniques such as planning poker. All of this brings the delivery team into line with the business strategy and generally steers a product in line to what a customer actually wants.

This post has been edited by djjeavons: 14 February 2015 - 10:30 AM

Was This Post Helpful? 0
  • +
  • -

#12 NecroWinter   User is offline

  • D.I.C Regular

Reputation: 38
  • View blog
  • Posts: 347
  • Joined: 21-October 11

Re: Why Agile?

Posted 14 February 2015 - 10:27 AM

Yeah thats what I was trying to figure out whether or not my company is doing agile correctly or not.

I need to emphasize this isnt about me, there are hundreds of teams in my company, and every team ive interacted with has the same issues. Every person has mentioned similar issues as I have here, its just theyre less annoyed with it or theyre just used to it.
Was This Post Helpful? 0
  • +
  • -

#13 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11651
  • View blog
  • Posts: 19,801
  • Joined: 19-March 11

Re: Why Agile?

Posted 14 February 2015 - 10:51 AM

BTW, "waterfall" is also a buzzword - it's just a generic pejorative that Agile uses to mean "other than agile". The actual "waterfall" design cycle - gather requirements, write specifications, etc - is pretty archaic, but most of what it does maps neatly on to any agile process. The main difference is that "waterfall" expects the design to be right from the start, and that everyone should follow the plan. It's a command-and-control approach, based on centralized power and deployment of specialized units operating in an environment where communication between units is difficult, expensive, or time-consuming. (not surprising that this comes out of the cold war period, really, particularly considering the importance of the military in early US computing)

I think it's very unlikely that any software development done today is using an actual waterfall model. What they're using is technically called "a complete failure to think about what they're doing".
Was This Post Helpful? 0
  • +
  • -

#14 djjeavons   User is offline

  • D.I.C Regular
  • member icon

Reputation: 114
  • View blog
  • Posts: 417
  • Joined: 09-January 09

Re: Why Agile?

Posted 14 February 2015 - 11:09 AM

View Postjon.kiparsky, on 14 February 2015 - 10:51 AM, said:

I think it's very unlikely that any software development done today is using an actual waterfall model. What they're using is technically called "a complete failure to think about what they're doing".

I don't mean any disrespect (seen many posts in here turn to arguments) but I don't necessarily agree with this on the basis that Waterfall does have it place, think airlines, medical or other safety critical systems. These need a proper documented and well thought out approach and in the main they get these right. Waterfall does have its place. Could you imagine an agile approach to an air traffic control system? Learn by your mistakes or customer feedback, well their dead....

You are right that waterfall can map on to agile but the Main difference is that waterfall is all about requirements, then dev, then test, then fix, then test (continue) then release. The point of agile and specifically scrum is that you do this cycle within two/four week sprints. When you get to a certain sprint of a greenfield project (let's say sprint 10) then you can release it and every sprint after that should deliver a useable, well tested, customer sought feature.

Also, the team is looks after. After each sprint you have a retrospective, what worked, what didn't, what should we do. Those go onto the backlog and are incorporated into the next sprint to help the team continuously improve.
Was This Post Helpful? 0
  • +
  • -

#15 jon.kiparsky   User is offline

  • Beginner
  • member icon


Reputation: 11651
  • View blog
  • Posts: 19,801
  • Joined: 19-March 11

Re: Why Agile?

Posted 14 February 2015 - 11:41 AM

Hm. I suppose that's an empirical question. And yeah, those are the the sorts of projects where you might expect to find a waterfall model in play. As I say, waterfall's main point is that it strives to reduce the costs of communication, by going to a central command-and-control model, and on a project like that you'd have more in the way of communication costs to manage. But I'm not sure that's enough to overwhelm the advantages of a fast-feedback cycle.

I guess the thing is, not everything is a website, but even things that aren't web sites can benefit from a more fluid development process. For example, imagine you're working on software controlling the brakes for a new model of car, and you have some specs that are based on a particular material being used for the physical brakes. One day, the "customer" (who is, as always, an internal representative, not an actual purchaser of a car) finds out that there's a new material to make the brakes from, with different characteristics. In an agile model, you could imagine a civilized and effective process for determining what it would cost in terms of development time and features foregone to change to the new material. Under classical waterfall, you're going back to square one.
So you don't need to be pushing your software changes to the end user at the end of each sprint to get benefits from using Agile methods.
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2