sithh16 - the implications of becoming agile

The Implications of Becoming Agile

Markus Theilen SAP Inside Track Hamburg 11.06.2016

Disclaimer• Everything that is stated in the following slides is

my personal point of view and is in no ways an official statement of EWE.

• This document is provided without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. EWE assumes no responsibility for content of this document.

Who is this guy?• Working with SAP stuff for 15 years • Student => Developer =>

Software Architect => IT Coordinator => Enterprise IT Architect

• SAP Mentor • Helped to transform a waterfall-oriented

IT department into an agile organization between 2012 and 2015 (still ongoing)

Today’s Mission for me• Tell you about an agile transformation in a SAP-

based development environment

• Show you that there are more changes then stickers on the wall and people standing in front of them

• And to convince you that it is still worth the effort!

=>

Agenda

• The Environment

• Testing

• Software Architecture

• People

The Environment

easy+• Utility Customer Information System for ~2000 users,

maintained by around 50 developers and 150 other people

• 13.4 Mio. lines of code (non-standard)

• 20 year old code base

• Colorfull mix of frameworks from different generations

• Since 3 years transitioning from waterfall to Scrum

• From half-yearly releases to weekly shipments

Main Principles of Agile • "Use a honest way to deal with uncertainty"

• How to do this?

• => Take small, safe steps (you won't regret)!

• => Get feedback as early and often as possible!

• => Learn from feedback!

Feedback is the Driver• A Review is one of the most

important meetings in Scrum, because you get feedback for your work

• This feedback will let you learn about the next steps

• Even better feedback comes from users using software in production mode.

• SO GET YOUR STUFF OUT!

Breakout: Self-Quantified Software

• We have a lot of possibilities to analyze tons of log files and event streams.

• Why not use this power to get feedback about how our software is used in production?

Testing

Release Often =>Test Often

• More releases per year lead to more testing per year

• Test automation is key!

• Unit tests are great, but automated functional regression tests are a must

• Strive for about 50-60% test coverage

• Even 20% is ok if this represents 80% of daily business

TestDevelopment

Changing Testing changed System Landscape

DEV QA PROD

DEV QA1 PRODQA2

Automated Tests here!

Software Architecture

Software Architecture needs to change for testability

• Changes in one module should have no ripple effects

• So it is all about independency and abstraction

• Small refactoring steps at a constant pace are needed to break up a monolith

People

The Impact on people• New skills are needed out of a sudden

• Test Automation, Servant Leaders, visionary Business Analysts

• Developers are urged to think before code and adopt Agile Software Engineering (TDD, Pair Programming, Refactoring,...)

• Responsibility moves from "Master Mind" to team, also for production system

• Not everyone is happy with transparency.

Breakout: Modern Practices in ABAP?

• Continuous Delivery: TMS

• Continuous Integration: BAdIs for TMS to start automated tests

• DevOps: ST03, SM66, EWA, SE80

• Test Automation: eCATT

• Unit Tests: AUnit

• The possibilities are there and excuses are gone.

Change Organizations by Changing People

• Restructuring or refactoring an organization can not be done by mailing a PDF or PowerPoint file!

• Organizational changes take a lot of time and communication skills

• To too big task for few people

• So find people with the right mindset and grow them like plants (sun = attention from others and wate = time, money)

Is it worth it?Indeed. People satisfaction, speed of delivery,

development expenses

Honeypot here!

"Nothing worth having comes without some kind of fight"

Bruce Cockburn in "Lovers in Dangerous Times"

Thank you for your staying power!

Any questions? Contact: @therealtier

Best Feedback comes from Real Live

• One can disappear in the garage, doing hard work for months and find out on release day that what was build is not what the user said would be needed.

• Or one can put small, but working releases on production system and learn from real users doing real stuff and over time discover together what the user needs now