Mixing Oil & Water (how to make agile methods work with governance and compliance)

Transcription

1 Mixing Oil & Water (how to make agile methods work with governance and compliance) Stephen Gristock, Agile Delivery Leader 15 Feb Agile Consulting Services

2 YOUR PRESENTER ELIASSEN AGILE PRACTICE Originally from Wales (UK), Stephen has a background in model based improvement and advisory consulting specializing in Lean-Agile. solutions, He is a CSM, CSPO, SAFe SPC, PMI-ACP, PMI-PMP, SEI Lead Appraiser and Trainer. He has also served as a member on both the Software Engineering Institute (SEI) and PMI model Development Teams. Having led several corporate agile initiatives, he now leads Eliassen Group s Agile advisory and training services in NY. Advisory Eliassen Group s Agile Advisory Services help organizations assess agile readiness, plan for Agile transformation, track Agile Maturity and launch pilots. Agile Staffing Enterprises often need additional human resources to make the transition to Agile. Eliassen Group is positioned to staff your short and long-term needs with indepth Agile experience. 01 Advisory 04 Staffing 02 Training 03 Coaching Training Eliassen Group s Agile training Services give development teams, managers and the entire enterprise the tools to deliver business value faster. Coaching Moving to an Agile way of working requires a shift in mindset and practices on many levels. Eliassen coaches help organizations adopt and improve Agile methods and practices. 2

3 OBJECTIVES & AGENDA FOR THIS SESSION OBJECTIVES: Compliance and Agile overview from 70,000 feet Challenges with Compliance in an Agile environment Explore potential strategies for meeting Compliance challenges AGENDA: 1. Introduction (concepts and groundwork) 2. Rationale 3. Toolbox: Tips & Techniques 4. Close and Q&A First, a quick poll for experience of: - Agile? - Compliance? 3

4 1. Introduction AGILE RE-CAP, WHAT IS GRC? 4

5 SOME KEY ATTRIBUTES OF LEAN AGILE Small Increments Time-box Work Drive Value Self Organized x-functional Teams Continuous Improvement Make Work Visible Adaptive: Fast Feedback Loop Quality- TDD/Acceptance 5

6 WHAT IS GOVERNANCE, RISK & COMPLIANCE (GRC)? KEY ASPECTS: EXAMPLE SOURCES: IT Governance & Security Audit Enterprise Risk Management Operational Risk Mgt. Financial Controls Compliance Regulatory bodies Fed, DoD, EU, OSHA, FDA, data protection, National Govts. Finance Dodd Frank- CCAR, PCI,SOX, Basel Tech CMMI, ITIL, ISO, DoD, ITAR. PRINCE2, CSA CCM, COBIT 6

7 TRADITIONAL GRC DRIVERS & SOLUTIONS DRIVERS: Regulatory demands Risk Management Corporate & Business Governance SOLUTIONS: Lines of defense Automated Tools Specialist roles/groups Hierarchy: REG/LAW POLICY PROCESS RISK CONTROL Test Issue Action Plan 7

8 2. Rationale PROBLEM STATEMENT, SOLUTION ASSERTION, REALWORLD NEEDS 8

9 KEY CONTROL GROUP EXERCISE (OPTIONAL) 9 SCENARIO: You are the organization s Agile Lead, your 3 product development teams run bi-weekly iterations/sprints. Read the following Policy Statement: All use of COTS must be pre-approved by the CFO and CTO Select one of the following Control options and post your vote in the space provided: 1. Ensure that an approval task is inserted in the project plan at the point it is needed 2. Create a Story/Enabler and include in the reserved Technical stage of the Sprint 3. Wait until it becomes apparent that software is needed, conduct research and then seek approval while you wait We will revisit at close of session

10 PERCEIVED IMPEDIMENTS: SOME COMMON CHALLENGES AGILE CHALLENGES: Hybrid semi-agile Siloed implementations Struggles to align with nonagile organizational functions Gaming and manipulation of process Organizational politics Misaligned development of methods/processes GRC CHALLENGES: Bureaucracy prescribed and burdensome process Layers of decision makers/info handlers Misuse of external advisory capabilities Over reliance on tools for solutions Intra company boundaries and divergent standards 10

