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

2. 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

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

4. 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

5. 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

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

7. 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

8. 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

9. 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

10. 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

11. 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

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

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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

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

23. 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

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