Do you remember the telephone game? That is the game where you and a bunch of your friends sat in a circle and took turns whispering a message in each other's ear. The person whispering the phrase to you could only do it once. You had to listen carefully to what they are saying and then try your best to repeat it to the next person. Inevitably, the starting phrase and the ending phrase would be different. What affected the outcome of the game and the integrity of the message? The person telling you the information was usually giggling and had a hard time repeating the phrase accurately. Other children were laughing, and carrying on while waiting in anticipation for their turn. And undoubtedly, one, or more than one person, intentionally changed the phrase to serve their purpose, which was usually to gain attention.

The telephone game has a lot in common with the traditional “waterfall” software development processes commonly used for developing and deploying DAM solutions. The “waterfall” project management approach treats the project like a pipeline. It is a process that often sees the primary business problem and requirements identified in the beginning but not addressed by the solution that is delivered in the end. This is what typically happens. A team of project owners will gather requirements from key users. These requirements will get transcribed and communicated to team members on the project. The requirements will be reviewed and validated. The project team will go off and build a solution that most likely is a combination of existing software tools, configuration and custom development. The project plan will possibly have some milestones to keep things on track. Something almost always happens along the way with this approach: the initial requirements become clouded by misinterpretation, poor recall, assumptions and new priorities. This is the result of having the discovery and design at the beginning of the project and not having allowances for validation once the software is in development. As a result, the success of the project hinges on the stakeholder's ability to accurately communicate requirements and the analyst's ability to capture them at the outset of the project. It seems highly improbable that they will get it 100 per cent right the first time. The end result is usually a solution that will only meet some of the requirements that it originally set out to address. If the project team is experienced, they will make sure, often through Herculean efforts, the needs that were met, meet the established success criteria. This gives them a checkmark for success; but in reality, the success is marginal compared to the initial intention. In cases where success criteria are not met, the solution is usually shelved or sidelined because it just does not provide any value, wasting a lot of time and effort on a problem that is then deemed unsolvable.

Why does this happen? Typically, a combination of contributing factors is at fault. One thing that is evident is that “waterfall”-based approaches do not allow for corrective actions. It truly is like a waterfall. Once you are over the edge, pardon the pun, you have to go with the flow. As the project progresses and milestones are achieved, momentum gathers and there is no going back without incurring significant cost or jeopardizing the project timeline. That is where Agile processes start to differ, they suggest a highly iterative approach to solving the problem and they center development around the most important aspect of the solution, the end user.

Before we explore Agile methodologies further, let us first look at the additional impact DAM solutions have on the software development process. Projects involving DAM complicate the project management process because of the nature of the problem they are trying to solve. DAM systems are expected to be high-quality solutions with intuitive user experiences that meet the needs of discerning creative users. They promise major cost savings, increased capacity and new revenue streams. With all of this potential, it is only natural that a number of DAM projects are high profile within a company. The attention is magnified in content commerce organizations. To try and deliver ROI, most companies defined using a DAM solution to organize their rich media, automate processes that touch it and efficiently distribute it. Figure 1 illustrates a typical approach to DAM. An organization starts by creating a centralized location to house all of their rich media and metadata. They then determine how to use that central library to support their work process and finally publish the final media or product to customers, partners, and employees through various vehicles.

Figure 1
figure 1

Functions of a DAM solution

Full size image

Organizations can realize operational benefits by establishing a centralized source for media related to a variety of aspects of their business. A DAM solution provides a comprehensive set of capabilities such as rich media intelligence, metadata modeling, automated transformations, and classification that deliver a robust solution for managing terabytes of all content types in one centralized location. Organizations seek this type of solution so that they can rely on the fact that content critical to their business is appropriately stored, managed, and protected. The rationale for this investment is evident in countless stories of organizations spending real dollars re-creating things like product shots, talent photos, and video clips when a perfectly reusable asset was created in the past but could not be located.

Companies have developed processes that result in the creation of content that is critical to driving their business for years. In the past, they have relied on a variety of disparate systems, legacy technologies, and brute-force manual efforts to create things like product brochures, signage, final form artwork, websites, technical documentation, magazines, and videos. A DAM solution can streamline these processes through automation of common, mundane manual steps. Features like version control, security, rich media intelligence, design tool integrations, and format transformations make it easier to reuse and repurpose content with minimal effort. In addition, workflow and business process management features of DAM systems enable organizations to design, monitor, and manage highly flexible processes that can include ERP, AR/AP or CRM transactions, e-mail messages and responses, Web Services integration, work activities, and so on. DAM systems are capable of supporting complex content formats and the most-demanding workflows. This automation delivers significant increase in processing throughput and a reduction in costs associated with the eliminated manual steps.

The ability to reuse, repurpose, and deliver content to different channels such as the web, print, wireless, or broadcast from a single system results in lower operating cost, increased efficiency, and more revenue-generating opportunities. DAM solutions make it easier to create, manage, and deliver content. Organizations utilize these features through their entire production process to make disseminating content to any existing or emerging channel a reality. The format requirements exist because of specific business opportunities. Solutions utilize the format transformation and metadata modeling to automate interaction with external systems that drive commerce. For example, DAM systems can automate the ability to take a video in a native editable format and transform it to channel-specific formats like iTunes, wireless and internet with appropriate quality.