11 COMPLIANCE VS. AGILE GRC requires varying degrees of significant effort to maintain and demonstrate control Adoption of Agile requires a shift in emphasis towards fast iterations and incremental delivery of value let s get out the blender! Our assertion is that this need not be the case, Agile can co-exist with, and support, GRC 11

12 3. Toolbox: Tips & Techniques SOLUTION STRATEGY & APPROACHES 12

13 MEETING THE CHALLENGE CASE STUDIES Our proposed solutions are based on four client case-studies: Defense Contractor Utilizing Scrum while complying with Capability Maturity Model Integration (CMMI) Major Financial Services Corporation Employing Lean Agile and demonstrating controls to audit Management Consulting Company Transitioning to Kanban while complying with IT Policies Medical Equipment Company Using Scrum and Kanban while undergoing continuous FDA and ISO audits 13

14 THE ROLE OF THE QUALITY MANAGEMENT SYSTEM Module Overview DEVELOPMENT & OPS PROCESS QMS COMPLIANCE REQUIREMENTS An organization s Quality Management System (QMS) contains their delivery process and supporting artifacts It can demonstrate that compliance needs are met by integrating them as Enablers (or NFRs) PRODUCT NEEDS & REQUIREMENTS 14

15 2 LEVELS TO MEETING THE CHALLENGE LEVEL 1: USE STANDARD AGILE ENABLERS Let s organize our QMS based solutions into Two levels : LEVEL 1: USE STANDARD AGILE ENABLERS Embed and align with traditional agile approach- i.e. backlog stories that demo/test compliance (NFRS), demos and retros integrate compliance tests/checks etc. But if/when that s not sufficient: LEVEL 2: AUGMENT GRC PRACTICES Additional (more robust) steps such as those explored under the next 4 practices 15 LEVEL 2: AUGMENT GRC PRACTICES

16 LEVEL 1: USE STANDARD AGILE NFRS ENABLERS COMPLIANCE FRAME OF REF: - REGULATIONS - STANDARD - MODEL - AUDIT SCHEDULE NFRS COMPLIANCE BACKLOG ENABLERS PRODUCT BACKLOG COMPLIANCE NEEDS & REQUIREMENTS REFINED/GROOMED INTO ENABLER/STORIES ENABLERS/STORIES INCLUDED IN PLANNING Now, let s look at Level 2 in more detail 16

17 LEVEL 2: MAPPING TO STANDARDS/REGULATORY/POLICY Establish a Compliance Traceability Matrix (CTM) Maps required compliance elements to supporting roles, practices and artifacts Maintained and monitored by Process Quality Assurance (PMO) Align with process change management cycle 17

18 LEVEL 2: PMO TMO/CMO Typically three possible functional elements to a traditional PMO: Program Management Office Potential opportunities: Extend to encompass a: Transformation Management Office (TMO) Compliance Management Office (CMO) Strategic Planning & Tracking Process Project Support Establish and manage a CM Cycle Enable (train/coach) teams Manage the Agile roadmap and manage Agile tools Develop solutions that support Mapping Track & Report on Controls 18

19 LEVEL 2: ASSESSMENT DRIVEN AGILE TRANSFORMATION Assess Educate & Pilot Sustain CONTINUAL CYCLE The assessment is an empirical, objective measure of agile maturity at the individual, team, organization and enterprise level. The need for an assessment cannot be understated. This key step informs all of the work that will be done to create a high performing product development organization. Stage Scale 19

20 LEVEL 2: ESTABLISH AN AGILE LIFE CYCLE (ALC) Attributes of an effective generic Life Cycle (LC): Acts as a common frame of reference - role/function based Built by, and for, practitioners in QMS Flexible and allows controlled tailoring Potential opportunities for an ALC in QMS: Support the Compliance Map/Matrix Agile training and playbook Platform for driving/communicating improvements 20

