Today’s types of software development, broadly known as ‘agile’, require changes to how traditional corporations are structured but they also require flexibility in how the theory is introduced and implemented.
Being agile about agility means not slavishly following any one model but adapting these practises to fit your specific case.
That being said there are still some general rules for almost all organisations looking to adopt more agile development.
An agile structure requires an acceptance that software development must take a more central role in wider business decisions. It is not just something which can be bolted onto the existing IT department – it will require organisational changes across the board.
Part of this is a personnel issue – an agile project needs input from all sides of the business so you need to ensure that the right people are involved right from the start.
But it also means changes to corporate structure and removing some of the silos between development, operations and other departments with an interest in the project.
All of this needs to be handled with care to avoid alienating teams who will feel invested, and protected, by existing structures.
In terms of recruitment it means looking for people with experience across disciplines which will help build teams without a development or operations bias.
It also means moving towards an almost constant update schedule ‘constant delivery’ in place of traditional prepare, test, release calendars.
The roots of agile software development came from traditional engineering. Projects in aeronautics and defence typically required project times of up to 20 years. This meant that following a traditional project management schedule could leave you with ancient technology by the time your plane was ready to fly.
Even in the PC-centred world of the 1990s it was clear that business requirements were often moving more quickly than software development. The time needed to properly define software projects meant it was almost guaranteed to be out of date by the time it was ready.
In reality even when the business needs of the project are clearly delineated the next step – how to achieve this – can shift very quickly as technology or other parts of the business environment changes.
It became clear that an iterative model, where changes are regular but small, was a better way to keep such projects on track and satisfy changing business demands.
But whatever model you choose to follow your project still needs to be managed and measured.
Accepting the bare minimum of management structures and restrictions is important – but someone still needs the data required for proper oversight and a way to steer the project.
Creating an agile infrastructure is not about reaching a defined endpoint.
It is about building systems which will remain flexible and open to rapid change in response to the changing needs of the business.
Business change is getting faster not slower.
Guessing what those changes will be is impossible so all today’s business can do is ensure it has systems in place which will give it the flexibility to deal with this ever-increasing pace of change.
