One of the key business benefits to Agile approaches is their ability to protect the organization from controllable risk. Market fluctuations, employee turnover and variable resource levels are all factors that, to a large extent, organizations cannot control. However, an organization can control the way in which it plans for – and responds to – these risk factors.
Each Agile principle works in a different way to protect organizations from controllable risk, but these principles also complement each other.

Responsive planning
Every time an organization commits financial, human or physical resources to a business activity, it is taking a calculated risk that the cost of supplying these resources will provide a significant enough return to justify the initial expenditure. The more that these resources are committed upfront, the greater the risk to the organization that the intended outcomes will not yield the level of return that was anticipated if circumstances change. The ideal position for an organization is to undertake a moderate upfront investment in time, money and resources, and then monitor the ongoing return on that investment before additional resources are committed.

Responsive planning is designed to enable organizations to commit small amounts of resources towards their objectives, monitor the progress of these resources against both internal and external influencing factors, and adjust the ongoing commitment based on the most current information available. This does not eliminate the potential for unforeseen issues to affect the work that is being done, but it minimizes the impact of these issues when they arise.

Frequent and continuous business value Even when Agile work is stopped due to unforeseen risks, the initial commitment that the organization made can be partially (or fully) recoverable. Agile approaches require delivery teams to produce high business value outcomes in every iteration, such as:

» sales reports that include real customer data
» working (and releasable) website functionality
» efficiencies to business processes that have been applied (and measured) in live conditions.

These are not thought papers or conceptual discussions, they are tangible outputs that the organization can continue to utilize, even if the Agile work is postponed or stopped altogether. (If you stopped the year-long projects in your organization after three months, how many of them would be able to deliver more than a pile of project plans and status reports?)

Agile approaches enable the upfront investment that the organization has made to deliver at least a portion of the intended returns. Moreover, because that portion represents the highest-priority work for the organization, there are times when receiving only these initial outcomes is sufficient for the organization to have achieved its intended objectives.

Direct stakeholder engagement
One of the biggest risks that organizations take is the assumption that the work that they are doing will meet the needs of the intended audiences. The further removed work is from the people that require these outputs, the greater the likelihood that these outputs will be misaligned. At a minimum, this means that the organization is risking absorbing the cost of rework (or discarded work); in more critical circumstances, it means that the organization is risking market share, customer loyalty, staff productivity and employee retention.

In any competitive marketplace, there is always the risk that other organizations will deliver a product or service that is more appealing to audiences. Equally, there is always the risk that customer needs will change over time. The differentiator here is controllable risk.

Agile approaches encourage the direct involvement of internal and external stakeholders so that, to the largest extent possible, their input will reflect their most current requirements, including:

» the most up-to-date information that staff members have about the organization (e.g. resource availability, changes in corporate direction)
» hands-on feedback on whether (or not) interim deliverables are meeting the needs of internal staff
» input from external customers on their projected shortand long-term future needs
» the most current information that both internal and external stakeholders have about competing products and services.

Although this does not guarantee that every possible requirement will be known in advance, it significantly shortens the window of time between when the organization identifies a need, and when it delivers the outcomes that are intended to address that need.

Regular face-to-face communication
In the same way that direct stakeholder engagement reduces the risk of business requirements not being known, face-toface communication reduces the risk of business requirements not being understood. One of the biggest factors in the failure of IT projects in the 1990s was insufficient communication. This was particularly evident in both the reliance upon upfront documentation to articulate business requirements, and the isolation of the staff members who were doing the work from the business areas that required the outcomes.

Even when organizations involve internal and external stakeholders in the identification of requirements, the value of their involvement is directly correlated to how well the people who are doing the work clearly understand what is needed. This is particularly true when the people who are doing the work do not have the same level of specialist business knowledge as the stakeholders. The more that the business requirements are misinterpreted, the greater the risk to the organization of rework and discarded work.

Regular face-to-face communication not only ensures that work will not be done in isolation of the people who best understand the business requirement. It also minimizes the potential for employees to act on the assumptions or misinformation that can arise from the one-way
communication channel of documentation. Combining regular face-to-face communication with tangible outputs in fixed iteration timeframes can remove this ambiguity (and the corresponding risk) altogether.

Minimizing waste
Until now, the focus of risk management through the use of Agile approaches has been on risk mitigation by minimizing upfront commitments in planned business activities. Included in this, is waste management by reducing the risk of resources over-producing (or going too far off-track) before their work is contained. There is also an equivalent ongoing risk when organizations allocate
resources for business processes that are inefficient.

Maximizing resource utilization involves giving staff the tools that they need to get the work done. In the same way that faulty equipment can stop a production line from moving forward, ineffective communication channels, lowquality outputs and excess movement can bring work to a virtual standstill. Organizations not only risk productivity leakages in these inefficient processes, they also risk delays in deliverables and employee frustration.

Tangible outputs
The requirement for delivery teams to produce tangible outputs in each iteration, provides significant risk mitigation beyond the ongoing business value that these outputs provide; it also reduces the potential for theoretical concepts (or prototypes) to oversimplify the work that is required for production-level deliverables to be generated. This can include everything from a physical product that takes more money to produce than the prototype indicated, through to mock-ups of corporate reports that cannot actually be produced because the information required is unavailable (or too costly to acquire). The more information that an organization has about the real costs involved in producing a required output, the better positioned the organization is to determine whether ongoing investment is justified.

Empowering the team
The very nature of Agile work provides employees with levels of satisfaction and self-motivation that go far beyond what they can get from traditional approaches to work. With Agile approaches, teams have input into the estimation and planning process. They can see tangible outputs of their work on a regular basis. They can interact directly with the stakeholders to avoid wasted effort and rework. They can produce business value instead of writing up status reports. Furthermore, because management is able to see the outputs of their work in short timeframes, these teams often get a level of independence and trust that is generally not available to them in the workplace. Selfmotivated and empowered teams are a critical part of the success of Agile approaches, and the rewarding nature of Agile work creates an ongoing source of motivation for employees, which reduces the risk of staff turnover.

Quality by design
The direct (and indirect) costs of low-quality outputs can put an organization in a greater position of risk than even the most inefficient business process. Internally, organizations risk lost resource time as defects are addressed and outputs reproduced. Externally, organizations risk their reputation in the marketplace and ongoing customer loyalty.

Agile approaches mitigate this risk by putting active checkpoints in place throughout the process to confirm (to the largest extent possible) that ongoing work is delivering high-quality results for stakeholders. These approaches further mitigate the risk of low-quality outputs by encouraging continuous improvement throughout the process, including simplified (and more sustainable) business processes. This positions the organization to not only identify risk, but to be able to respond more quickly, and cost-effectively, to any unexpected issues that arise.

Individually, each of these Agile principles has the ability to protect organizations from some degree of risk. When they are combined in Agile approaches, however, the level of risk mitigation for the organization increases significantly – and, when they are used systematically across the organization, the level of protection from risk can increase exponentially.

Source of Information : IT Governance Publishing-Agile Productivity Unleashed 2010


Subscribe to Developer Techno ?
Enter your email address:

Delivered by FeedBurner