agile in a huge-waterfall company wisang eom. who am i? working for lg electronics, korea – role:...

Agile in a Huge-Waterfall company

Wisang Eom

Who am I?

• Working for LG Electronics, Korea

– Role: Agile coach & Trainer

– Main Activities: TDD, Refactoring, Pair programming

• Hobby

– Translation : Translate Agile books and publish Korean edition

What I like the most: XP

● If something is good, do it to the extreme

○ If code review is good, why not do it all the time?

■ Pair programming

● If walking is good for your health, then why not walk all the time?

○ Extreme Coding & Walking

■ https://www.youtube.com/watch?v=JWm4NnpCGgM&feature=youtube_gdata_player

■ http://www.lgblog.co.kr/frnt/postView.dev?ctgrid=8&post_id=688

■ http://news.mk.co.kr/newsRead.php?year=2014&no=1015884

What I like the most: XP

● If something is good, do it to the extreme

○ If code review is good, why not do it all the time?

■ Pair programming

● If walking is good for your health, then why not walk all the time?

○ Extreme Coding & Walking

■ https://www.youtube.com/watch?v=JWm4NnpCGgM&feature=youtube_gdata_player

■ http://www.lgblog.co.kr/frnt/postView.dev?ctgrid=8&post_id=688

■ http://news.mk.co.kr/newsRead.php?year=2014&no=1015884

Our Products

Work flow of typical Electronics Company

● Waterfall is natural : HW is hard to change later.o Board design -> Evaluation Board -> PCB v0.9 -> 1.0 -> ...

Traditional SW Development in Electronics company

Spec. freeze

Strict change controlAnalysis

Milestone 1 Milestone 2 ...

Waterfall in Detail

Expectations for Scrum

“Productivity 5-10 times industry average has been observed in many Scrums since 1993.”

- Jeff Sutherland

Is it true in your company?

What happens frequently is …

“Unfortunately, many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them”

- Ken Schwaber

What makes it hard to apply Agile?

1. Working in the Trenches

2. Waterfall Assumption

4. HR Policies

5. Systems & Tools

6. Legacy Code

7. Silver Bullet Illusion

8. But Syndrome

Training room vs. Trenches

Waterfall Assumption

1. Milestone

2. Mini Waterfall

3. Org. Chart == Software Structure

Dept. 1

Team 1-1 Team 1-2 Team 1-3

Comp.1

1-1 1-2 1-3

HR Policy

● Shared responsibility, but how about evaluation? Shared evaluation?

● Bonus or Incentives

● Roles!

Systems & Tools

Legacy Code

● 2,000 lines method.

● Code disappeared when scrolling down.

● Ugly but it works!

Silver Bullet Illusion

But Syndrome!

1. ScrumBut

2. UnitTestBut

3. RefactoringBut

4. CodeReviewBut

5. C.I. But

Unit Test But

• We do unit test but …

-check coverage but have no many asserts.

-don’t refactor test code.

-don’t update test code but ignore when req. changed.

-don’t improve the production code

Refactoring But

• We do refactoring but …

- It’s done by special team, not us.

- don’t care qualitative aspects but cares index only

: Cyclomatic complexity < Criteria

C.I. But

• We do C.I. but …

- It is maintained by a special team, not us.

- we can’t change other’s code

- no many tests and not maintained

Starting Improvement from the Trenches

● Use the strength of the opponent

● Backward Approach(end -> start)

● Attracting developers: Technically Sexy!

● Spread out slowly

SPI org?

● Responsible for company-wide standard

process & Tool

● Generally, Agile guys are enemy to them

● Can report to Top management directly

● Can make promotion easily

● Can do company-wide measurement, or

auditing easily

Backward Approach

● Product Backlog -> Sprint Planning -> Daily Scrum -> Sprint Review -> Retrospective

● Retrospective - Sprint Planning: DoD, Task Size, ... - Backlog Clarification & Refinement - C.I: Auto Build, Test Automation

* Invite SPI guys to Sprint review and Retrospective. They will be shocked!

First Step

Sprint Review

Critical issue detection

● How much simultaneous is

simultaneous?

● How much horizontal is

horizontal?

● How much swipe is enough?

What Scrum itself can and can’t

● Scrum cano Make things visible, help people see it and learn

from it

● Scrum can’to Make people see it

o Make people learn

o Make people improve

o Make people improve their technical capability

How to motivate developers?

● Engineers like cutting-edge technology

● They also like fancy technical practices

● Show them they can sharpen their technical excellence

by doing something Agile without telling them it is Agile

practices.

How to motivate developers?

● Engineers like new technology

o Hot topics like Hadoop, Docker, …

o Design Principles / Design Patterns

o Fancy topics: Fake, Mock, …

o Technically Sexy!

● Turn something very hard for them into very easy one.

But Syndrome!

1. ScrumBut

2. UnitTestBut

3. RefactoringBut

4. CodeReviewBut

5. C.I. But

Trivial is not trivial

Make it testable

Test Case

1. Given that it is in washing

2. When expected signal comes n times in a row

3. Then we should say it is locked.

4. Given that it is in washing

5. When expected signal comes n-m times in a row, other

signals several times and expected signal m times

6. Then we should say it is not locked.

Test code

TEST(SignalCheck, NotLockedIfSignalNotInARow)

{

SignalGenerator_GenerateExpectedSignal(n-m);

SignalGenerator_GenerateOtherSignal(3);

SignalGenerator_GenerateExpectedSignal(m);

CHECK_FALSE(isLocked(timer_500us_wrapper,

check_signal_count));

}

Smart phone application

What makes everything hard?

Test case

1. Given that a man of height 174cm and weight of 72 kg

2. When he runs around Marina Bay Sands for an hour

3. Then it shows the track record and energy consumption

of 105 KCal.

Let’s Run the Test

How to avoid RefactoringBut

1.Funny Metric: CodeFat

2.Make them exposed to good code

3.Make it fun to code and refactor

Google TOTT

LG TOTT

Conclusion

1. Reality is tough!2. Many excuses, Hard to change.3. Use the strength of the opponent.4. Once started, it gets accelerated5. Avoid But syndrome6. Culture first, practice later7. “Fun” is important!

* Still long way to go, Probably endless!