Stop designing and delivering, start listening and iterating

agile development cycle

Working effectively in the age of Trump means changing how we seek to help those in need. Efforts to bring in processes like human centered design and agile development are slowly creeping in. However, as an evaluator, more often than not, I still encounter programming that has been traditionally designed and, more importantly, traditionally delivered.

For the most part, I think the development and aid sector “gets it” that we need to go to the source – the communities we are seeking to help – to identify and determine what types of assistance they are seeking. However, what is learned through these inquiries then becomes a project or program through a traditional “write it up and find funding for it” process. If or when funding is received, these programs are still, by and large, delivered traditionally. That is, the project becomes something of a race to implement and deliver on the too-many outputs promised, without true consideration regarding the outcomes sought. Monitoring and reporting in these programs is standard practice, but examples of using monitoring data to actually adjust (or completely change) the direction of programming are far and few between.

There is a short, sweet and very on-point article recently written by Ofir Reich on the Feedback Labs blog that makes the case for bringing agile development to the fore. Beyond a best practice to complete normalization. Check it out to learn more about:

  • Not planning, but iterating as you design and develop programming
  • Learning to fail early and often, and
  • Short circuiting your feedback loops, so that you are able to directly listen to those who would benefit from your assistance directly.

Check out the full article here

Do you use an agile process in your practice? Tell us about it in the comments below.

Share the Post: