By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

s?

I can’t think of any ideal situations that call for Agile plus some other methodology, but there are plenty of non-ideal situations that demand creative approaches. Some domains still impose a requirement for Big Design Up Front, or at least big requirements documents up front. For example, many government contracts start with a huge requirements document and impose regimented delivery schedules that are more appropriate for a Waterfall approach. Teams working within these constraints can still be creative. They can ‘release’ code frequently to a test environment and ask customers to try it out and give them feedback. This process results in a much better product by the time the official delivery date rolls around.

Some development organizations want the benefits of Agile development, but can’t convince the product side of the business to go along with an Agile transition. They still have to work with huge requirements documents. Development teams must slice-and-dice these into small increments themselves, and find out the business priorities. They can ask the business, “What would you like to see in the first demo, in one month?” They can work with product management to get a roadmap of important features.

I’ve applied Agile principles and adopted Agile practices on a test team within a non-Agile organization. We paired on testing and test automation, and used retrospectives to find ways to improve our process. We asked the development managers to identify pain points, and tried experiments to address those. For example, dev managers complained that either the requirements took too long to produce, leaving no time to code, or they were nonexistent, forcing the developers to have to just make them up as they went along. We asked them to try using customer-facing acceptance tests to guide development. We turned business examples into tests in lieu of a traditional requirements document. Developers found these easy to work with, and it allowed us to deliver the correct functionality for the business.

Don’t worry about what you call your methodology or development practices. Get people in different positions, with different skill sets, involved in finding ways to improve software quality. It takes time to build up good teams, but the investment will pay off handsomely over the long term.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy