1. For IBM i Environments Agile Application Lifecycle Management

2. Speaker Bio Christoph Heinrich, Founder and CEO CM First Group Swiss, moved to SLC in 1998 and again in 2011 Developer on IBM i since 1991 CA 2E (Synon) and CA Plex (Obsydian) Software Change Management and Application Lifecycle Management CM MatchPoint ALM

3. Hot Topics

4. Agenda CM First Company Overview What is agile ALM Agile vs. Waterfall Agile vs. Architected Scrum Overview Difficulties and Benefits of adopting Agile Further Information Q&A

5. CM First Group

6. Headquarter in Switzerland Offices in USA, Italy, France 35 Employees > 400 Customers Products CM WebClient – Web and Mobile Applications with CA Plex CM MatchPoint - Application Lifecycle Manager CM Meta Analytics – Source Code Comprehension CM Power – PHP Framework for IBM i CA 2E – Application Development Platform for IBM i CA Plex – Modelbased Multiplatform Development Platform Worksoft Certify – Automated Testing Databorough X-Analysis – Source Code Analysis and Documentation Sencha / Sencha Touch

7. What is agile ALM?

8. What is ALM Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management WIKIPEDIA

9. ALM Disciplines 9 DisciplineTool ModelingCA Plex / 2E DesignCA Plex / 2E Issue and defect trackingCM MatchPoint ALM Change and Configuration Mgmt.CM MatchPoint ALM / CA Plex / CA 2E Release ManagementCM MatchPoint ALM Production MonitoringCA Wily Tests and VerificationCM MatchPoint ALM / Worksoft Certify ReportingCM MatchPoint ALM TracabilityCM MatchPoint ALM PoliciesCM MatchPoint ALM / CA Plex / 2E AutomationCM MatchPoint ALM / CA Plex / 2E CollaborationCM MatchPoint ALM / CA Plex / 2E

10. What is agile ALM

11. What is Agile? - History

12. History of Agile Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/

13. Definition of Agile A definition of Agile: You accept input from reality and you respond to it (Kent Beck) Twelve Principles of Agile Software Scrum Transparency Inspection Adaption Agile ALM Collaboration Integration Automation Continuous Improvement

14. Agile vs. Waterfall

15. Waterfall is… Still No. 1 The most-popular development methodology A logical approach that is partly responsible for the greatest number of large, successful projects Proven "Tried and true Suitable for projects (e.g., fixed-bid contracts) in which vast majority of requirements must be defined early if add/change is clear

16. Agile vs. Waterfall But Waterfall is also…. Frustrating management overhead Value is indirect and not often apparent to team members Risky Prone to dead on arrival and long tail projects Slow Not suitable for short duration projects Difficult to track Metrics are subjective and reluctance to reveal problems create a tendency to fail late in the cycle

17. Agile vs. Waterfall Agile is…. Quick Can handle projects as short as a couple of weeks Iterative Agile is built around a constant feedback loop Continuous Agile focuses on continuous integration, test and deployment Verifiable With a definition of done that is transparent and verifiable, project progress is quickly apparent

18. Agile vs. Waterfall But Agile is also… Not a silver bullet Agile exposes problems early, but does not solve all of them Disruptive Agile requires significant changes to culture, governance and IT's interactions with the rest of organization Less mature Over a dozen years old, but new to many organizations Harder to outsource Does not fit fixed bid contract model

19. Recommendations Reduce Iteration Duration Long iterations limit feed back, resulting in: -Delivering the wrong functionality -Delivering too much functionality -Schedule risk

20. Recommendations

21. Agile vs. Architected

22. Locking in Ignorance The beginning of a project is the moment when a team has the least knowledge of the domain they will ever have. This is the moment when they invent the most naive models they will ever invent. Upfront modeling locks in the team's initial ignorance." Eric Evans, Domain Language

23. Agile vs. Architected Most agile methodologies have no architect role. Overreaction to "big design upfront": -Requirements change quickly -The problem and solution are not well known upfront "Ivory Tower" architects did not know how code actually worked.

24. Agile vs. Architected

