Every time we approach solving a problem—no matter in what arena—we are faced with unexpected changes and circumstances that we must adapt to. It is not that a plan was a waste to prepare, but rather that the plan can only carry you so far before you must begin to adjust.
This philosophy, should in many ways, guide your approach to designing the technology and operations of your media facilities. How many projects have you been involved with in which a very time-consuming, detailed design is done down to the lowest level of detail and then a few weeks into the project, circumstances change? This then causes tremendous and difficult rework of the plan.
This is especially true of software projects. Some things may be clear, but others may only be vague wishes. And since business requirements inevitably change on long and large projects, much design and implementation effort can end up being wasted.
This has long been a problem and there have been techniques developed to tackle it starting as far back as the 1960s, but really picking up steam in the 1990s. While it is impossible to describe every detail of every specific methodology that has been used, I will try to discuss the two major approaches at a high level.
The first, and more conventional and traditional means of system development is usually called "waterfall." In this approach, the process proceeds deliberately through the complete steps of development in one pass as shown in Fig. 1. This should be familiar.
Fig. 1: In the “waterfall” approach, the process proceeds deliberately through the complete steps of development in one pass. The second method, gaining rapidly in popularity, is generally called "agile." In this method the project is broken down into multiple small cycles or iterations in which the work is brought to a working state and feedback from users is accounted for before continuing to the next cycle. This can be seen in Fig. 2.
'WATERFALL'
First let's look at the traditional waterfall development methodology:
Requirements—In this step, all of the both functional and nonfunctional requirements of the project are defined. Functional requirements are the things that the system should actually do, such as use cases and features. Nonfunctional requirements are a description of how it should actually get things done—such as how fast it should respond to users or specific file formats it should support. As this step will only be done once, every attempt is made to gather every possible requirement in one elicitation cycle.
Design—In this step, all of the input from the requirements phase is used to architect and design the solution. Sub-phases can include architecture, technology selection, detailed design, and, in some cases in software, pseudo-code. The goal of this phase is to describe in intricate detail the exact work that needs to be done during the implementation phase.
Implementation—The design is now built out. As each sub-component is built, it is individually tested as a unit. Units can be tested in small groups like sub-assemblies. The testing is done to the design and as many defects are detected and fixed in this stage as possible.
Testing—The system as a whole is tested. This can include technical testing as well as "beta" user testing. All defects are tracked and as many as possible are fixed before deployment.
Deploy/Maintain—The system is deployed to the main body of users and they are trained on its operation. As the system is used, any additional defects or requirements are tracked. These items are normally addressed in future releases, which will go through the whole waterfall cycle again.
Fig. 2: In “agile” method the project is broken down into iterations in which the work is brought to a working state and feedback from users is accounted for before continuing to the next cycle. The key benefit of this methodology is its thoroughness. In some types of development, particularly those that involve life safety, there aren't really a lot of opportunities to make corrections after it goes into use. So every step must be done as thoroughly as possible.
The key problem with this methodology is its inflexibility in the face of change as well as the longer time that each step will typically take. Important requirements that come up after design begins are increasingly difficult to bring to fruition.
'AGILE'
So how does agile compare?
Requirements—In many ways this phase is similar to that in the waterfall methodology with the exception being that there is less pressure to get every single requirement identified and documented. It allows for new requirements to be brought in at any time as they will be fit into a future iteration if they are important enough.
Estimation—In this phase, a basic work estimation to implement each requirement is done. This is helpful in planning potential iterations.
High Level Planning—The overall system is architected and core technologies selected. A vision of future iterations and releases is developed.
Iterations—A project will go through N iterations as the system is built. Each one should be short in duration and would typically last a small number of weeks. At the end of each iteration cycle the system is in working condition and could theoretically be deployed if it met sufficient requirements for real-world use. A decision is made at the end of each iteration cycle whether to enter another iteration cycle or to release the technology to users.
Describe Iteration—This is the first step of an iteration. The team selects features that will be completed and describes what the experience of using the system will be like at the end of this cycle.
Implement Iteration—The features are built and unit tested.
Deploy Iteration—The features are deployed to a test system.
Iteration Quality Assurance (QA) —In this phase both testers and users use the system and provided feedback. Defects or new requirements identified at this phase are put into the list of potential items for a future iteration.
Post Iteration Final QA—When it is decided to exit the iteration cycle and release the system, there is a final and more thorough QA on the system before it goes to users.
Deliver Release—The system is released to users and training and use commences.
Examples of agile methodologies you can consider include: Agile Unified Process; Extreme Programming; Feature Driven Development,; and my personal favorite—Scrum. Even if you are not involved in software development, I recommend taking a little time to understand the basics. Agile philosophy can be applied in many areas of your work, from business processes, to technology deployment, to bringing on whole new businesses.
Just keep in mind that what you need to be agile is to have a long vision, plan and implement in small increments, and continually revisit that vision. It is a strategy that will serve you well.
By recognizing that most things are a never ending journey and embracing that with agile methodologies, you will find success is just around the corner. You can Count on IT!
John Footen is head of Cognizant's Broadcast Consulting practice. He is also co-author of the book "Service-Oriented Media Enterprise." He can be reached at jfooten@footen.tv.
