Agile Application Lifecycle Management

1. Agile Application Lifecycle Management For IBM i Environments

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. CM First Group • 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

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. Agile vs. Waterfall • 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. Agile vs. Architected 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 vs. Architected • 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

29. SCRUM

30. SCRUM • 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. Architected RAD with CA Plex Page based on Title Only from Slide Layout palette. Design is cacorp 2006. • INFORMATION • ENGINEERING • Data Modeling • Model-Based Development • Code Generation • OBJECT • ORIENTATION • Patterns • Reuse • Inheritance ArchitectedRapid ApplicationDevelopment(ARAD)

42. CA Plex - Single Model/Code Base

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

44. CM MatchPoint ALM

45. CM MatchPoint Deployment Manage complex multiplatform deployments PROD DEV INTEG • 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