Agile

Since 1994 I have been active in the area of what we call now a days Agile. In 1994 I switched to Rapid Application Development. I percieve RAD pretty much as the founding concept for later Agile developments. RAD introduced the combination of prototyping, userinvolvement, iterations, etc. For me it felt as common sense.

RAD had a few gaps. I did fill in those gaps in my own way. In 1997 I got to know about DSDM (Dynamic Systems Development Method) and it filled those gaps almost 100% the way I did it myself and I decided to switch to DSDM. DSDM has evolved into DSDM/Atern. I got certified as Practitioner and Trainer and later in 2000 as Consultant.

My commitment was and is still in a way that I want to stay involved, learn and innovate. This is also my motivation to be active (still) in the DSDM Consortium in the beginning of this century and now in the Agile Consortium International as chair elect.

At the Rotterdam University for Professional Education Agile is also the core of what I lecture, in combination with Facilitation and graduarion projects. So on this site you are able to find some of my lectures as well.

Going through this website it is helpful to know my defnition of Agile, and realize at the same timen that the other authors of the Manifesto might have a (slightly) different definition. For me Agile is a disciplined proces itself with built in flexibility to track and deliver the real business requirements that serve end users at their fingertips. Therefor my definition of Agile is:

Serving the business by being adaptive.

To be able to do I consider a few techniques or concepts essential:

end user participation
No IT-professional can know the ins and outs of the day to day job of the edn user as well as the end user himself. Therefor, do not try to replace or think for the end user but get them in the project. Help them giving the information you need to create the right solkution and let them ‘test’ along the way.
prototyping
Testing along the way by end users should be based on prototypes. Not about techniqal sketches, drwaings or descirptions end users do not understand. Show them the prototype and let them simulate their daily work. They will know what works for the best.
iterate
Giving the fact we do not know everyting up front and also that we find things out after we detected other stuff give time to end users to review a prootype a number of times to refine. Controled iterations as described in DSDM work wonderful!
prioritise and timebox
To avoid the risc of building to much (the scope creep), force choices based on business value. A strong business case in combination with MoSCoW for priorisation within a limited timeframe helps you managing budget and time (including delivery) at the same time.