Risk Management in Agile

In this article, we will explore the business concerns of Agile methodologies in project management. Recently, I read an article by Chris Matts and Olav Maasen discussing the challenges Agile faces. Does Agile's approach to project management in fact endanger the safety of an organization's projects?

The authors believe that if Agile wants to be utilized by large organizations, its developers must make some modifications to improve the security of the project. Therein lies its first inconsistency: Agile was created in order to deal with high-risk projects. The authors list the three main types of risks from the investor's perspective, and insist that they must be mastered fairly quickly. Before we go any further, let's discuss these points in detail:

•Risk of delivery - the project may not be delivered on time, at a given budget and quality.

In reality, there's very little risk. Thanks to ongoing cooperation with the customer, this problem practically does not occur. For projects based in Agile, quality software is always produced, for one simple reason. With each project, in addition to developers and experts in the field, the design software taps the knowledge and experience of quality engineers.

• Risk of business value - the project may have no value.

In a typical project conducted by a modern company, the most important value is the business (or revenue) that the project is intended to generate. Producing a continuous stream of value is the essential foundation of modern, iterative software development methodologies. However, in practice, an iterative generation is not easy and requires a lot of experience from the project manager and manufacturing team.

The project carried out in accordance with Agile is calibrated to cooperation and joint business success. The Agile team expects continuous and close cooperation for the duration of the project, not just during the analytical work and implementation. The mechanisms that allow you to track the progress of the work (such as by a Gantt chart) bring further increases in the function of the software. These mechanisms also allow you to correct previously approved plans, within budget and without the costly process of management change.

• Risk to the business model - that the project may hurt the existing organization of work.

If the model does not work for some reason, you have to wonder, what are other options? Which way can we go? How can we change our group of customers, channel reach, pricing, revenue streams, and so on? If someone comes to the conclusion that the model does not deliver the expected profit or does not give the customer what they need, individual components can be replaced to see what will work better. Sometimes companies try to intuit solutions step by step, by trial and error, testing various changes in their business model. In new markets, they'll check the new sales channels, they'll change the offer and pricing. Most large corporations are less inclined to take a risk and will forego more radical changes. It falls to the outside player to break all the molds and show a new way to make money. In this case, an Agile methodology can be used by anyone, adjusting it to your individual needs.

Benefits of Choosing Agile

Agile methodology focuses primarily on providing value, while maintaining safety for organizations to implement solutions. Companies choose Agile because:

• In long-term projects, it can quickly respond to changes in business.

• Agile is based on the realities of the requirements of the organization, not imaginative over-analysis.

• By deep collaboration with customers, and readiness to change (within reasonable budget), Agile promotes a win-win philosophy.

Of course, each of the Agile methodologies is different, but what they have in common is the goal of minimizing bureaucracy, with a greater emphasis on communication. Bureaucracies are not conducive to project completion, as they take a long time to analyze and spell out requirements, which delays coding. When the programmer begins to create applications relatively late, a lot of things get lost in the wash.

With the Agile methodology, developers admitted earlier into the process will shorten the time of creation, the quality will be improved and the final product will be more suited to the requirements of the customer because Agile smoothly accommodates changes during application development.

Agile Merges Business with Science

