Developing Maximum Value Paul Berryman 2016 Agile Down-to-Earth © 2016 Agile Down-to-Earth – All rights reserved

Developing maximum value Some keys to getting maximum effectiveness from your development teams Empower Agility (SCRUM, XP, Lean) Embed Quality (DevOps, the Shift Left) Architect for Efficiency (Code re-use, Design patterns) © 2016 Agile Down-to-Earth – All rights reserved

Empowering Agility © 2016 Agile Down-to-Earth – All rights reserved

Empower Agility SCRUM, XP and Lean Agile All Projects hold fast to these principles: Business owns vision – must have an empowered Product Owner Support them with a qualified Vision team – SMEs, UX, Tech Leads, Architects Small Batches – Continuous Feedback Always deliver the Minimally Viable Product (MVP) Deliver in 6 month increments (maximum) Fully define the release before beginning to Sprint 80% of User Story details in place Prioritize and Estimate all User Stories © 2016 Agile Down-to-Earth – All rights reserved

Note: The importance of small batches Nothing is particularly hard if you divide it into small jobs. Henry Ford © 2016 Agile Down-to-Earth – All rights reserved

DevOps & the Shift Left © 2016 Agile Down-to-Earth – All rights reserved

What is DevOps? From Gartner Group: “DevOps is a perspective that requires cultural change, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of an integrated approach. DevOps emphasizes people and culture to improve collaboration between development and operations groups as well as other IT stakeholders such as architecture and information security. DevOps implementations utilize technology, especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective” © 2016 Agile Down-to-Earth – All rights reserved

Devops & 14 levels of Quality Test Level Test Target Environment Accountable Owner / Participants 1 Quality Req’s Creation & Verification Before development begins Product Owner 2 Unit Testing IDE Dev 3 Peer Code Review (pre-commit) 4 Over the shoulder Testing QA / Dev 5 Static Code Review 6 Tech Lead Code Review (Post commit) Development / Sys Int 7 Continuous Code Integration Testing ISG / Dev 8 Functional Testing System Integration QA 9 Story Acceptance Testing 10 Regression Testing 11 End-to-End Testing / Performance testing Staging 12 User Acceptance Testing UAT Product Owner / End Users 13 App Scan Pre-Production Tech Lead 14 Quality Code Deployment & Verification Production Ops / Dev © 2016 Agile Down-to-Earth – All rights reserved

Shift Left – in the IDE (the individual development environment) Defect detection and prevention in the IDE TDD, etc. – Create Unit Test before Code is written (NUnit, QUnit, Junit, etc. ) Test code branch (snapshot) in the IDE Local Static Code Analysis (SCA) Peer code review in the IDE (pre-commit) before Check-In QA Over-the-Shoulder Testing (OTS) Check-out Branch Write Unit Test Code solution Run Unit Test Run SCA Peer Review OTS Check-in Branch Within the IDE © 2016 Agile Down-to-Earth – All rights reserved

Continuous Integration / Continuous Deployment Use your ‘DevOps’ infrastructure to build your Integration base Build from head – or snapshot build No code is to be deployed to Integration if defects are found C.I. integration engine controls process and error reporting Build automation (build-once) Release automation (deployment testing) All executables in one Binary repository (build-once/deploy many) © 2016 Agile Down-to-Earth – All rights reserved

Test automation Use your ‘DevOps’ infrastructure to discover pre-prod defects automatically Part of the CI/CD stack Tech Lead code review (optional) Unit Test automation (using all developers JUnit/QUnit/NUnit) Regression Test automation (developers Unit Tests + other tools) Static Code Analysis (ex. Security rules enforcement) © 2016 Agile Down-to-Earth – All rights reserved

Sample DevOps Infrastructure © 2016 Agile Down-to-Earth – All rights reserved

Architect for Efficiency © 2016 Agile Down-to-Earth – All rights reserved

Architecting for Success learn from others – do not ‘start from scratch’ Code Component Catalog Architectural Design Patterns Static Code Analysis rules Peer Code Reviews Technical Design Reviews Defect tracking Usability Design © 2016 Agile Down-to-Earth – All rights reserved

