Waterfall and Agile
25
April
2014
There are many discussions on using Waterfall – the traditional approach to project management, or Agile, widely regarded as being the best way of dealing with software development and similar situations where the client and users cannot accurately predict and state their future requirements.
Where do I stand on this? I do not recall ever having to draw a distinction between the two in a practical setting. Even in construction where much of the requirement might appear to be predictable, there will be many elements that can and should be subject to change, it being very difficult for a site developer to predict what their future occupiers – retail, commercial, or industrial – might expect. The two approaches can be blended.
An example:
A national data programme required schemas to enable data sharing for property data. These ensure that the content of any field can be read and interpreted correctly by relevant software, and, with multiple software providers, the decision was made to create open source schemas for all suppliers to adopt.
The process of creation was effectively agile, involving some leading users and engaging with suppliers both informally and later when it had reached a suitable stage for general comments and then for acceptance. Naturally, these schemas could then be subject to changes through careful version control, and their adoption was subject to the twin elements of customer demand and the availability of time in the software suppliers' own work schedules.
In parallel with the development of the software, pilot stakeholders were cleaning their own sets of data, removing duplicates, creating a single data set from a number of others for each of their organisations, and ensuring that the single data set was accurate and could be maintained. This aspect of the programme was more aligned with a waterfall approach. However, these stakeholders would all have been able to develop their own approach, perhaps using different selections of local datasets, and together could produce a preferred or best approach.
For each of them, they then had a clean set of data, one that crucially could be shared with other organisations. The schemas provided the optimum approach to sharing.
We had piloted an approach to creating and testing schemas, and to best practice for data cleansing, which then enabled further testing by early adopters - with the potential for refinements and updates - before successful national rollout.
Project management can adopt and adapt the most appropriate routes to success, whether waterfall, agile or a combination.