For IBM i Environments

Agile Application Lifecycle Management

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

Hot Topics

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

CM First Group

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

What is agile ALM?

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

ALM Disciplines

9

Discipline Tool

Modeling CA Plex / 2E

Design CA Plex / 2E

Issue and defect tracking CM MatchPoint ALM

Change and Configuration Mgmt. CM MatchPoint ALM / CA Plex / CA 2E

Release Management CM MatchPoint ALM

Production Monitoring CA Wily

Tests and Verification CM MatchPoint ALM / Worksoft Certify

Reporting CM MatchPoint ALM

Tracability CM MatchPoint ALM

Policies CM MatchPoint ALM / CA Plex / 2E

Automation CM MatchPoint ALM / CA Plex / 2E

Collaboration CM MatchPoint ALM / CA Plex / 2E

What is agile ALM

What is Agile? - History

History of Agile

Manifesto for Agile Software Development

We are uncovering better ways of developingsoftware 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/

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

Agile vs. Waterfall

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

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

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

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

Recommendations

• Reduce Iteration Duration• Long iterations limit feed back, resulting in:

• -Delivering the wrong functionality• -Delivering too much functionality• -Schedule risk

Recommendations

Agile vs. Architected

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

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.

Agile vs. Architected

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

Agile vs. Architected

• Avoid Speculative Development• Just in time development• YAGNI and KISS• Plan for extensions• Doe not code extensions until needed

Agile vs. Architected

SCRUM

SCRUM

SCRUM

• Scrum is..• Lightweight• Simple to understand• Extremely difficult to master

• 3 Pillars of Scrum• Transparency• Inspection• Adaption

SCRUM Overview

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

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

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

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

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

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!

Difficulties adopting Agile

• Organizational Structure / disruptive• Management Support• New to most team members• Scrum but

Benefits of agile ALM

• Higher Productivity• Higher Quality

ALM Tooling for IBM i

INFORMATIONENGINEERING> Data Modeling

> Model-Based Development

> Code Generation

ArchitectedRapid Application

Development(ARAD)

OBJECTORIENTATION> Patterns

> Reuse

> Inheritance

Architected RAD with CA Plex

CA Plex - Single Model/Code Base

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

CM MatchPoint ALM

CM MatchPoint Deployment

Manage complex multiplatform deployments

DEV INTEG PROD

• Detect changes/conflicts• Check for conflicts• Create releases/builds• Manage source code• Scheduled deployments• ….

CM MatchPoint Agile

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

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

Questions

christoph.heinrich@cmfirstgroup.com