selling points of Agile practices

Question

My company is using waterfall methodologies for software development. I want to convince the senior management about the advantages of agile practices. Which would be the most selling points about the benefits of agile development methodologies and practices?

Answer 1

already posted

http://stackoverflow.com/questions/52997/you-have-to-sell-agile-to-management

Answer 2

Some agile practices are easy to adopt right away. You won't get the full benefit, but they're still worth it. Like 1-step build, nightly build, Test-Drive Development, and Refactoring.

Depending on your position in the organization, you could accept change requests with grace, instead of with resistance. That always goes over well, and is a good sign that your agility is improving.

This is by no means a complete answer.

Answer 3

When it comes to convincing management it comes down to numbers. I'm not sure where your revenue model is and agile is a broad term that includes recognized best practices learnt over the past 20 years.

I find Test Driven Development reduces the amount of defects in shipped code. The cost of a defect is far more expensive to the company once the code has gone live.

A continuous integration server is huge for saving time once its set up.

Using the Scrum style of project management gears you towards the release early and release often mindset which means you are actually producing production ready code early on in the life-cycle. Early results are good yes?

In my experience you end up with a more satisfied customer as they are part of the process and you can respond to their feedback earlier and with less re-work than you would with more traditional waterfall methodologies. But now we're starting to get into the more subjective reasons of why to go agile - of which there are many but which hold little weight with "The Man"

I recomend you adopt agile practices within the development team stealthily so that you can then go to management after a successful release or two under your belt. That way they would have already experienced the benefits.

Better to ask for forgiveness than permission.

Answer 4

The end of the first iteration (usually somewhere between one and four weeks) results in a little bit of software that actually works. This has the staggering advantage that the customer/sponsor can take that little bit of usable software… and use it! Even if the client waits for a few iterations before the software has enough functionality, and only then uses it, the advantage is still huge. In any process where all the requirements are gathered up front, regardless of how or what is done with them afterwards, there is a large delay in getting the first bit of usable working software in the client’s hands. This delay costs. It costs both money and opportunity. Regardless of how stable or unstable the requirements are, agile methods deliver a return on investment much much sooner than any other approach to building software. Customers know what they want - higher profits, greater market share, etc.For both of these desires, the best way to get them is by the reduced cycle time that using an agile method provides.

Agile uses simple best practices

Daily kickoff and review of goals

short release cycles

Responsive Development

Generalism - Use of generic skill sets that are common across the team, not reliance on specific skill sets that are scarce

Hope this helps...

Answer 5

There will probably be many specific answers to your question, but I'd say that many of them will have one thing in common: agile practices provide feedback sooner, which allows you - provided you're paying attention, which is harder than it sounds - to more rapidly and effectively adjust what you're doing to your current situation.

Think of requirements. In agile processes, the customer sees a demo of the working product and/or receives production-ready code at the end of each iteration (i.e. every few weeks). In fact, the customer was probably sitting beside you as you built the code. At the end of the iteration milestone, the team is about to plan the work for the next milestone. They can incorporate the feedback from customer in that planning. Think about it. Every few weeks you get to plan and prioritize using feedback from the customer about real, working code, as well as the team's deeper understanding of the problem since they've actually built and delivered real features. Contrast this with trying to plan months of work using some requirements tome that is likely ambiguous, incomplete and inaccuate.

The practices that most agile practitioners follow are usually a subset or variation of those laid out by Extreme Programming. Those practices are designed to support each other. Unit tests enable shared code ownership: if I'm working on code written by somebody else, the tests illustrate how it is supposed to work and will tell me if I break something. Continuous integration validates and communicates the 'health' of the code base to the team. User stories and acceptance tests bridge the knowledge and expectations of the customer to what the team understands and builds. Again, each of the practices provides feedback in some form to somebody or group of people on the team.

Large software projects deal with significant unknowns. The application itself is new. Perhaps the market its aimed at is new as well. The business environment is ever-changing. Who knows what the market and competitors will be doing differently by the time the product finally ships. And we're forever trying to apply new technology, either to one-up the competition or gain a productivity boost.

Agile development is about working in the tiniest steps, and then aggregating the progress. And at every step in the process you stop, however briefly, evaluate where your are and where you need to go next. The flexibility this gives virtually unheard of in traditional, waterfall-style approaches.

Answer 6

This answer may be tangential, but then again, it might be useful. I'm assuming when you say agile you mean (big-A) Agile, which is basically a blob of practices packaged together for marketing purposes. I come from the context-based school of thought which states that there are no best practices, only good practices dependent on context. I strongly urge you to watch this video here, which features testing expert James Bach. At worst, you'll merely be entertained. But you will learn some good stuff.