IBM Innovate2014 - Is Agile Compliance an Oxymoron?
Upcoming SlideShare
Loading in...5
×
 

IBM Innovate2014 - Is Agile Compliance an Oxymoron?

on

  • 346 views

Agile software development is a light framework that focusses more on early value delivery and incremental improvement than traditional tasks like detailed up-front planning, comprehensive ...

Agile software development is a light framework that focusses more on early value delivery and incremental improvement than traditional tasks like detailed up-front planning, comprehensive specifications and technical documentation. But from the perspective of regulatory compliance, this planning and documentation serve a purpose. How can we reconcile agile approaches that value a working product over documentation with the need to meet regulatory requirements for, e.g. medical devices or telecommunications? I will discuss how to bring together the apparently conflicting needs of regulatory compliance and agile, and show by example how agile teams actually approach tough regulatory requirements in finance, healthcare and telecommunications.

Learning Objectives

- How to use agile in a highly-regulated environment

- How to incorporate strict regulatory requirements within an agile development approach

- The power of agile as a risk-limiting software development approach

Statistics

Views

Total Views
346
Views on SlideShare
317
Embed Views
29

Actions

Likes
1
Downloads
5
Comments
0

6 Embeds 29

http://www.1agile.com 11
http://1agile.com 8
https://twitter.com 5
http://lanyrd.com 3
http://54.187.9.213 1
http://www.slideee.com 1

Accessibility

Categories

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