25. Agile Architecture Meets the current need Functional Non-Functional Simple Expect your architecture to evolve SOA Encapsulation Loose Coupling Separation of Concerns

26. Agile vs. Architected Avoid Speculative Development Just in time development YAGNI and KISS Plan for extensions Doe not code extensions until needed

27. Agile vs. Architected

28. SCRUM

30. Scrum is.. Lightweight Simple to understand Extremely difficult to master 3 Pillars of Scrum Transparency Inspection Adaption

31. SCRUM Overview

32. SCRUM Artifacts Product Backlog Ordered Items at the top are more granular than items at the bottom Maintained/re-ordered during the Backlog Grooming effort by Product Owner Sprint Backlog Committed items negotiated between team and Product Owner in Sprint Planning Meeting Scope commitment is fixed during Sprint execution Increment Sum of all Product Backlog items completed during a Sprint and all previous Sprints which produce a new increment that must be Done Usable condition regardless of Product Owner readiness to release it

33. SCRUM Roles Product Owner Responsible for maximizing the value of the Product and the work of the Dev team. Responsible for managing the Product Backlog Scrum Master Responsible for ensuring Scrum is understood and enacted Servant-leader for Scrum team Development Team Cross-functional team who produce a potentially releasable increment of Done at the end of each sprint Only members of this team create the increment

34. SCRUM Rules Definition of Done When a Product Backlog Item or Increment is described as Done, everyone needs a common understanding Shared understanding is the key as this definition drives the amount of Product Backlog Items the team can select during a Sprint Increments are usable; Product Owner may choose to immediately release it

35. SCRUM Events / 1 Sprint Time boxed at 4 weeks or less in which a Done, usable, and potentially releasable increment is created Consistent duration and are continuous Sprint Planning Meeting Time boxed at 8 hours for a 4 week Sprint Plans the work to be performed in the Sprint Two parts: 1) What will be delivered, 2) How will it be delivered Daily Scrum Time boxed at 15 minutes/day Finished, going to finish, obstacles/impediments today

36. SCRUM Events / 2 Sprint Review Time boxed at 4 hours for a 4 week Sprint Inspect the increment/Adapt the backlog Elicit feedback and foster collaboration Sprint Retrospective Time boxed at 3 hours for a 4 week Sprint Team self-inspection and creation of a plan for improving execution

37. SCRUM – Summarization Scrum uses time boxed techniques built upon an empirical approach (transparency, inspection, adaption) to cycle through Loading/Prioritizing Planning Execution Review Retrospection Time Boxed mini life cycles Huge risk mitigation Great opportunity for efficiency realization Enables a sustainable ecosystem Emphasis on communication, collaboration, functioning software and flexibility to adapt = more competitive!

38. Difficulties adopting Agile Organizational Structure / disruptive Management Support New to most team members Scrum but

39. Benefits of agile ALM Higher Productivity Higher Quality

40. ALM Tooling for IBM i

41. INFORMATION ENGINEERING >Data Modeling >Model-Based Development >Code Generation Architected Rapid Application Development (ARAD) OBJECT ORIENTATION >Patterns >Reuse >Inheritance Architected RAD with CA Plex Page based on Title Only from Slide Layout palette. Design is cacorp 2006.

42. CA Plex - Single Model/Code Base

43. CA Plex - Multi-Platform Code Generation WPF (7.0) WCF Multi-Tier Servers MFC C++ Java Plex C# Plex RPG IV or any i5/OS programs Plex Java

44. CM MatchPoint ALM

45. CM MatchPoint Deployment Manage complex multiplatform deployments DEVINTEG PROD Detect changes/conflicts Check for conflicts Create releases/builds Manage source code Scheduled deployments ….

46. CM MatchPoint Agile CM MatchPoint Agile supports agile ALM Collaboration between team Central documentation and information Seamless handover Automated deployment

47. Further reading www.scrum.org http://agilemanifesto.org/ http://www.manning.com/huettermann/ www.cmfirstgroup.com

48. Questions christoph.heinrich@cmfirstgroup.com