This week I want to discuss Software Development and Implementation Methodologies. These are hotly debated, and perhaps none more so than ‘Agile’ methods. Agile Software Development reforms the classical, at times pedestrian, approach of a lengthy analysis phase, followed by a lengthy specification phase, and then further sequentially organized and separate phases. This classical approach reliably delivers functionality that the project team thought was required several months or years earlier and whilst this method can work well in a static environment where the requirements are vast, and hard to determine without exhaustive investigation, it is an inappropriate method in medium sized organisations. At the outset of projects, when both requirements and software solutions are theoretical, it is almost pointless to obtain a customer’s confirmation of a specification if they don’t have a clear idea of what the solution will ‘look like’ and how it will work ‘in practice’. The Agile software development method replaces the classical sequential approach with an iterative and collaborative process. Its principles include:
1. Building frequent working versions.
2. Working closely with sponsors and users to determine a clear understanding of requirements and the suitability of solutions.
3. Collaborating closely with sponsors and users on workarounds, simplifications, and compromises.
4. Documenting requirements and specifications in tandem with iterative software versions (rather than always prior).
These Agile methods stemmed from frustration with the classical approach, which, though well defined, had a tendency to deliver something other than what was needed by the user (even when they had accepted the developer’s specification).
Agile methods are useful both for the development of specific (‘bespoke’) systems and for the development of software packages such as those from systems@work. Indeed, we use this method for the development of time@work and expense@work.
What do the Agile Development methods tell us about Implementation methods in general? To answer this question, we need to look at the way in which software packages are designed.
Software packages come in a variety of ‘styles’, two of the most identifiable styles being the Adaptable and the Configurable: In the case of the Adaptable Style a solution is achieved through programmed adaptation of a system’s predefined functionality, usually through modification, and extension of the source code delivered with the package. One might call this ‘fast-track’ bespoke development, since the package provides something of a leap forward from nothing, even if it lands the customer only half way down the track. In this context, implementation is part of the development process.
Adaptable systems are not so easy to upgrade, but they can seem to deliver, eventually, ‘exactly’ what is understood to be required. In the case of the Configurable Style a solution is achieved through the configuration of parameters without underlying software modification. Authors of Configurable packages don’t release the system’s source code, but provide a variety of interface techniques to overcome the issue of integration.
This is also ‘fast-track’ development, but even if the customer lands only half way down the track, they continue in the same vehicle rather than an adapted one. In this context, implementation is a separate process from software development.
These kinds of system are much easier to upgrade. systems@work’s time@work and expense@work solutions fall into this category. Even though it was initially developed for Adaptable or bespoke systems, the iterative approach to software implementation (Agile Implementation), is in reality the most cost effective for Configurable systems, since they can more quickly be configured in a variety of ways. This can typically be done by a single consultant, rather than through the lengthier teamwork of consultant and developer, to demonstrate exactly how a solution can meet a requirement. Iterative system prototypes can rapidly be developed, and workshop sessions can frequently be convened to try out alternative solutions. During the crucial system building phase, as long as customers and consultants are working closely together, requirements can be refined, solutions developed (and redeveloped), consensus achieved and the system documented “on the fly”.
It is the Agile Implementation Methodology that systems@work advocates. Of course this also necessitates ‘Agile’ project management, but it is far more likely to create a workable solution than a method which involves detailed initial analysis, ‘theoretical’ confirmation, and then distant ‘laboratory’ development. In practice the Agile Method involves:
Initial Requirements Analysis
Typically a one or two day session led by a systems@work consultant, with sponsors and key users, which delivers an outline of requirements and scope, and enables the building of an illustrative prototype and an outline specification (requirements and outline solution).
An outline project plan and change control procedures may also be developed during this phase.
These are workshop sessions with sponsors and users that demonstrate the proposed solution (or alternatives) in order to clarify ‘how’ the system will provide a solution and, crucially, ‘what it will actually be like to use’.
It is during this phase that we can also identify areas where requirements cannot be met (or cannot easily be met), so that compromises and solutions can be agreed and demonstrated.
During this phase, which is iterative, and subject to careful change control (identifying risks, costs, etc.), requirements and design decisions may change and documentation should be kept up to date with each prototype.
In terms of overall success, this phase is the most critical one, and the one where the Agile Method is most in evidence.
Final System Build
Once there is sufficient confidence in the solution being proposed, the final logic of the system can be completed, interfaces defined and built, procedures documented, and test plans and transition plans created.
Following this stage, the classical, sequential method becomes a little more evident, though there may be residual iterative steps if misunderstandings require some redesign. These final stages include:
1. System Testing
2. Acceptance Testing
4. Transition Management
5. Go Live Support