Friday, 19 September 2014

Role of a Scrum Master

The first thing we have to be sure when dealing with SCRUM master is whether they have a full time Scrum masters, and the second question we have to ask is if what do they do?
We usually don’t find a full time scrum master.  Scrum master is described by scrum guide as one who teaches, facilitates and removes impediments. When the team is relatively new it takes time and the team follows scrum religiously. This is when the team needs a scrum master who can teach scrum full time.
Facilitating is necessary, though it takes only 20 to 30 % of the time. The issues tend to lessen as the team learns to resolve them.
If a person puts 100% of his efforts being a scrum master, i.e. if he is training, facilitating that takes up only 20 to 25% of his time. He has to devote himself in helping the team with their work.
The first step is to train the project managers in Agile. Try to get them to be certified scrum masters, and agile project managers, preferably from Project Management Institute.
Thus the project managers become the first scrum masters.  At first the scrum master shouldn’t be assigned to one team.
Probably assign two to three teams to one project managers. Their role is to train the team in Scrum.
This has to be followed for the initial six months, until the team gets used to the concept of Scrum.
Then once you are past the first 6 to 9 months have one of the team members to be a scrum master, it would be ideal if the team was allowed to select the scrum master from their team.
Then elevate the project manager to the level of program manager. This would enable them to become accountable for cross team initiatives,
Rearrange management structure, now instead of a functional manager we have a delivery manager.
The delivery manager is now accountable for training agile.
Thus Scrum Masters was underway as a position and evolved to be a role as the team becomes more Agile mature.
The bottom line here is we have less people doing same amount of work. This is without the need of a dedicated scrum master, Along with this we need to have a contingent plan.

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

Thursday, 4 September 2014

Identifying Risk in Scrum

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 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 risk with regards to the possible cause, the area of uncertainty, and the potential effects if the risk occurs.
One major step to manage risk is correctly identifying the risk. The Scrum Body of Knowledge (SBOKTM) explains the process of identifying a risk in detail. According to SBOK, the scrum team members should attempt to identify all risks that could potentially impact the project. Risk identification is done throughout the project and identified risks become inputs to several scrum processes. The following techniques are commonly used to identify risks:

  1. Review lessons learned from retrospect sprint: Learning from similar projects and earlier sprints in the same project and exploring the uncertainties that affected those sprints and projects can be a useful way to identify risks.
  2. Risk checklist: Risk checklists can include key points to be considered when identifying risks, common risks encountered in the Scrum project, or even categories of risks that should be addresses by the team. Checklists are a valuable tool to help ensure comprehensive risk identification.
  3. Risk prompt lists: Risk prompt lists are used in stimulating thoughts regarding the source from which risks may originate. Risk prompt lists for various industries and project types are available publicly.
  4. Brainstorming: Sessions where relevant stakeholders and members in the scrum core team openly share ideas through discussions and knowledge sharing sessions, which are normally conducted by a facilitator.
  5. Risk breakdown structure: One of the key tools used in identifying risks is a risk breakdown structure. In this structure, risks are grouped based on categories or commonalities. For example, risks may be categorized as financial, technical, or safety related. This allows the team to better plan for and address each risk.