Agile - buzzword, benefits and business buy-in

I have been involved in web development for around 5 years now but it is really only in the last 12 months that I have come on board agile projects. Many companies are now adopting the framework and is often seen as the savior in combining IT, business and vendors all holding hands to deliver a superior product.

But does agile make development a dream or a disaster?

Benefits of agile:

• Communication. When daily stand-ups, showcases and retrospective meetings are all utilised, the value of having the project team be aware of all issues, risks, blockers etc. is fantastic. Never before has a few simple concepts allowed business stakeholders such as myself to have such high visibility to what developers and business analysts are tackling on a daily basis.
• Flexibility. This can be either effective or a nightmare for agile development, depending how it is managed. In terms of business requirements and more so for user interface design, you don't need all the answers up front. With web and UI design evolving so rapidly, front ends can be designed iteratively to make use of trends and best practice. It also allows usability testing since working UAT versions of your project are usually available.

Disadvantages of agile:

• Business participation. This is the killer.. If you don't have your business reps on board  and being on tap to answer questions and sign off functionality, your project will struggle. Since agile works on development, test, development, test - having stories linger around simply slows down velocity and above all frustrates the developers and testers. Fair enough they might not be able to give you all of their time if your project isn't their sole focus (I have been guilty of getting slammed on other work and not following up questions that delay testing) but explaining to them the benefits of daily communication is key - which i'll get too.
• Stakeholders not in agile mode. Whilst there may be times that stakeholders such as external vendors don't have to operate in an agile form, from my experience, its best to get them on board. There have been instances where vendors have dumped deliverables into your inbox which are completely out of whack to what you need because a) due to the benefit of agile, your design/build may have shifted direction or b) since they don't get the daily update or are proactively involved in the project, they become detached. Vendors should make an effort to be available and flexible too. After all, your paying them more often or not.
• Expectations of go live. While there's flexibility in designing & building under agile, it can be a challenge to get firm go live dates. Whilst some may not mind, those pesky managers expect hard-line dates as above all - your website or application needs to sell, acquire, retain, convert and numerous other functions that lead to one thing: $$$

Working in a business environment with an IT background has allowed myself to get an interesting perspective on IT development.Whilst you love to build websites and apps that are beautifically designed, intuitive and have had extensive usability testing.. the reality is, most people in the business world don't have the same passion or honestly don't care about these things.

Your completed product is simply technology that allows your employer to make money.

What IT colleagues forget is that product/marketing managers - usually the customers of the web app being built have profit and loss driven targets in their jobs. They aren't reviewed on how many well built IT systems are made for them....they are reviewed on how much cash they bring in.

Tips on how to get better business buy-in for agile development:

• Focus on the tangible benefits of agile. You are asking for a lot of time from a business rep so explain that their involvement will give them a much higher quality web app. Look for case studies out there from well known companies on how agile worked for them. 
• Explain how they can user test easily. Whilst promoting usability and user centered design to business reps is a topic in itself, explain how you will get access to a working prototype from start to finish which you can then take around to colleagues, friends etc. to test. By identifying errors/issues early on, they can be tackled swiftly to deliver a usable product.
• If they come for the ride - they get flexibility and of course less documentation. Moving away from massive requirements documents into storycards may interest business reps and by using other agile elements like personas, it allows them to understand who and how their customers will interact with what is being built.