Monday, 22 September 2014

Introduction to Agile Application Lifecycle Management

Agile Application Lifecycle management, known as Agile ALM, is a relatively new concept, and can be defined as a marriage of Agile methodology with Software Configuration Management to develop and release software in a coherent and integrated way. The best part about Agile ALM is that it can be customized to be used with any process models and methodologies, even Waterfall and Spiral models. This approach results in processes and lightweight tool-chains which are very high quality, flexible and open to change. The primary focus of Agile ALM is not processes or tools but people. Projects are driven by people who are provided authority, and in return very high accountability is expected. In scenarios where tools will benefit, they have to be light weight and open source, so that they remain agile in principle.
  • Proper implementation of Agile ALM leads to:
  • Increase in productivity
  • Reduction of cost
  • Team collaboration
  • Removal of redundancy
  • Practical approach of coding and deployment
  • Makes software development fun
The philosophy behind Agile ALM is that it removes functional, technology and process barriers. It forms a streamlined approach wherein every process and every artefact is very nimble and adaptable. It encompasses all the phases in a lifecycle like Development, Design, Deployment, Testing, Release etc. It is not restricted to any particular phase and it also spans all artefact types with equal ease. Because it implements light weight tools and it also defines task based activities which are directly aligned to requirements, hence it allows teams to collaborate without any silos. Another feature of agile ALM is that it makes the relationship of an artefact along with other artefacts or user stories or tasks visible to everyone, it accounts for greater transparency among business teams, while helping in traceability and reproducibility.
It’s essential to take a stakeholder focus in any Agile effort; one must consider the role of releasing code in Agile ALM as well as the service orientation and application architecture. As merely adopting Agile principles is not enough unless they are inculcated and internalized, similarly it is imperative to establish an effective ALM through culture, processes, tools and manpower. Agile ALM is aligned with engineering processes spanning development cycles, which result in releases that are functionally and technically consistent. By organizing, linking, and referencing activities and artefacts, you can track the development progress as a whole. Through the use of integrated tool chains, ALM helps you to overcome the biggest challenge in the software creation process: the technological and functional barriers that make it difficult to implement a transparent and consistent development process.
Agile ALM, when implemented properly, can bring transformational changes in the way a software project is developed. It’s an innovation approach which will find many takers in the software industry in the years to come.

 To know more click on: http://www.scrumstudy.com/blog/

Thursday, 4 September 2014

How to identify risk?

How to identify risk?
Risk is defined as an uncertain event that can affect the objectives of a project and may contribute to
its success or failure. Risks with a potential for positive impact on the project are called opportunities,
whereas threats are risks that could negatively impact a project. Managing risk must be done
proactively, and it is an iterative process that should begin at project inception and continue throughout
the life of the project. The process of managing risk should follow some standardized steps to ensure
that risks are identified, evaluated, and a proper course of action is determined and acted upon

accordingly.

Risks should be identified, assessed, and responded to based, primarily, on two factors: the probability
of an occurrence and the probable impact in the event of the occurrence. Risks with a high probability
and impact rating should be addressed before those with a lower rating. In general, once a risk is
identified, it is important to understand the basic aspects of the risk with regard to the possible causes,
the area of uncertainty, and the potential effects if the risk occurs.
Difference between Risks and Issues
Risks are the uncertainties related to a project that could significantly alter the outcome of the project
in a positive or negative way. Since risks are future uncertainties, they have no current impact on the
project, but could have a potential impact on the future. The following are some examples of risks:
• Even after extensive training, the customer service representatives might not be ready to take
orders on the go-live date.
• The painting crew might be delayed due to heavy rain, which could negatively impact the
project schedule.
Issues are generally well-defined certainties that are currently happening on the project: so there is no
need for conducting a probability assessment as we would for a risk. Issues must be dealt with. Some
examples of issues include the following:
• Funding is not approved.
• Requirements are unclear.
Risks, if not addressed in time, may become issues. The goal of risk management is to be prepared, with
plans in place to deal with any risks that may occur.
Risk Attitude
Stakeholders include all people or organizations impacted by the project as well as those that have the
ability to impact the project. It is important to understand the risk attitude of the stakeholders. Risk
attitude is influenced by the following three factors:
1. Risk appetite: refers to how much uncertainty the stakeholder or organization is willing to take
on.
2. Risk tolerance: indicates the degree, amount, or volume of risk stakeholders will withstand.
3. Risk threshold: refers to the level at which a risk is acceptable to the stakeholder organization. A
risk will fall above or below the risk threshold. If it is below, then the stakeholder or organization
is more likely to accept the risk.
Essentially, the risk attitude of the stakeholders determines how much risk the Stakeholders consider
acceptable, and hence when they will decide to take actions to mitigate potential adverse impacts of
risks. Therefore, it is important to understand the tolerance levels of the stakeholders in relation to
various factors including cost, quality, scope, and schedule.
Utility Function is a model used for measuring stakeholder risk preference or attitude toward risk. It
defines the stakeholders’ level or willingness to accept risk. The three categories of Utility Function are
the following:
1. Risk Averse: Stakeholder is unwilling to accept a risk no matter what the anticipated benefit or
opportunity.
2. Risk Neutral: Stakeholder is neither risk averse nor risk seeking, and any given decision is not
affected by the level of uncertainty of the outcomes. When two possible scenarios carry the
same level of benefit, the risk neutral stakeholder will not be concerned if one scenario is riskier
than the other.
3. Risk Seeking: Stakeholder is willing to accept risk even if it delivers a marginal increase in return

or benefit to the project.
to know more visit -http://www.scrumstudy.com/blog/how-to-identify-risk/