Process Matters

I have recently completed work on my first project using the Agile development approach preferred by Black Pepper. So what you might say - but for a developer that has spent a considerable part of his 20 odd years in the industry firmly believing in a more formal methodology, it came as a bit of a culture shock, although largely an enjoyable one.

It wasn't totally alien however. Having spent the last 5 or 6 years working as a RUP Mentor and instructor, the benefits of an iterative approach were already well understood, but as my time with the project progressed it became clear that there were many misconceptions about the differences between the Agile and RUP approaches to development.

The Rational Unified Process is often thought of as a heavy weight development process, largely due to the apparent level of complexity and the overwhelming number of activities and artefacts described within the commercial product. This is the first misconception; the RUP product is not a development process but a process framework. If RUP is to be used effectively, it must be tailored to the needs of the development environment, the size of the team, the project being undertaken and the requirements of the customer. As the level of process formality reduces, RUP can become more agile, although it will never be as lightweight or as agile as eXtreme Programming. In my opinion, Rational made a huge mistake in the way RUP was originally put together, resulting in a reputation for red tape and complexity. The real problem was the lack of understanding amongst adopters on how to tailor the process effectively. Worse still, any tailoring that is performed is often the addition of new activities and work products that represent corporate standards, without removing any overlapping elements from the base product. This results in wasted effort as development teams produce documentation and other shelf-ware that will never be used or read.

Agile has none of this baggage, but does have a reputation for allowing developers to run riot, doing the stuff that interests them and ignoring the more mundane elements such as design and documentation. My recent experience has proved that this is also a misconception; when done correctly the agile approach produces all the documentation that is actually required. Design can be performed, either as a deliverable in it's own right, or evolving out of a pair programming session. The lack of process formality does require considerable discipline from team members. Without discipline and rigour, Agile development can become very fragile.

There is remarkable synergy between the two approaches when they are done correctly:

  • Both follow an iterative development life-cycle to enable early reduction in risk and respond to changing requirements
  • Both are focussed on delivering working software from each iteration
  • Both encourage a high level of communication within and across development and customer teams
  • Both focus continuously on quality, testing the system through each iteration.

Obviously there are also some differences. For example a RUP project is more likely to produce formal design documentation using modelling tools, where agile might favour a test driven approach to drive out the design during development - any modelling is likely to be throw away sketches used to help the developer understand the problem domain rather than to communicate that knowledge to other team members. However, there are no hard rules; the deliverables required by the various stakeholders will always be the final arbiter.

The choice of development approach can make or break a project. The correct level of formality must be selected if the development is to be successful and will depend upon a number of factors including the level of customer and other stakeholder requirements, application complexity and team size, with the process effectively scaling from an agile approach such as eXtreme Programming through to a tailored RUP process as required. I would even go as far as suggesting a waterfall life-cycle might be appropriate in some instances.

There is no doubt that the development process landscape is evolving and Agile in all it's variations is becoming more mainstream, something I'll discuss further in a future blog.

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.