What makes Agile software development so appealing?

Question

Agile software development is becoming a pretty fun buzzword these days.

As a developer, I understand the pragmatic value of iterative development, but (most often) it isn't a developers choice to embrace an Agile approach to software development. It's a top-down management choice! Whether it is crystal, agile methods, dsdm, rup, xp, scrum, fdd, tdd, you name it. It's not a developer choice.

For all the managers out there, what are the biggest reasons for choosing to do Agile development when (in my experience) most managers haven't even touched a piece of code in their life!

Answer 1

Shifting requirements, faster delivery

Agile is appealing because it gives the possibility of adapting to changing needs more quickly (or at all), and delivering those changes to the customer more quickly.

This is why many companies fail when using Agile/Scrum: Managers don't understand that with great power (of setting quicker release dates and changing requirements often) comes the responsibility of relying on developers for estimates. For agile to work, the manager has to be willing to then cut scope.

They want the power of both.

Answer 2

Following trends

Sometimes people do things, not because of the merit of the thing they're embarking on (agile), but merely because it is popular and other people are attempting to do the same.

"What? Macrojam is doing Agile? Why aren't we? We're not slow, we're Agile, dammit!"

Some people don't give a good goddamn what being agile actually entails. It's merely a means to justify their existence. Sheeple, peer pressure, etc.

Answer 3

Coding itself is not the major reason managers can be convinced to select agile as a method. The fact you can react quicker to changing requirements and priorities is appealing. The 'manager' in the end needs to deliver a solution to the end user/customer/his manager.

If functionality that seemed key when starting the project can be abolished midproject and replaced by new, more relevant requirements, that is a major advantage.

Also important is that mostly (e.g. like in scrum) each intermediate delivery should be nearly ready to be put into production. At the same time, the most urgent functions were developed first. So, in case the project is canceled because of some corporate decision, management is sure you will end up with something that will work and can be put in production.

Hope this helps.

Answer 4

Increase visibility on what's is going on, and increase productivity

1. Managers are usually interested by visibility agile brings, especially with scrum. It's one of the most used selling point in the seminars that targets managers.

2. Higher productivity is also commonly used to attract them as it is easy to demonstrate (thanks to visibility). Some agile evangelists promise them outstanding productivity from their existing employees. "What? I'm already pressing them like lemons and you tell me I can get even more"?

Many managers use agile to crush their employee a little bit more and I've seen them using the burn down chart as a slacker hunting machine in one large company.

Result? Many team in distress. They thought agile would solve all their problems, but it did the exact opposite. The problem was elsewhere.

I'm actively fighting against that. That's why sometimes where there is an high probability than agile methodology will be perverted by management, I suggest to not mention it within the company.

Answer 5

The answer to that question could fill a book.

I think one of the main reasons is that agile development focuses on the deliverable. It always focuses on delivering exactly what is most urgent here and now.

Another reason is that the story based planning and estimation practices that agile processes follow gives a far better estimate of what can be delivered and when.

A good example of how effective story based planning is, is a project I worked at. For a couple of months (before we adopted agile development), the project leader believed that we could deliver on time, and that was about 18 months from deadline. All developers had a feeling that that was probably unrealistic. After starting agile planning, the project leader still had an optimistic appraisal of the situation. But only after a few sprints, the project leader realized that the team simply didn't have the capacity to deliver all the requirements on the expected time. And that was now still more than 12 months from the deadline.

So agile practices also make reality clear a lot sooner.

And finally, agile teams tend to more often adopt practices that create better code quality, e.g. test driven development, frequent refactoring, continuous integration, peer code review/pair programming, etc. Not that traditional software projects prohibit these practices, they just tend to not be that much in focus.

Answer 6

most managers haven't even touched a piece of code in their life!

I was a developer for 12 years and now a manager for 5. During the 5 years I transitioned gradually from a manager that still coded to being primarily a pure manager (I still occasionally fix bugs or do prototyping exercises).

what are the biggest reasons for choosing to do Agile development

• Visibility or Succeed fast / Fail fast - We are a product development shop with 6 month to 24 month cycles. Iterative development with working, tested features did a better job of reflecting project status.
• Change - In our environment, requirements and time tend to be fixed. But, the business on a too regular basis goes through rapid, jarring changes in direction. Iterative, visible development made it easier for the projects to change direction.
• Story based requirements with iterative development made it easier to work with the business that didn't always understand the technical aspects of the requirements or fully understand the business drivers of some of the details. In our past efforts, high level specifications or marketing requirement documents were not always sufficient. Now, as projects evolve, there can be some parallel market and customer research.
• The process change came with a lot of other development attributes like TDD, automated versus manual testing, tighter testing cycles (We no longer have a QC group, just a QA group), and a higher appreciation and effort related to quality (we use a lot more tools and metrics).

We could have achieved this in other ways, but leveraging agile methodologies and ideas has helped us immensely.

We also continue to refine our process. For example, the balance between up front design work versus design just ahead of implementation. We review all of our decisions regularly to determine if we could have deferred past design decisions. And, when things go wrong, how much more up front work would have been necessary until the error would have been identified. Often, failures are corner cases that require deep analysis. The effort to get that detailed is often the same as the cost of figuring it out along the way and refactoring. Teams are not penalized for these types of errors and encouraged to be more aggressive.

Answer 7

I've seen a number of companies "doing" agile. Unfortunately, very few of them adopt agile. What I mean is just doing iterative development and daily standups (where most of the team sits down) does not make the team Agile. TDD, Refactoring, Continuous Integration, Customer Presence, SOLID practices makes a team Agile. Without those, you're just going around in circles.

There is a lot of appeal that the message of Agile brings. Adaptability to change being the biggest. Unfortunately, your code does not become more adaptable just because you change how you manage the project. Until more companies realize this, we'll just hear about more and more failed agile project.

Answer 8

I don't know about the buzz word part. I've really been doing this all along in a not so formalized or identified process. I've had clients literally look over my shoulder as I built their website. Saved about 50 emails and the client learned something about this process - it ain't easy.

The whole notion that we will take a long period of time to write down everything the user wants the software to do, then take a longer period of time to build what we think they want only to discover within 2 seconds of trying the app that this isn't what they expected is nauseating. How hard is it to break up any project or application into some reasonable pieces to build and get some feedback before you build another piece?

I know this is an over-simplification and doesn't address the actual developer practices, but it's not hard to sell to even the most non-technical manager or customer. What other approach is more appealing? Do clients really love the fact that the programmers are out of their hair for 6-12 months while they develop during some waterfall project? Would you hire someone to build a house this way?

Answer 9

Management doesn't push these things upon developers. Developers, and teams should take initiative and strive towards them to do their job better. Management's job is to provide support for these initiatives.

Answer 10

As a manager who has written a fair deal of code in my career I may not be who you are looking for to answer this. In any event, I think the draw to Agile these days has most to do with responding to customer needs more quickly as well as shortening the feedback loop between specification, coding, testing and customer. We are making a move toward more Agile development for these very reasons.

Answer 11

I think you should not mess the Agile process and coding/development practices. For example, Scrum does not tell you how you should develop your code - it's all about the process that welcomes changes.

Answer 12

At the end of the day, it's about empowering the developer; it's about acknowledging the fact that those guys that are at the very bottom of the hierarchy are the only ones who truly understand the extent of what needs to be done and how to do it, so if you already hired them for their expertise--why not let them take full control or rather, why distance them from the actual decision making?