21 AUGMENTED (L2) SOLUTIONS RE-CAP Coach Teams Manage Roadmap Establish Roles & Practices Pilot & Improve Compliant Agile Practices Traceability Matrix ii. TMO/CMO Track & Report L2 COMPLIANCE STRATEGY Train & Communicate- Constantly! iv. AGILE LIFE CYCLE Managed by PQA/PMO i. MAPPING iii. ASSESSMENT Engage Stakeholders Basis for Improvement Validate with SMEs Include in CM Cycle Baseline Measure Maturity Align with Matrix Validate Compliance 21

22 4. Closing and Q&A CLOSE OUT 22

23 KEY CONTROL EXERCISE - REVISITED Policy Statement: All use of COTS must be pre-approved by the CFO and CTO Which one of the following Control options did you vote for? 1. Ensure that an approval task is inserted in the project plan at the point it is needed 2. Create a Story/Enabler and include in the reserved Technical stage of the Sprint 3. Wait until it becomes apparent that software is needed, conduct research and then seek approval while you wait 23

24 RECAP AND Q&A So, during this session we briefly covered: The GRC imperative Relevant facets of Agile Techniques - Level 1 (standard agile) & Level 2 (augmented) Let s quickly address any remaining questions 24

25 APPENDIX AGILE GLOSSARY 25

26 SAY IT IN AGILE! Agile an adjective that describes anything that supports the values and principles of the Agile Manifesto. Agile Manifesto the Agile values and principles as agreed upon by the signatories in Backlog a list of user stories ordered in descending business value order. Burn-up chart a chart that is updated daily with the accumulated story points associated with done stories that shows progress towards the iteration goal. Co-location the practice of locating all or most of the members of an Agile team together, ideally in a shared team environment. Continuous Integration (CI) the practice of merging in changes, fully integrating the product, building it, and testing it as frequently as possible and preferably as a part of every check-in. Cross functional team a team that has all of the skills to perform the work it pulls in for an iteration. 26

27 SAY IT IN AGILE! Cycle time the time it takes from the initial formation of a business idea until it is available in the market. Daily Standup (DSU) synonym for stand-up meeting. Definition of Done specific criteria that need to be met for a user story to be considered done. Definition of Ready specific entrance criteria that need to be met for a user story to be considered ready for a team to start working on it. It is an agreement between the product owner and the team. Epic a large chunk of value which typically breaks down into many user stories. Holistic testing - having most test cases associated with individual user stories, driving the tests as close to the actual code as possible, and having all those involved in testing the story (developers and QA) coordinate in order to maximize coverage and minimize duplication of effort. 27

28 SAY IT IN AGILE! I.N.V.E.S.T. acronym created by Bill Wake describing one set of criteria for a good user story: independent, negotiable, valuable, estimable, small, testable. Iterations regular intervals of time, from 1-4 weeks, in which the team produces a deliverable increment of work. Iteration/Sprint Planning Meeting a planning meeting at the start of an iteration in which the team works with the product owner to plan an iteration worth of work. Minimum Viable Product (MVP) the epics and/or user stories associated with developing a product which has just enough value to be worth the effort of delivering it; no more and no less. Planning Poker an Agile estimation technique that leverages the wisdom of the whole team. Product Owner a product management role within the Scrum framework. Scrum an Agile framework co-created by Ken Schwaber and Jeff Sutherland. Scrum Master a servant leader that serves as the steward of the Scrum framework and facilitates the removal of impediments. 28

29 SAY IT IN AGILE! Self-organizing team an Agile team which, given an iteration worth of ready work, is able to produce a deliverable increment of work entirely on their own. Sprint the Scrum term for Iteration. Story points a unit of measure referring to the relative level of effort associated with completing a user story. Test Driven Development (TDD) the practice of writing automated tests for a story first, making sure they all fail, and then writing just enough code to get the tests to pass one by one. A common related practice is called red-green-refactor which includes doing any refactoring that is indicated. User Story a description in language that the end user can understand that includes who the story is for, what is needed, and why it is needed. Velocity the number of story points associated with done stories over a given period of time, usually one iteration. Working agreement a document created by an Agile team for the Agile team that describes a set of rules that the whole team agrees to abide by. The document is generally posted in the team room for all to see. Including the scrum master, product owner, and any managers of the team in the agreement is a good idea. 29