Problem solve Get help with specific problems with your technologies, process and projects.

Applying Agile principles on non-Agile teams

Expert Lisa Crispin describes how teams can apply Agile principles to reach development goals, whether using an Agile, mixed methodology or Waterfall approach.

Are there situations where combining Agile development with other methodologies is ideal? Can you give examples?

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.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.