Code Component Catalog Code components should be stored for future re-use Source code ‘component’ is stored and tagged Component candidates are ‘approved’ and ‘sanitized’ Comments in components are very important Tag with databases/systems; purpose; language; etc. Catalog must be searchable by tag and by text string Important: Vendors should be required to use the catalog and copy from there before writing from scratch; and prove that the catalog has nothing they can use before writing custom code ‘from scratch’ © 2016 Agile Down-to-Earth – All rights reserved

Design Patterns Certain common code/services should follow a formal “Design Pattern” Establish patterns for typical services How to read database; how to update record repository; how to retrieve customer ID; how to store to price updates, etc. Design patterns should have an ‘ID’ Recommend ‘Patterns of Enterprise Application Architecture’ by Martin Fowler Important: Vendors should be required to follow design patterns and to prove that design patterns were followed © 2016 Agile Down-to-Earth – All rights reserved

Static code analysis Some code quality can be enforced with Static Code Analysis (SCA) tools Security practices should be enforced with SCA Full code repository should be scanned regularly (daily) Code findings are scaled – all ‘important/urgent’ should be remediated immediately SCA tools can be customized to enforce rules that are unique to certain systems – tech lead will ‘own’ rules Note: Most SCA tools have so many rules already available that you will have to select a sub-set Most legacy systems will need to be remediated over time or given exceptions when implementing a new SCA tool © 2016 Agile Down-to-Earth – All rights reserved

Peer code reviews All code should be reviewed by a ‘peer’ before being checked-in Code reviews can be automated to prevent check-in until peer ‘approves’ code Peer ID is saved with code snippet to allow for continuous improvement is code has high defect rates Peer code review should be done in ‘real’ time rather than being added to a ‘to do’ queue Good technique for enforcing code quality at a vendor, as the peer will be ‘on the hook’ for code quality © 2016 Agile Down-to-Earth – All rights reserved

Tech lead design review recommended for code that is developed by vendor teams All code is reviewed by an Tech Lead after check-in but before promotion to system integration environment Code reviews can be automated to prevent promotion until Tech Lead ‘approves’ code Code is sent or put in a ‘to do’ queue for Tech Lead to review ASAP Tech lead looking for best practices – not detailed code approval Especially important with new vendor or new system © 2016 Agile Down-to-Earth – All rights reserved

Defect tracking Map your defects and source code to track defect rate by system or programmer Track changes in defect rate (rather than trying to track each individual defect) Use for ‘continuous improvement’ retrospectives – NOT to punish (Agile has proven that this is counter productive) Be sure to tag code with User Story ID, programmer, peer reviewer, system, and even expected release date Track defect rates pre-prod in addition to prod rates to gain a better view of practice standards effectiveness © 2016 Agile Down-to-Earth – All rights reserved

Usability Design Design and Usability should refer to industry standards Common Industry Specification for Usability – Requirements UX design should be discussed before coding is begun © 2016 Agile Down-to-Earth – All rights reserved

Appendix © 2016 Agile Down-to-Earth – All rights reserved

Quality Steps by Development Stage and Role Early Defect Discovery/Testing (Shift Left) Dev System Integration QA Staging/UAT Delivery IDE Focus (Shift Left) TDD - Unit Testing; Peer Code Review; Static Code Analysis; Snapshot builds; Code Quality review Delivery Continuous integration; Build Manager; SI oversight; Zero defect policy Delivery QA Defects automatically sent to development team; Zero defect policy Delivery UAT Defects automatically sent to development team; Zero defect policy QA Over-the-Shoulder testing; Nightly SCARC Rules Analysis QA Automated Unit / Functional Testing; Zero defect enforcement QA Automated Regression Testing; Zero defect enforcement QA UAT Defect Tracking; Zero Defect enforcement; E2E testing Operations Continuous Integration Builds; Automated SCARC Enforcement; Release Candidate certification (Build once) Operations Automated Gold Source deployment to QA Operations Automated Gold Source deployment to Staging/UAT Operations Automated Gold Source deployment to Prod Continuous Integration/Continuous Deployment © 2016 Agile Down-to-Earth – All rights reserved

Thank You © 2016 Agile Down-to-Earth – All rights reserved