Agile Development – How to get started?
ASXU_Bob_Tarne 270003ASXU Visits (1772)
The use of agile techniques for executing software projects continues to grow. However, acceptance isn't universal yet. There are still organizations that haven't switched from their more traditional, waterfall approach and are reluctant to do so. This post will look at the situation from the perspective of an external consultant experienced in agile (me) and my observations working with organizations that haven't made the jump to agile yet.
There have been a number of surveys on barriers to agile adoption. One consistent theme is that culture is one of the most significant barriers to acceptance. The culture of the company was at odds with the culture of an agile team. So how does a consultant work with this?
In my experience, it begins by selling the benefits of agile techniques to the immediate project team. Using their own experience, the consultant can demonstrate how agile techniques have been used successfully. Part of this discussion should also include more details on agile, to clear up some common misperceptions such as there is no documentation in agile development or there is no planning.
Taking this a step further, delivering a small, isolated project following agile techniques can demonstrate the benefits. If the consultant is leading a team with a discrete delivery, this is a practical step. From my own experience, showing the client working software at the end of the first iteration is a big step in demonstrating the benefits of agile development.
From here, the situation can be more complicated. If the agile team is working as part of a bigger, waterfall project, more planning needs to take place to determine how to integrate the projects together. If there are no dependencies between the project components, the plan is a matter of aligning the release dates of the components.
However, if there is tighter coupling, more integration needs to occur. For example, the agile team may be delivering a business rules application built on IBM's Operations Decision Management (ODM) platform. Their deliverable will be exposed via web services to be called by another application, the one being built using waterfall. The agile team will need to define the WSDL in coordination with the design work being done by the other team, testing will need to be coordinated, and production deployments aligned. The following picture illustrates this coordination.
If there is even more dependencies between the two work streams, the amount of coordination will increase as well. There may be a need to have cross-stream meetings at the end of each iteration, or maybe even having the waterfall project manager attending the daily stand-up meetings of the agile team.
The discussion so far assumes a trained agile team coming into the waterfall environment. But what if the end goal of the engagement is to empower the client, including helping them adopt agile development? At this level, one could assume that the client organization's management team has agreed to adopt agile, which is a first step in overcoming the cultural resistance. However, there are other impediments to adoption including a general resistance to change.
As a first step, the agile team can demonstrate the agile techniques and provide a first level of coaching. But the delivery team may only be working with the client for a short amount of time, leaving before adoption has occurred. This is where an agile coach can help out. An agile coach can work with the client to help them in their adoption by identifying patterns and anti-patterns in the client’s adoption and keeping them moving in the right direction.
Adopting agile techniques, especially in a large organization that has developed a culture supporting waterfall techniques, is challenging. Developing a structured approach with incremental steps will be more effective than forcing in the new approach.