A Process Philosophy
Agile is a philosophy, as set of principles. Agile Operations is the use of Agile Principles in the maintenance of a software system. The operation of a project in an Agile environment will be much different than that of a traditional or waterfall environment.
At the very least, Agile Operations addresses the need for a system to have the ability to continuously adapt to a changing and uncertain environment.
Traditional Environment
In a traditional waterfall environment, all requirements, the design document and test plan must be identified and developed before any coding can begin. With few exceptions, all coding and integrated testing must be completed prior to Independent Verification and Validation. The software package is delivered as a single delivery. Once delivered, the work begins to develop updates, bug fixes, and other changes. And the create/delivery cycle begins again.
There is a manager who directs the activities, from requirements gathering, to coding, to unit testing, to integrated testing, to delivery. All releases of the completed software follow the same cycle. And generally, it is weeks or months before the client sees the changes they have requested.
Traditional operations are rigid, not open to quick changes in direction. The philosophy is that of stability - stability of the requirements before the design has begun. Stability of a final design before the coding has begun. And stability of the final coding before the testing is initiated.
Progress is measured in the number of lines of code created, the number of bugs identified and fixed, the number of tests completed.
Agile Environment
As discussed in other Agile Project Management articles on this site, the Agile philosophy differs significantly from a traditional approach. A few of the differences are:
- Welcoming changing requirements/functions
- Delivering working software frequently (new functions, not just bug fixes)
- Working with self-organizing teams rather than manager-directed teams
- Developers working with the Business analysts in a face-to-face environment
- Measure progress by the number of functions delivered rather than lines of coding or bugs fixed
- Examining, as a team, communications effectiveness and responsiveness
How to Implement
Once the system has been developed and delivered, the operational phase begins. Within most organizations, the operational phase merely represents a phase of the waterfall model. The system transitions from development and testing to operations and maintenance. The boundary between the two phases is definite. Once the software passes its tests and attains configuration board approval, the software is operational. At that point, "mini-waterfalls" are developed and managed to implement changes in response to new requirements. As previously stated, the changes are bundled, included in the testing of new coding, and deployed as a new release. As time goes on the cycle repeats itself until the software is retired.
Agile production maintenance, like Agile software development, differs from the traditional SDLC model. Within an Agile development environment, there is no single delivery of the completed software. The software will be redelivered as additional functions are added to the overall system. Each additional set of functions goes through the iterative process shown in Figure 1.
What Are the Barriers?
One of the characteristics of the traditional approach to development is the need to identify all requirements before any work is done and an adherence to a milestone driven process. This approach will not work with Agile processes. Depending on the general standard allowed by the client, the client may insist on a requirements document rather than a set of user stories identifying the functions to be delivered. Or they may want every imaginable user story captured before any coding is initiated. Clients may insist on formal Requirements documents in addition to the user stories.
When a new release is delivered, management has to train the users. The requirements documents have to be updated. System Documentation has to be updated. And all of the documentation is delivered with the new release. And if the objective of Agile development is to make deliveries often, this translates into the need to train personnel, to update requirements and to update design documents - often.
Agile operations represents a sometimes unnerving break from standard System Development Life Cycle (SDLC) processes. Rather than delivering small additions due to changing or added requirements, the software is modified to acquire specific functions, some of which were identified at the beginning of software develop through the collaboration of the users, the developers, the testers, and even the Independent Validation and Verification testers. The Agile operation also allows for the identification of new functions by the Agile development team.
How to Overcome Them
A company or organization does not adopt Agile methods suddenly or for a large, complex system. Participants who have a great deal of experience with a waterfall approach will have difficulty adapting to an Agile approach.
Agile can seem random, unplanned. There are no requirements. Often there is not much in the way of documentation. Not much in the way of initial design, Requirements Traceability Matrices, or any of the other documentation used in the Waterfall model.
The organization's Configuration Control Boards and other entities will not want to ignore the usual milestones for software delivery. They expect to see such milestones as an Initial Design Review, Critical Design Review, and other standard SDLC milestones.
This difference in expectation requires a great deal of communications between the system owner and the various boards. It requires an open mind on the part of the boards. Refusal to allow for a different path to software delivery will kill an Agile project, or at least make it more expensive with some of the documentation requirements. Documents have to be written; and that costs. And if the boards insist on the documentation, they are insisting on additional costs.
The system owner, once she has agreed to an Agile approach, must see an expert and disciplined team. If the team is to be self-directing, then the owner must know the team is able to produce the desired results. Again this comes back to communications on the part of the owner, team leader, developers, the testers, and the rest of the Agile team.
Benefits
Why should anyone use an Agile approach to operations? There are several reasons.
- Greater responsiveness on the part of the development team. Given the communications between the system owner, the system user, and the developers, an understanding of just what the user wants is easier to establish.
- Lower costs. Getting a function right the first time saves money. It prevents the need of recoding, redesigning, and retesting.
- Greater understanding between Developers and Testers. Within an Agile development environment, there is a much smaller likelihood of testers misunderstanding expected test results. This saves time, which saves money.
- Lower error rates. Since software developed in this operational environment is developed in an iterative, or incremental process, testing will uncover errors caused by additional functionality. These errors, or bugs, can be addressed as a part of the development rather than a failure during IV&V.
The overall benefit of managing a system's operation in an Agile environment, if done with discipline and a willingness to follow Agile principles, is lower costs for the owner and higher satisfaction for the user. The function being added throughout the system's life are those functions the User actually wants, not functions the Developer thinks the User needs.
Downside
The primary downside to an Agile operations environment is the sometimes bothersome dearth of documentation. The owner has to decide what level of documentation he or she wants. And they have to be willing to pay for it.
What to Consider
There are several things to consider in shifting to an Agile operation environment.
- How willing are the owners to make a change in how they develop and maintain software?
- How willing are the various configuration boards to forgo standard (SDLC standard) documentation, or at least working at developing a hybrid process to document the system?
- How much freedom is the owner willing to give the Agile development team in maintaining the software and ensuring the software is being kept on a course that is use to the user?