Saturday, November 14, 2015

Risk Management in Agile

Primarily Risk is something that may occur and cause unexpected or unanticipated outcomes.
Traditional project management applies full-blown Risk Management techniques and recommend a full-blown risk register to monitor for managing and controlling risks.

However there is no definite consensus on the need for risk management within the Agile method.
In many of my classes, participants ask how Scrum and Agile address risk management. Some are concerned that Agile or Scrum completely ignore risk management.
Here is the rationale. First, a great deal of explicit risk management becomes unnecessary when a project uses an agile approach. The short iterations, single-minded focus on working software, heavy emphasis on automated tests, and frequent customer deliveries help teams avoid the biggest risk most projects face—that of eventually delivering nothing. So, it is not surprising that many agile projects forgo any form of explicit risk management

This has led many to believe that risk management is irrelevant in an iterative model, rather manage risk & issues through the natural sprint progression.
Because of this, managing risks may not seem to fit naturally into the Agile context.

However risk can be undertaken in Agile also without any formal risk management, may be preferably thru simple techniques: 
  • Simple Risk Register
  • Simple Risk Burn-down chart

 Simple Risk Register

Below are the attributes to keep risk monitoring thru simple risk register.
Risk register must be made available for the team so that it can be managed and monitored collaboratively. 
  • Description of risk: A one- or two-line overview of the risk. It should be simple and easy to comprehend.
  • Date identified: Date when the risk was identified.
  • Likelihood: Estimated probability of occurrence of the risk.
  • Severity: The severity of the risk is assessed based on impact of the undesired outcome.
  • Priority (optional): This could be either given an independent value or set as a product of likelihood and severity (above). A high-severity risk with a high likelihood should receive more importance than a high-severity risk with a low likelihood.
  • Owner: The person who manages, controls, and takes action in response to the risk.
  • Action: The response defined to manage/control the risk.
  • Status: Indicates whether the risk is open or closed or being monitored.

At every sprint meeting, the risk register must be reviewed and updated with any new information obtained over the sprint.
This way risk management becomes an integral part of Agile.

Risk Burn-down Chart

Another interesting technique, to managed and controlled risk is thru Risk Burn-down Chart (Originally introduced by John Brothers in The Agile Times in 2004)
In essence, the burn-down chart represents the status of the risk across the iterations.
Similar to other burn-down charts, the ideal burn-down would be a linear decrease of consolidated risk exposure over the sprints.


Risk Exposure is collected into a table similar to a risk register as below. 
  • Risk: Description of the risk in a few lines.
  • Probability: Likelihood of the risk.
  • Size of loss: Amount of time lost should the risk occur. This could be represented in days or story points.
  • Exposure: This is computed as a product of the probability and size of loss (above).

 An example is shown below. The consolidated risk exposure is shown in the final row of the risk register.


This consolidated risk register is reevaluated at every sprint meeting; its values are adjusted based on the current assessment of the existing and new risks.




Summary:

Above are two of the bare-minimum approaches that are effective in Agile. They're simple to manage and align with the iterative process.
Adopting one of these is critical to having a proactive risk management approach.


Regards,
Arun Manglick

Saturday, October 24, 2015

Agile Estimation

First time, putting this link directly. as this post does not require references from multiple sources .. 

http://www.deltamatrix.com/agile-estimation


Regards,
Arun Manglick

Wednesday, September 30, 2015

Sprint Retrospective Meeting - Facts & Rules

SourceAgile Project Management with Scrum by Ken Schwaber

Duration:

1.     Time-boxed to 03 Hours (Three Hrs).
2.     Occurs after Sprint Review & Before Next Sprint Planning meeting.
  
Attendees:

3.     Team, Scrum Master, and Product Owner.
4.     The Product Owner is optional

 Retrospective Procedure

5.     All Team members answer two questions:
a.     What went well during the last Sprint?
b.     What could be improved in the next Sprint?

6.     Also team members can think on four Short Subjects:
a.     Start Doing
b.     Stop Doing
c.     Do More
d.     Do Less

7.     The Scrum Master writes down the Team’s answers in summary form.
8.     Scrum Master does not provide answers, but facilitate the Team’s search for better ways for the Scrum process to work for it.

Action Items – At The End

9.     The Team prioritizes in which order it wants to talk about the potential improvements.
10.   Actionable items that can be added to the next Sprint should be devised as high-priority non-functional Product Backlog.

More Details On Retrospective

11.   Type of Retrospectives
a.     Iteration Retrospective
b.     Release Retrospective
c.     Project Retrospective
d.     Surprise Retrospective

12.   Retrospectives Improvements: Retrospective offers multiple improvements.
a.     Improved Productivity
b.     Improved Capability
c.     Improved Quality
d.     Improved Capacity

13.   Steps to Conduct Retrospectives
a.     Set the Stage
In this step, aim at creating an atmosphere where people feel comfortable speaking about things that may not have gone well on the project.

Few techniques:
·         Check-In – Ask everyone to summarize in one-two words what they hope to get from retrospectives.
·         Focus On/Focus Off
·         ESVP - Explorers, Shoppers, Vacationers, Prisoners
·         Working Agreements

b.     Gather Data
Create a shared picture of what happened during the iteration.

Few techniques:
·         Timeline
·         Triple Nickels – Top Five Ideas, Elaborated By Five Groups, Five Times
·         Mad, Sad, Glad
·         Local Strength
·         Satisfaction Histograms
·         Team Radar
·         Like to Like

c.     Generate Insights
This step involves driving meaning insights from the gathered data in previous step and make sense out of it.
Activities done in this step help team interpret and understand implications of the issues before then move on to solving them.

