Agile and the nature of decision making
Upcoming SlideShare
Loading in...5
×
 

Agile and the nature of decision making

on

  • 6,648 views

This describes an approach to integrating Risk Management into Agile in the Enterprise.

This describes an approach to integrating Risk Management into Agile in the Enterprise.

Statistics

Views

Total Views
6,648
Views on SlideShare
1,556
Embed Views
5,092

Actions

Likes
1
Downloads
88
Comments
0

14 Embeds 5,092

http://www.leadingagile.com 4886
http://feedly.com 124
http://feeds.feedburner.com 40
http://inoreader.com 9
http://digg.com 8
http://www.newsblur.com 7
http://www.twylah.com 5
http://feeds2.feedburner.com 3
http://feedproxy.google.com 2
http://www.linkedin.com 2
http://www.dzone.com 2
http://christianekstrand.newsblur.com 2
http://www.feedspot.com 1
http://webcache.googleusercontent.com 1
More...

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • ICACTUS: A silly acronym to remember the decision making factors. We are not rational decision makers for the most part. We are certainly not systemic / holistic decision makers. Most of the time we make decisions:with limited information, not thinking through the bigger (system) consequences, without exploring alternatives (do the first thing that comes to mind that works), When is the right time to make the decision (real options, cost of delay, commitment/holding cost), without thinking about the outcomes, andthat result in local optimization.
  • When we don’t have t
  • When we don’t make aren’t making good decisions (ICACTUS)with the explicit intention to reduce risk – we are likely to incur losses and miss opportunities. Risk Management is all about making good decisions throughout the project.
  • I am interested in raising the risks we need to pay attention to. Often, I will move a risk to a 1 or 0 when I want to monitor it – after I have done everything I can to manage it. For example, adding contingency to a project schedule for an external dependency, getting organizational support to escalate the dependency, and then setting up a weekly meeting to track the status of the dependency may be all I can do for a certain risk. At that point, I can burn the risk down to a lower number – but I still need to monitor.
  • You can integrate the risk work directly into teams backlogs. In my experience we do this we delivery teams – but often have a distinct risk board for the Product Owner Teams.