The previously described architectural concepts and rationale are valid justification and solid strategic approaches to a DAM solution. They are all developed to support key operational business processes. Their impact on efficiency, capacity, and cost savings justify investment in the technology, but they do not ensure successful deployments. There is one underlying factor that is most important. It is a less-obvious reason as to why DAM solutions further complicate the solution development process. It is related to an end user's experience. All the high-level components described above are there to support users and how they work. Whether it is streamlining how their work is done, making it easier for them to find information assets, or facilitating how they distribute finished content, it is all done to make it better and faster for the users. The majority of users of a DAM system are often considered to be “creative”. The term “creative” merely serves as a label to identify users whose day-to-day tasks are extremely technical yet artistic and design focused. Take the photographer or a page layout designer. They leverage a set of technically complex tools to manage rich content formats to produce something esthetically pleasing. As such, these users have comprehensive technical requirements but demand efficient, intuitive user experience. This adds more risk to the challenge of capturing their requirements and delivering a solution that meets their needs.

DAM projects are high profile: they deliver the promise of cost savings, increased capacity, and revenue by supporting a highly critical user community. These things combined put a large emphasis on success. Unfortunately, these are the very factors that cause challenges when attempting to develop a solution with the traditional “waterfall” approach. Luckily, Agile methodologies operate well in this environment. Wikipedia states that “Agile software development is a conceptual framework for undertaking software engineering projects that embraces and promotes evolutionary change throughout the entire life-cycle of the project. There are a number of agile software development methods; most attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks.” Time-boxed iterations are an important project mechanism for managing scope and avoiding “balloon” payments. They emphasize the calendar to drive prioritization and keep fine-grained control over the project. The net impact is they keep the project cranking with fast turns and short iterations. Very early on in the project there is a continuously working system. At the end of each iteration, a functional augmentation of the existing system is created. Off the start, the system may not functionally do much, but the iterative process has an impact on the project. It keeps development teams synchronized and reduces risk by finding problems early and ensures that there is always a system for users to touch. These three factors alleviate typical project pain that is experienced when implementing a solution using traditional approaches.

In addition to them, there are other aspects of Agile that make it ideal for developing and DAM solutions. All functionality is described by user stories. These are concrete, user-centered descriptions of what the system can do and how users accomplish their tasks. They are used to gather requirements and drive design of the solution. This avoids the problem where 3,000 requirements are collected and developers carefully ensure that all of them are met on an item-by-item basis but the system is unusable. Instead, it keeps the development focused on a holistic end user-centric approach to meeting requirements. For example, the traditional process would state requirements in functional terms like the system will extract IPTC keywords and generate low-resolution instances of raw images. The user story captures the same information but keeps the focus on the user's interaction with the system. In this case, the previous requirement might be expressed like the user can log on to the system, search for an image using IPTC keywords, and view a low-resolution preview rendition of it. The second description provides more direction to the development team and allows more autonomy in making decisions about how a feature should be implemented because one can immediately understand the context of how it will be used.

Complementary to user stories for defining requirements, Agile methodologies also encourage ongoing user interaction. Throughout the process, users are involved. They assist in defining user stories, evaluating functionality at the end of each iteration, and reviewing mockups and prototypes. This builds trust with the users. They get to see their feedback taken into account throughout the process. Users steer the project early, because their direction is taken throughout the process, rather than just at the beginning in the discovery and design phase and at the end in the acceptance phase. Corrections to the solutions are cheaper earlier than when trying to redo months of work. All of this helps with user adoption; users know what the system does because they were involved and share ownership and responsibility. This “co-inventing and developing” of the system together creates an army of project champions that can even spur on viral adoption of the solution outside the scope of the original project. Since users are engaged along the way, training and knowledge transfer efforts are constant throughout the project. Most project phases usually conclude with formal knowledge transfer and training. The level of education participants have coming into the session is far greater than traditional processes, making the session far more effective.

Finally, Agile methodologies promote test-driven development. Based on user stories, explicit test cases can be created before or together with development. This means there is a constant verification throughout the process that the system is doing the right thing, rather than waiting till the end. It increases reliability, reduces risk and ensures a good match to user needs.

DAM solution development and Agile are a good fit because DAM solutions are inherently about supporting the user and the way they work with rich media and Agile methodologies emphasize the critical importance of the user — Something that traditional software development “waterfall” approaches do not systemically place much emphasize on. Agile methodologies encourage consistent feedback, limit risk, allow for early correction, and always involve the ultimate stakeholder of the system, the user.

Agile software development takes the telephone game example and turns it on its side. Instead of unidirectional controlled communication, it turns the “telephone” into a “loudspeaker”, making it impossible to not hear the right message fully and completely.