Few techniques:
·         Brainstorming
·         Five Whys
·         Fishbone
·         Prioritize with Dots
·         Identify Themes

d.     Decide What To do
                        In this step, team will decide what they will change and how they will behave differently.

Few techniques:
·         Short Subjects
1.     What Went Well,
2.     Do differently Next time
3.     Keep, Drop, Add
4.    Start Doing, Stop Doing, Do More, Do Less



·         SMART Goals
·         Retrospective Planning Games
·         Circle Of Questions

e.     Close Retrospective
                        Here team summarizes:
·         What the team decided to keep
·         What to change
·         What we are thankful for
·         Where we can use our time going forward
·         Express Appreciation to each other

Few techniques:
·         Plus/Delta
·         Helped, Hindered, Hypothesis
·         ROTI (Return on Time Invested)
·         Appreciations

Keep Blogging...

Regards,
Arun Manglick


Sunday, September 6, 2015

Product Backlog Grooming

Backlog refinement (also called grooming),  advises teams to dedicate 10-15 % of every sprint to this activity.

Key Players:
  • Product Owner
  • Team
  • Scrum Master

Process:
During the meeting, everyone helps prepare the Product Backlog for the sprint planning meeting. This usually includes:
  • Adding new stories and epics,
  • Removing user stories that no longer appear relevant
  • Extracting stories from existing epics, and
  • Creating new user stories in response to newly discovered needs
  • Splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
  • Re-assessing the relative priority of stories
  • Estimating effort for existing stories (T-shirt sizing) (Optional here, to be taken in Sprint Planning)

Benefits/Why is this helpful?

The intent of a "grooming" meeting is:

·         To ensure that the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority.
·         Groomed backlog will help streamline sprint planning meetings; otherwise, they can stretch on for hours.
·         When product backlog items contain clearly defined acceptance criteria and are estimated by the team members, the planning process does not have to be tense or overly long.
·         By dedicating a time to backlog maintenance, the team ensures that this preliminary planning occurs prior to the sprint planning meeting.


How this is different than Sprint Planning Meeting:

At this meeting, the Product Owner and the team negotiate which stories a team will tackle that sprint.
·         Time-boxed to two to four hours, this meeting is a conversation between the Product Owner and the team.
·         During the sprint planning meeting, the product owner describes the highest priority features to the team.
·         The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
·         PO to answer questions, clarify acceptance criteria, or renegotiate.
·         Team sizes story in story points based on complexity and effort required.
·         Stories are broken down to tasks and tasks are estimated jointly in hours.

References:

http://scrummethodology.com/scrum-backlog-grooming/
http://guide.agilealliance.org/guide/backlog-grooming.html
http://www.capriconsulting.co.uk/difference-between-productbacklog-grooming-sprint-planning-and-elaboration/


Regards,
Arun Manglick


Three Amigos In Agile

Three Amigo is a process to get the various roles in a Scrum team together to have a common understanding about a Feature.
The aim is to create a common understanding and shared vocabulary across these individuals.

Key Players Involved:
  • Business Analyst (Could Represent Product Owner/stakeholders)
  • Developers
  • QA Members


Essentially, this is a meeting during which the business analyst (BA) presents the requirements and tests for a new feature.
The Three Amigos (BA, developer, and QA) discuss the new feature and review the specification. Intent is to make these constituencies to be heavily collaborative (have conversations) around the Acceptance Tests or Acceptance Criteria for each user story.

Aim of the Three Amigos process is to bring:
  • Shared understanding of the requirements across the Scrum team
  • Shared understanding of the tests across the Scrum team
  • Consensus about whether a feature was specified sufficiently and is ready to go into a development sprint.

Here is the process in detail:

·         The BA should begin the session by introducing the feature to the Amigos. Why is the feature needed? Is it like anything they've done before? Is there a visual design?
·         The BA should also present the requirements (prepared prior to the Three Amigos meeting). These will be reviewed by the Amigos, who will provide feedback, identify missing requirements/edge cases. The requirements should be updated in the session until the requirements are deemed ready for development.
·         The BA should then present the test scenarios (prepared before the meeting). These are also reviewed by the Amigos. Feedback is incorporated until there is agreement that the test scenarios cover the feature's expected behavior. This ensures good test coverage.
·         The developer is asked to identify Dev tasks that need to be done before development. For example, do they need access to an endpoint? Do they need to see variants of the visual design? These tasks are assigned and put on the current sprint board.
·         The QA is asked to identify QA tasks that need to be done before feature testing. For example, do they require access to a system? Do they need mock data? These tasks are assigned and put on the current sprint board.
·         Regarding estimating, the Amigos should have a common understanding of the requirements and tests. This is a good opportunity for the developer and QA to provide estimates.
·         The feature/specification should now be designated as ready for development. It has been accepted by the developer and QA and is ready to be assigned to a future development sprint.


Few Things To Note:

·         Timebox the Three Amigos meeting (30 minutes to 1 hour, max). Schedule it to occur one to two sprints before a feature is expected to go into development.
·         To embrace the iterative approach of Scrum, there may need to have several Three Amigo sessions in order to perfect a specification.
·         The developer and QA involved in the Three Amigos meeting should be the individuals who will develop and test the feature.
·         When specifying a feature in the Three Amigos, rather than using technical language (e.g., the JSON endpoint) or plain English (e.g., the financial instrument), prefer to use domain language.

Finally aim is – Accept only those features in development that have been Three Amigo'd, so that features are pulled rather than pushed into a sprint.



Regards,

Arun Manglick