As the two halves of a powerful whole, business and science desperately need each other, though it is oftentimes hard for them to mesh perfectly. I recently had the opportunity to attend an international conference (http://2012.eurospi.net/) and talk to people from all over the world. What did I notice? We all have similar problems. These two forces - business and science – represent a cure but unfortunately, are so incredibly difficult to unite.

Agile methodology makes a clean mix of science and business, addressing and adjusting to what at first are very unrealistic requirements. By assessing the problems of the market and changing the model, Agile can deal with them practically, in real time mode. For example, sometimes a consultant makes contact with a person or organization, to implement or improve methods in order to reach a solution on their own. A company wants to improve its efficiency, or perhaps the quality of products, or organize the way it works. Why? Most incentive to change, in business as well as in personal life, is the sudden shock. This may be something wrong (e.g. loss of an important client), which shakes the company, or positive (e.g., gaining an important customer, the dynamic growth of the company, the introduction of new products/services, expansion of sales market, or increase in the number of employees).

In small companies, we witness the principle of the Maslow's pyramid in action. As we strive to survive, our lack of security compels us to focus on reaching self-actualization. We find the most important success factor is the support board. Even though we sometimes discover a brilliant idea, one thing stands in the way: management. We must convince them in order for the new idea to be implemented. If we do not, then it will not.

Please remember one thing. Preparation and application of methods requires consideration, implementation, improvement, etc. If your bosses' priorities are elsewhere, none of your ideas will move. But also remember that sometimes our boss has a lot of influence. When a company wants to improve, but a resistant individual is in the way, the head can simply use his personal power.

But is there something that can help us? Do we know what it is? Remember, that for sure, if you experience any problems, you should first see if anyone else had the problem first. Just take a moment to stop and search for the optimal solution. Very often it happens that the founders of small companies are enterprising engineers, as they have managed to create a company and successfully develop it further. Their thoughts are very focused on production, maintaining a business perspective, and they may have already found a solution to the same problem you are experiencing now.

Risk Management in Agile

Most of the literature describing Agile methodologies completely ignores the topic of risk management. However, the risk is inherent in the projects by their very definition - if the project is an innovative project, then risk is associated with it. To avoid doubt, assume the definition of the risk to be any future, uncertain event that may affect the scope, time, resources, or quality of the project.

In fact, Agile has risk management inherent in the methodology, because of the short iterations, providing only the active version of the product, constant contact with clients, and surveys, which include the project scope, technology and processes used. Being careful to the consider the possibility of a good functional alignment of priorities, where all of those projects at high risk are first, we get a system that is expected to cope with risk. If the risk is to materialize thanks to a short iteration, we will be able to quickly change the scope of the plan and adapt to new situations. By selecting the most risky project as the first, we will be able to quickly test the feasibility of the project.

The activities of the Agile methodology can significantly reduce the risks associated with technology and uncertainty about the scope of the project. Unfortunately, these are not the only risks that may arise during the project. In particular, in larger organizations and projects, there is much more risk related to the financing of the investment, integration with other system components, system implementation in production environments, the organization of the market situation, or even domestic policy. Such risks are not only due to the short iterations and focus on delivering value. These risks are completely ignored in most of the literature on Agile. So dust off time risk management methods straight from PMI (Project Management Institute).The processes of identification of risk and qualitative evaluation occurs under the name of Planning Responses to Risk. For each risk, you can use one of four general strategies:

• Acceptance - do not do this, and let's move on.
  
• Avoid - take active steps to ensure that the risk does not occur.
  
• Minimize the impact - know the risk, and do not wait for the moment when it appears, but have a plan to reduce its impact.
  
• Transfer - Pay someone else to worry about the risk.

Regardless of the method you use to conduct the project, if you choose anything other than the risk acceptance strategy, your project plan should be adjusted to the chosen risk management strategy.

In the case of Agile, if you want to avoid any risk, the steps leading to the avoidance should be recorded and assigned to the earliest possible realization of the iteration. In this way the risk will be less likely to occur.

If you choose to minimize the impact, in this case the ratio of the Agile is held "on the side," in a set of features / cards that will come to pass if the risk is to materialize.

However, if we choose a strategy of risk transfer such action also entails the implementation of operations, but usually these are not activities for the project team.

What is interesting is that due to the nature of risk of which we speak here, very often plans for dealing with risk will engage in a small way the design team and owner of a much larger product. However, this risk can be managed well in Agile methodologies. Manage means to plan, assign responsibilities and then oversee their implementation. Sometimes it can be reduced to the regrettably we will have to be different than the iterative method to manage these.

Summary

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

What should you learn next?

From SOC Analyst to Secure Coder to Security Manager — our team of experts has 12 free training plans to help you hit your goals. Get your free copy now.

Get Your Plan

The purpose of this article is to dispel all doubts related to the risk in projects developed in the Agile environment. I hope I've succeeded, and as always, I invite you to discuss this topic. Next, we'll move onto the risk of human resource management in Agile.