Today there is a certain appetite to use agile methods again for software development. The promise of being faster, smarter, cheaper of course no one wants to miss. But in fact there is already a long history of doing projects the agile way. And I don’t mean that the more “classic” method of not using a method at all, is agile too . Well known Dutch thoughtleaders like Ron Tolido and Sander Hoogendoorn already wrote some books about agile software development quite a few years ago. Other professionals like Birgit Klomps and Tommes Snels became experts in workgroups and softskills, may be the major pillars of agile projects. In fact, a number service providers, just like my own employer, already had project centers with agile development as one of their key spearheads. I'm still happy a was heading one of them in those days.
So we’d better look at these best practices and see what we can learn from the past. Of course we look at other examples of agile development like Scrum and XP but in essence the basic principles do not differ that much from IAD (IterativeApplication Development) or SMART.
There are two angles to look at the advantages. From the clients perspective and through the eyes of the developer.To start with the first, clients expect software development to be fast, cheap, understandable and predictable, just to mention a few important aspects. Writing massive documents and disappearing long with them, is not the flexibility the client usually is looking for. At the same time, software engineers don’t want to have much paperwork to write and maintain as well. At the end of the day, it’s all about writing code, isn’t it?.
However, there are a few major pitfalls according to the tradition of agile projects. First of all, it puts a lot of pressure on the overall skills of the engineers. In fact, a lot of documentation is written to hand knowledge over from one person to another with different backgrounds, knowledge and experience. And often in another phase of their careers. Agility demands a more fluent approach to this. Separating activities and distribute them to different person might put a lot of pressure onto communication or efficiency. On top of that, not being able to utilize all available time because people cannot or don’t want to do certain tasks, forces the project to be slow and expensive after all. The need for a bunch of very good software engineers to overcome above mentioned dificulties, demand tougher selection of people and an even tougher training program.
Secondly, as almost every agile method relies heavily on a very close contact with the key stakeholders, in the beginning due to swift progress of the first prototypes, the expectations are set high .However, as with a lot of projects, the sting is in the tail. Integrating an application into the rest of the technical and business environment often proved to be a bit more difficult as planned. Or, and this happens in most cases, the “must haves” are not separated enough from the “could haves”, at least given the budget and/or time constraints. In all above cases either the business or the IT-department is disappointed and probably both.
There is a simple solution to this. Agile software development is definitely an approach to look at when saving time or costs. But, look before you leap!
Productivity 
So we’d better look at these best practices and see what we can learn from the past. Of course we look at other examples of agile development like Scrum and XP but in essence the basic principles do not differ that much from IAD (IterativeApplication Development) or SMART.
Comments (4)
