Slides from my talk about the not so obvious changes that occur when change from waterfall to agile software development with Scrum. A review on the past three years in an agile transition.

1. The Implications of
Becoming Agile
Markus Theilen
SAP Inside Track Hamburg 11.06.2016

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

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

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

5. Agenda
• The Environment
• Testing
• Software Architecture
• People

6. The Environment

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

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

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

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

11. Testing

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

13. TestDevelopment
Changing Testing changed
System Landscape
DEV QA PROD
DEV QA1 PRODQA2
Automated
Tests here!

14. Software Architecture

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

16. People

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

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

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

20. Is it worth it?
Indeed. People satisfaction, speed of delivery,
development expenses
Honeypot
here!

21. "Nothing worth
having comes
without some
kind of fight"
Bruce Cockburn in "Lovers
in Dangerous Times"

22. Thank you for your
staying power!
Any questions?
Contact: @therealtier

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