agile in a huge-waterfall company wisang eom. who am i? working for lg electronics, korea – role:...
TRANSCRIPT
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!