Agile and the nature of decision making Agile and the nature of decision making Presentation Transcript

  • Agile and theNature of Decision Making Risk Management for Agile in the Enterprise
  • Dennis Stevensdennis@leadingagile.comEnterprise Agile Coachwww.leadingagile.comtwitter.com/dennisstevensLinkedin.com/in/dennisstevens
  • What we’re going to talk aboutWhy we need to figure out risk management in largeagile projectsPractice a proven approach• Define Risk Drivers• Agile Risk Assessment• Integrate Risk Management
  • Decisions are made throughout a project
  • Decision making is impacted by many factors• Available Information• Uncertainty about Consequences• Awareness of Alternatives• What Context we are paying attention to• When the decision is made and how much Time we have to make the decision• Uncertainty about the desired outcomes• Conflicting concerns among Stakeholders
  • Decisions are interdependentA decision in one area may reveal or create other problems in other areas.
  • Risk ManagementRiskThe likelihood of suffering a loss or missing anopportunityRisk ManagementHow decisions are made under uncertainty during theproject to:• avoid losses on the project that are avoidable, and• benefit from opportunities that arise during the project
  • Risk Management in AgileAgile has risk management implicitly built in• Feedback cycles (Product, Progress, Process, and Capability) are built in throughout the agile cadence• Co-located teams (individuals and interactions ) facilitate shared understanding• Agile teams may explore alternatives through spikes and dialog• Continuous delivery of working-tested software
  • Agile Implicit Risk Management Uncertainty AmbiguityAgile is designedfor higheruncertainty Certainty
  • Agile Implicit Risk Management Uncertainty AmbiguityAgile is suitable forhigher certaintyefforts Certainty When practiced by mature agile practitioners in a co-located environment on relatively small projects –implicit risk management may be appropriate
  • Limits of Agile Risk Management• Can miss important aspects of the program outcomes that are outside the teams line of sight• Makes is difficult to measure the risk impact• Can encourage pushing risky things off so we can maintain an optimistic burn-up• Often is tactical in nature – focusing on a local effect without a clear connection to the outcomes
  • “Traditional” Risk ManagementRisk Management in Many Organizations• Tactical in nature• Focuses on threats and the direct consequences of the threat• Driven by bottom up analysis• Often identified, assessed and managed independently of the teams executing the work
  • Tactical approach to risk management Uncertainty AmbiguityTactical Risk managementis designed for fewinterconnections inrelatively certainenvironments Certainty Entities 1, 2 Many Dynamic
  • Limits of Traditional Risk Management• Creates bureaucratic overhead• Managing point solutions mean that the risk impact may not be closely connected to objectives• Significant gaps in ability to handle ambiguity and emergence• Ineffective integration of risk-management• Often ignores opportunities
  • Insufficient approaches to risk management Uncertainty Ambiguity The problems we are solving today operate in high uncertainty and dynamic, interconnected systems. Certainty Entities 1, 2 Many Dynamic
  • What is neededTo handle scale• Explicit risk management• Systemic view of riskTo handle ambiguity• Continuous risk management• Integrated with the work and the team• Exploits opportunity as well as avoids threats
  • What I’ve drawn on for this approachSignificant Experience with Agile in the EnterpriseSEI-CMM research into Systemic Risk Management(MOSIAC)Lean-Startup, particularly validated learning, scientificexperimentation, and iterative product releases
  • Risk Management for Agile in the Enterprise• Identify Risk Drivers • Identify objectives • Determine risk drivers• Agile Risk Assessment • Assess against risk drivers (Threats and Opportunities) • Risk profile / burn-down• Integrate Risk Management • Plan responses • Risk board • Acceptance criteria
  • IDENTIFY RISK DRIVERS
  • Define the ObjectivesProduct• Functional, Performance, Operations, Usage, Maintainability, Deployment, TransitionBusiness• Financial, Market, Adoption, SatisfactionConstraints• Cost Constraint, Schedule Constraint
  • Risk Drivers• A driver is a factor that has a strong influence on the eventual outcome or result• Drivers enable a continuous systemic approach to risk management• Effects of conditions and potential events can be aggregated across a program
  • Risk DriversRisk drivers are stated from a success state and a failure state. Our processes are sufficient for Success State delivering this productDrivers Our processes are inadequate to Failure State deliver this product
  • Risk Driver Starter• Mosaic defines 20 drivers in 6 categories • Seems like a lot from an Agile standpoint• I have used two – internal to team external to team • Has proven to be too light• I am currently using five • Business • Technical • Feedback • Organizational • Dependency
  • Identify Risk Drivers• Do this with the same group who is doing Release and/or Program Planning• Tailor the drivers to your effort • Remove extraneous drivers, add missing drivers to the list, combine or decompose drivers so they make sense to the team • Write a success condition statement and a failure condition statement • Adjust the wording in each driver to be consistent with the programs language
  • Business Risk DriversConsider• Clear Objectives• Customer / End-User Understanding• Appropriate Requirements• Plan and Constraints• Adoption Barriers• Trimming the Tail• Pivoting• Operational Preparedness
  • Business DriverCustomer UnderstandingSuccess State:The product is appealing to consumers and increasescustomers using automated systems for bank depositsFailure State:The product is viewed as threatening or unreliable tocustomers and more customers use the bank and drivethrough for deposits
  • TechnicalConsider• Development Tools and Technologies• Technical Execution Ability• Design and Architecture• Delivery Process (Design, Develop, and Deploy)
  • Technical DriverDevelopment Tools and TechnologiesSuccess State:The tools and technologies are sufficient to support thedelivery of the solutionFailure State:The tools and technologies hinder the delivery of thesolution
  • FeedbackConsider• Technical Performance• Fit to Need• Compliance Testing• System Capability• System Integration• Operational Support• Certification and Accreditation
  • Feedback DriverTechnical PerformanceSuccess State:Our test environments, test data management, and testdeployment are suitable to gathering rapid feedback toensure technical excellence is deliveredFailure State:Test environments, test data management, and testdeployment contribute to delays that cause theprogram to fail.
  • Organization and EnvironmentConsider• Staffing and Team Stability• Coordination• Project Management• Facilities and Equipment• Organizational Conditions• Political Concerns
  • Organization and Environment DriverStaffing and Team StabilitySuccess State:Our teams are fully staffed with analysts, testers, andengineers so they become high performing teamsFailure State:Testers are pulled onto many projects and there issignificant churn on the project from holdingcompleted code that can’t be tested when completed
  • Dependency• Suppliers, Partners or Collaborators• Applications• Software• Systems or Sub-systems• Hardware• Legal, Compliance, etc
  • Dependency DriverHardwareSuccess StateThe scanners in the ATM machines consistentlyproduce a high quality of inputFailure StateScanners in ATM machines are not calibratedsufficiently to balance between fraudulent deposits andsatisfactory scans
  • Workshop #1• Review the case study• For each Risk Driver discuss with the team and write a success statement and a failure statement• Focus on creating a future vision and a shared understanding of the opportunities and threats
  • Workshop #1 Discussion• Would effort be useful on your projects?• What would make this effort difficult?• Do you think the risk drivers would become stable over time – or do they shift from effort to effort?
  • ASSESS RISKS
  • Identify Events for each Category• Working with the whole team – identify events that could influence the success state or the failure state• This can look like story mapping Hardware Failed Implementation: We invest in the product and we can’t implement it in the field because the scanners are bad. Reduce Time: We may be able to reuse the Image Interpretation software from SOG to overcome deficiencies in the scanners.
  • Risk Management in Release Planning
  • Evaluate Risk Events Impact Small-1 Medium-3 Big-5 Likelihood Low-1 1 3 5 Medium-3 3 9 15 High-5 5 15 25Risk Likelihood Impact Risk ScoreFailed Implementation: We invest in the product 3 5 15and we can’t implement it in the field because thescanners are bad.Reduce Time: We may be able to reuse the Image 3 3 9Interpretation software from SOG to overcomedeficiencies in the scanners.
  • Risk Burn-DownThe risk burn-down measures the rate we are reducing the total risk score for aproject.You probably want to burn down risk faster than your features are burning up
  • Assessing the Risk Profile• Driver State • Driver is almost certainly in its success state • The driver is most likely in its success state • The driver is equally likely in its success and failure state • The driver is most likely in its failure state • The driver is almost certainly in its failure state
  • Risk Profile X X X X X
  • Risk AssessmentUse the Risk Burn-down or Risk Profile to encourage early risk reduction. Risk First Then Value
  • Agile and Compliance GatesPhase Gate 0Candidate Project Phase Gate 2 Phase Gate 4 Validated Plan and Architecture Acceptance and Closure Phase Gate 1 Phase Gate 3 Clear and Stable Objectives Deployment Ready
  • Agile and Compliance GatesPhase Gate 0Candidate Project Phase Gate 2 Phase Gate 4 Validated Plan and Architecture Acceptance and Closure Phase Gate 1 Phase Gate 3 Clear and Stable Objectives Deployment Ready Following Agile Release Planning including identification of drivers and first cut of risks
  • Agile and Compliance Gates All 15 and 25 risks are reduced, retired, or acceptedPhase Gate 0Candidate Project Phase Gate 2 Phase Gate 4 Validated Plan and Architecture Acceptance and Closure Phase Gate 1 Phase Gate 3 Clear and Stable Objectives Deployment Ready
  • Workshop #2• For each Risk Driver identify one or two events that would influence the driver• Evaluate those events on the Likelihood-Impact Scale – use a planning poker approach to determine the total score• Fill in the two charts (Risk Profile, Risk Burn-down)• Discuss how the Risk Profile combined with a release burn-down might influence more productive behavior in the project
  • Workshop #2 discussion• What is the difference between a risk event and a risk driver?
  • Workshop #2 discussionBased on the Feature Burn-up, which project is in better shape? Feature Burn-up
  • Workshop #2 discussionWith the Risk information incorporated, which project is in better shape? Feature Burn-up Risk Burn-down
  • INTEGRATED RISK MANAGEMENT
  • Integrated Risk ManagementAgile Teams• Product Owner Teams: Responsible for getting the work ready for the team and paving the way for successful delivery.• Delivery Teams: Responsible for delivering working tested software in a stable velocity at a sustainable pace
  • Agile Cadence Story writing
  • Integrated Risk ManagementIdentify, Assess, Create Response, Apply Response, RiskRetired, and Monitor• Risk Stories Integrated into Backlog• Risk Management Board• Track Items to Monitor• Integrate Review of Risk Drivers into Ceremonies• Acceptance Criteria
  • Risk BoardReady Doing Done Retired Mitigation Mitigation Risk Mitigation Risk Risk Mitigation Risk Risk Mitigation Mitigation Monitor Risk Mitigation Mitigation Mitigation Capacity Compromised Requirements Churn Mitigation Late Delivery from SOG
  • Workshop #3• Review the Agile Cadence and discuss the questions on the Workshop #3 Worksheet
  • Workshop #3 discussion• What are some ways that we can integrate explicit risk management into Agile?• How can we improve decision making on projects by making risk management explicit?• How can we avoid creating overhead in incorporating risk management?• Do you think this approach could be suitable for external audit and governance compliance without creating a risk management for risk management’s sake approach?
  • Questions and DiscussionRisk Management for Agile Projects• Identify Risk Drivers • Identify objectives • Determine risk drivers• Agile Risk Assessment • Assess against risk drivers (Threats and Opportunities) • Risk profile / burn-down• Integrate Risk Management • Plan responses • Risk board • Acceptance criteria
  • Thank YouFor additional questions or information contact me at dennis@leadingagile.com