IBM Innovate2014 - Is Agile Compliance an Oxymoron? IBM Innovate2014 - Is Agile Compliance an Oxymoron? Presentation Transcript

  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Is agile compliance an oxymoron? @davesharrock
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. compliance international B2B MBA English IPO agile husbandstart-up technology newly-minted Canadian IT executive leanstartup outsourcing father enterprise transitions B2C data analysis kanban seismology PhD scrum geophysicist organizational excellence Certified Scrum Trainer® (CST) Certified Scrum Coach (CSC) dave.sharrock@agile42.com twitter: @davesharrock www.facebook.com/agile42 Dr Dave Sharrock
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Why Agile?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Growing Software Complexity Software complexity in FORD vehicles quadruplicated in 5 years 0 2.5 5 7.5 10 2005 2006 2007 2008 2009 2010 10 6 4.5 3.4 2.8 2.4 Software lines in FORD vehicles over 5 years x4 MLOC in Ford vehicles
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Increasing Complexity in Technology Environments Language types and versions released per decade, taken from O’Reilly’s Programming Language Timeline 0 22 44 66 88 110 1954-1959 1960-1964 1965-1974 1975-1984 1985-1994 1995-2004 104 50 41 25 1211 New programming languages and versions released x10
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Time to Market Due to globalization effects, and other economical changes, the time to market over time decreased significantly Deepa Chandrasekaran, Gerard J. Tellis - Marshall School of Business, University of Southern California, Los Angeles, California 1915 1939 1972 1976 1983 1994 1998 2000 2002 2004 13.5 years 3 m onths Mean time to take-off
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Agile projects are 3x more successful than non- agile projects* The report goes so far as to say, “The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.” (page 25) * According to the 2011 CHAOS report from the Standish Group The Standish Group defines project success as: • on time • on budget • with all planned features
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Why does that matter?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Defined Process Control The time required to complete a repeatable action is a valid proxy to predict time to complete
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Empirical Process Control Every step performed while creating a new product is unique, only outcome can be trusted
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. And compliance?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Why should it be more difficult to apply Agile where IT governance & regulatory compliance is enforced?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. We only listen to the cool kids at school https://www.flickr.com/photos/jordyn-tacozombie/5555279358/
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Our intuitive response is to increase control We only listen to the cool kids at school https://www.flickr.com/photos/cmdrcord/
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Our intuitive response is to increase control We only listen to the cool kids at school Compliance too often bad cop, not good referee https://www.flickr.com/photos/clydeorama/
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. what is governance and regulatory compliance?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Goals of IT Governance & Regulatory Compliance The primary goals for information technology governance are to: 1. Assure that investment in IT generates business value, and 2. Mitigate the risks associated with IT Primary goals of regulatory compliance 1. Meet federal or industry minimum standards 2. Typically breakdown into: • Work Authorization • Segregation of Duties • Process Change Control • Audit Support
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Comparing the goals 1 2 3 4 Quality Productivity Predictability Business Value Business Value Risk Management Effectiveness Exceed requirements governance agility
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Interpreted to be prescriptive "The system by which the current and future use of ICT is directed and controlled. It involves evaluating and directing the plans for the use of ICT to support the organisation and monitoring this use to achieve plans. It includes the strategy and policies for using ICT within an organisation." Australian Standard "… the leadership and organisational structures and processes that ensure that the organisation’s IT sustains and extends the organisation’s strategies and objectives" IT Governance Institute “The structure, oversight and management processes which ensure the delivery of the expected benefits of IT in a controlled way to help enhance the long term sustainable success of the enterprise.” ISACA
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Achieving agility vs. compliance Communica)on Empowerment Transparency Adaptability Itera)ve  &  Incremental Defined  Process  &  Standards Plan  ›  Analyze  › Develop  › Test Traceability Formal  review  and  approval Configura)on  Management governance agility
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. how to reconcile agile and governance processes
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Agile delivery
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. The wrong way to deliver agile compliance 0 1 2 3
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Scrum process 1.  Interac)on 2.  Documenta)on 3.  Automa)on
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Interaction
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. CONCEIVE DESIGN IMPLEMENT DEPLOY A typical product development process time-to-market
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. CONCEIVE DESIGN IMPLEMENT DEPLOY value adding non-value adding Mapping the value stream time-to-market
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. CONCEIVE DESIGN IMPLEMENT DEPLOY value adding non-value adding Common non-value adding steps include... time-to-market
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Merging agile and compliance needs Interac(on • Role  of  involved  stakeholder • Defines  minimum   requirements  to  be  met • Reviews  Requirements  &   User  Stories • Provides  reviews/direc)on   within  Sprint
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Documentation
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Is documentation waste? “Everything that does not add value to the product is waste” 1st  principle  of  lean   development
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Is documentation waste? “If you must produce paperwork that adds little customer value, there are three rules to remember: Keep it short. Keep it high level. Do it offline.” “Safety-critical systems are frequently regulated and are often required to have written requirements, traceable to code. In this case, formatting the requirements so that they can easily be evaluated and checked for completeness may qualify as a value-adding activity. Look for a table driven or template driven format that reduces the requirements to a condensed format that both users and development can rapidly understand and validate.” Mary Poppendieck, Lean Software Development
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Changing role of specifications Requirements Specifica(ons Design Code Tests Requirements  Specifica)ons   drive  implementa)on Requirements  document  system  as-­‐built Requirements  Specifica(ons Epics User  Stories Acceptance  Criteria Design Code Validate  / Update Define  / Execute Tests governance agility
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Changing role of standard operating procedures Standards  reduce   varia)on  and  allow   untrained  people  to   make  decisions. WriPen  standards  are   to  be  followed,  not   changed. A  Standard  defines   goals  for  a  team  to   reach,  and  constraints   to  observe.   An  Agile  Team  will  use   it  as  a  baseline  for   con)nuous  process   improvement. governance agility
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Changing role of document review and approval This  document  is  now   approved  as  input  for  the   next  development  phase.   This  document  is  now   part  of  a  consistent   product  increment. The  Defini)on  of  Done   and  Defini)on  of  Ready   allow  seSng  of  minimal   requirements  to  pass  to   the  next  phase. governance agility
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Lean Canvases... What?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Lean Portfolio Canvas™ have been created by agile42 and are licensed using Creative Common 3.0 with attribution (by), non commercial usage (nc) and share alike (sa) options. You can reuse and modify the template, but you will always have to leave the logo on it Feature Name (title) 1. Opportunity 2. Customer Segments What is the problem to be solved? What type of customers & users will benefit from this solution? How is the customer solving the problem right now? 3. Possible Solution What are the key points of a possible solution to the presented problem? 4. Benefits What are the benefits for the customers? What are the benefits for internal stakeholders? 6. Measuring Success What metrics will be best measure the success of the feature? 5. Business Readiness What steps are required from the business side to be able to use this capability? 7. Cost of Delay Which profile better represent the cost of delay (CoD)? 8. Costs Structure How does the cost structure look like for such a feature? One time, ongoing costs, contractors expenses, development costs? 9. Value to Customer and Business What are the expected incremental revenue for selling this feature, and what are the strategic and tactical benefit? What are the intangible values (usability, performance, customer knowledge obtained...) It will contain 5000 songs Current digital music player can only hold up to 20 songs Re-sync their music frequently - Jogging lovers - Bicycle riders - Music Professionals - media store 1000+ songs - fit in a pocket - compression - no need to sync often - change mood change song - playlists - addressing a new market - micro engineering - partnership with component builder - sales channels - Packaging - Agreement with Music Firms? - Hardware development cost - SKU costs target $170.00 - 3rd parties licenses for digital music - Usability with one hand - Long battery life - All songs you own in one place - store 1000 songs (HQ) - 1000 early adopters/week on 1st month How Can we test this?
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Minimal Viable Product Experiment with Target Consolidate learnings Evolve
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Do we understand and agree on WHAT are the needs? A Lean Canvas serves as a container to represent a specific need, and allow to have a structured conversation with the stakeholders, and agree on the objectives…
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Merging agile and governance needs Documenta(on • Document  system  as-­‐ built • Opera)ng  procedures   serve  as  baseline • DoR,  DoD  serve  as   minimal  requirements • Document  is  part  of   product  increment
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Automation (or DevOps)
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Source Inspection Poka-Yoke (Error-Proofing) Information Inspection Jidoka (Automation) Judgement Inspection Dr. Shigeo Shingo, co- creator of the TPS Avoid Errors Find Errors before they become defects Find Defects Different types of inspection
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. ATDD Unit tests Component Integration tests Performance security, load testing Exploratory & Usability testing UAT Q2 Q1 Q3 Q4 Business-facing Technology-facing Supporttheteam Critiquetheproduct Copyright  2009  Lisa  Crispin,  Janet  Gregory
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. ATDD aka BDD aka Story-testing Business-facing Supporttheteam
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Write code to pass the test Add an acceptance test Fails? Acceptance test passes? Acceptance Test Driven Development
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Undefin ed Undefin ed Undefin ed - I want to be able to sync a song with a click Acceptance Test #1 Step 1 Step 2 Step 3 X X V X V V V - I want to add the song to my “Favorite” playlist UndefinedUndefined Acceptance Test #2 Step 1 Step 2VVV Done! Done is not an opinion ;-)
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Agile Engineering Practices Delivering fast requires new methods... and new tools People need to learn new tools and new practices...
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Add a test Run the test & check failure Write code to pass the test Run tests see all pass Re-Factor Re-Test Test Driven Development
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. TDDCycle Add an acceptance test Fails? Acceptance test passes? Add a test Run the test & check failure Write code to pass the test Run tests see all pass Re-Factor Re-Test ATDD + TDD
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. “Inspection to find defects is waste, inspection to prevent defects is essential” “If you find bug regularly, you have got a defective process” Mary Poppendieck, Google Talk “Competing on the basis of speed” Dec. 15, 2006 Defects are symptoms of a poor process
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Agile Compliance is...
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Cucumber – Process Validation – Why? Dr. Christian BeckScrumMed 2013 “Any software used to automate any part of the device production process or any part of the quality system must be validated for its intended use, as required by 21 CFR §820.70(i). This requirement applies to any software used to automate device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, complaint handling, or to automate any other aspect of the quality system. FDA General Guidelines on Software Validation“ FDA General Guidelines on Software Validation
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Goals – Values - Principles Principles stated in DIN62304, GGoSV, Design Control Guidance* Agile Principles & Practices Conduct V&V throughout the SW dev lifecycle Incremental & Iterative Development Ensure consistency of design artifacts Limit WIP, „Potentially Shippable“ Configuration Management / Document Control Configuration Management Design input requirements are the result of the first stage of the design control process Backlog Grooming Design input requirements should specify what the design is intended to do while carefully avoiding specific design solutions at this stage User Stories / Acceptance Criteria
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Principles stated in DIN62304, GGoSV*, Design Control Guidance** Agile Principles & Practices Traceability Limit WIP Procedures (Standardization) Working Agreements / 5S Create Evidence (Auditability) - Independence of Review „multidimensional testing“ *General Guidelines for Software Validation **Design Control Guidance for Medical Device Manufacturers Goals – Values - Principles
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Reader 1 Reader 2 Decision - - „Well letter“ + - ! Consensus Conf. - + ! Consensus Conf. + + Recall The quality of decision is achieved by collaboration and and skillful integration of different mental models Example: Mammography Screening Independent Review Collaborative Problem Solving Independence of Review
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. The value of compliance is...
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. falling defect rates...
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. and less time ‘hardening’ the product
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. In conclusion
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Conclusions • Agility and IT Governance & Regulatory Compliance share the same objectives • Differences in HOW they are implemented drives potential conflict • Agility and Compliance can co-exist: • Involve Compliance as involved Stakeholder, providing reviews/direction within Sprint • Deliver compliance documentation as part of product increment, codified within DoD and automated tests • Automate change tracking to reduce compliance burden, and provide comprehensive oversight
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright © 2007 - 2014. More food for thought... http://www.slideshare.net/davesharrock
  • agile42 | We advise, train and coach companies building software www.agile42.com | All rights reserved. Copyright ©2007-2014. Thank you dave.sharrock@agile42.com @davesharrock facebook.com/agile42
  • agile42 | We make your Agile transition succeed! www.agile42.com | All rights reserved. Copyright © 2007 - 2014. Copyright notice All material produced in this presentation is protected by the Creative Common License 4.0 (by-nc-sa).