GRADAP

Maarten Winkels

Our Agile software development process is a complete package. Many clients we present our ideas and solutions to, feel overwhelmed by the new mechanisms and interactions that it proposes. They are a bit taken back by the changes they face when they would introduce this new approach. Somehow they imagine all these changes have to take place at once in a big bang implementation of the new development process. This is quite contradictory to what the principles of Agile promise: The process is adaptable, to changes, but also to existing situations. Therefore I propose a new approach: GRADAP, Gradual Adaptation to the Agile Process.

Of course Agile is not just an empty term. There are core values that have to be present to make any Agile process work, but these are not very far from the reality of most existing software development practices.

Communication is the value that is probably at the core of Agile. Of course all development teams communicate, both internally and externally. Agilists believe in open, face-to-face communication in all directions and between all parties. Although this might not be practice at most large software development firms, where communication is often quite hierarchical and only flows through well-known channels, it can also not be very far from the reality of most clients that this is an area of improvement.

Another core value is embodied in the fact that our Agile process is an empirical process. This is to say that the team learns from the process while it is doing it. Important to this value are the practices of measuring and feedback. To enable these practices the development process need to be iterative. Small iterations allow a measurable scope. They define meaningful moments for feedback. Planning in iterations is quite difficult. You’ll probably need some guidance to get going.

Basically these two values form the starting point of an Agile adaptation process. So how should you, a client, start adopting Agile? Include a few experienced agilists into your team, enable the team to communicate freely and work in iterations! Let the process enfold itself. From the start, the experienced agilists will introduce new practices, like stand-ups, pair programming, unittests, automatic builds and whatnot. Let the team decide when to use what new practices. Have an open mind, but be sure to guard the unity of the team.

This way, it might take a little longer to reach the spectacular results that experienced agile shops have. If you’d call our Agile-SWAT team, we’d be up and running in a few days. But by gradually adopting to Agile, you’d embed it better in your own organization and have the satisfying feeling to have done it together!

Comments (2)

  1. Vincent Partington - Reply

    February 21, 2007 at 11:12 am

    It sounds like a sensible approach to gradually change the way you work. But how do you address the danger of only the "easy" parts of an Agile method being adopted? Or the fact that it only really starts to work when you do it all together?

    Regards, Vincent.

  2. Maarten Winkels - Reply

    February 21, 2007 at 11:42 am

    Vincent,

    To address yout last issue first: The "fact" that it only works if you do it all together alledgedly stems from the XP guys and is about their 12 practices. In my experience, all practices have value on their own, although the combination works best. Even then, there are some practices that we hardly ever use (e.g. Methaphor).

    I think you need to introduce Agile “agilely”: do the simplest thing that works, evolve, have courage and respect, let the team decide. If the "easy" parts of Agile (whatever they might be in your context) work for you, don't change! That's why you need the experienced agilists in your team: They'll start to introduce agile practices they feel the team needs.

    Regards

Add a Comment