Subscribe
About

A complex endeavour

The governance model used to manage software development projects is often unsuited for agile projects.

Ziaan Hattingh
By Ziaan Hattingh, MD of IndigoCube.
Johannesburg, 22 Oct 2010

It is common cause today, after a decade or so of evangelisation, that agile produces good software development results, it addresses many of the classic problems of development, and it is steadily growing in popularity. Implementing agile can, however, be a complex endeavour, especially in large organisations with established software development capabilities.

As more and more organisations choose to go the agile route, several common challenges related to agile adoption have become obvious. In a series of Industry Insights in this forum, I will examine in detail some of these challenges.

One of the typical challenges faced with agile adoption is that the governance model used to manage software development projects aligns with the waterfall approach and is unsuited for agile projects.

IT governance is critical in ensuring the business's priorities are aligned with those of IT; that corporate responsibilities have been discharged; and that there is clear auditability between decisions made and consequences.

Nature of risk

In this regard, then, the decision to go agile rather than waterfall has a direct impact on governance - it must by its very nature introduce risk, and the nature of that risk must be understood and mitigated. The appropriate governance model must then be applied.

It often happens that an organisation embarks on an agile project but continues to enforce waterfall-like governance, which hampers the adoption and causes great frustration for team members. The fact that agile projects need a different governance model is an aspect of agile adoption that is often overlooked.

Most companies have some sort of project office that plays a role in governing the way in which projects are run within the organisation. Often, when project leaders want to test-drive a different methodology, they single out one project on which to try it. In a large organisation it is very difficult to run a project in isolation, and trying to do so with a different methodology can lead to chaotic consequences. Inevitably the new methodology - such as agile - clashes with the processes of the entrenched approach, and the project runs into conflict with the rest of the organisation.

IT governance is critical in ensuring the business's priorities are aligned with those of IT.

Ziaan Hattingh is MD of Indigocube.

For example, if the project office has governance processes built into it that are of a more traditional or waterfall nature, then typically there will be rules stipulating that development cannot proceed without the requirement being specified in detail up-front and signed off by the business user. As the provision of detailed up-front specifications is not required in agile methodology, there would be conflict and indecision in the project office, causing a delay in the allocation of development resources and project progress.

By the book

There are many examples of the ways in which the once-off introduction of a new methodology can cause problems on projects. Project offices establish rules to ensure processes happen in a predictable manner. The spontaneous introduction of a new set of rules with different processes is most likely to create havoc for the entire organisation.

Usually, such a situation is handled in one of two ways: either the project leader concludes that the new methodology is not going to be appropriate for the organisation and the project is halted; or the rules of the new methodology are adjusted to blend with those of the established methodology.

The latter is more common - and the worse outcome of the two. A typical example would be the introduction of a detailed up-front requirements specification to the agile project - agile, by its very nature, does not call for detailed requirements up-front. Instead it advocates doing detailed analysis of requirements in small increments as part of an iteration/sprint: on a just-in-time basis. One of the key benefits of agile is its flexibility and adaptability to changing business requirements. The demand for detailed up-front requirements specifications in an agile project will therefore negate some of the benefits one expects to derive from agile adoption.

Alignment with the project office, which is where all the governance processes reside, and the world in which the project is executed, is therefore critical. Without this cohesion, implementation of the new methodology will not succeed.

Share