1. How Not to do Agile:
A Practitioner’s view in sharing
lessons learnt
Freddie Quek, 29 May 2014
Agile Evangelist No. 22, Park Plaza County Hall

2. About Me
Partnering external
third party with a
large technology
integration
component
Responding to
urgent competitive
threats
Execution of an
acquisition due
diligence
Completion of
large high profile
customer
engagement
Freddie Quek, Director of Strategic Initiatives, Pan Wiley
http://www.linkedin.com/in/freddiequek freddie.quek@wiley.com
Joined Wiley in 2006, responsible for Wiley’s largest web application
2010, launched Wiley Online Library
2013, charged with establishment of new organizational capability
2014, pan Wiley focus
Strategic Initiatives Team

3. History with using Agile
1999
Daily stand ups, iterative development – Teams of 2-6
2005
Led first Agile team at Elsevier – Team of 10
2009
Led large scale implementation of Agile for Wiley’s largest application
development – Team of 150
2011
Running 10 agile “project” teams
2012
Led Agile team to achieve Mission Impossible

4. About Wiley
• One of the oldest and largest global publishers
• World’s largest society publisher
• 5000+ employees
• US$1.8B revenue
Professional Development
25%
Global
Research
58%
Global Education
17%
2013 REVENUE
By Core Business

5. Wiley Online Library
Largest customer facing application
65 million page views per month
240 million visitors annually
1,600 queries per second (4 billion per mth)
Access to
Over 18 million documents
2,000 journals with 6 million journal articles
15,000 books with 300,000 chapters
6 million bibliographic references

6. About the Presentation
How do you get help to do Agile?
Is Pairing smart?
Can you really do agile with remote teams?
How do you hire the right people?
How Agile should you be?
How
Not
to do
Agile

7. What does doing Agile really mean?
Which one is better?
No need for Management/Organising?
No need for product vision/architecture?
Stand Ups – waste of time?
Not really doing Agile if you don’t co-locate
and do pair programming?
Does not matter
Remember guiding principles of Agile -
People over Process
Importance of Stand Ups and Retrospectives

8. How not to do Stand Ups
• Not just one big team
• Have individual scrum team stand ups - up to 10
• Big teams also have everyone including non devs - no limit
• But also have SoS (Scrum of Scrums) - only team leads/representatives
• Not get “traditional” pm to run it
• Not let “management” interfere
• Not run it for too long
• Not allow anyone to get away with “no update”
Make Stand Ups quick and useful
Answer 1 of 3 questions:
1.What you did yesterday and what you
will do today
2.What you need others to know
3.What you need help with

9. Stand Ups – in open spaces next to wall

10. Stand Ups - anywhere

11. Essential Tools – White Boards, Walls…

12. To Writable Walls

13. How not to do Retrospectives
• Not willing to provide feedback – do Safety Check
• Not team members in attendance
• Not just the negatives
• Not enough time to get to next steps
• Not doing one
Make it a culture
Do it after every iteration/major event
Have actionable item(s)

14. Large Team Retrospective

15. How do you get help to do
Agile?
Agile Assessment
Team Enablement
Inception Preparation
Team Building – Leaders within

16. Agile Assessment
As-is Process: Development perspective
In essence – download from team
through facilitated sessions
As-is Process: Requirements perspective
Putting the picture together & playing
it back
Get help when you need!
Always good to have impartial input

17. Team Enablement
• Team/Skillset Assessment
• How many know Agile?
• How many practice Agile?
• Training
• Hire Agile Coach
• Hire Agile Enablement consultants
• Hire experienced practitioners
• Who can show not tell
• Who can lead not debate
Wiley’s example
50% know Agile
25% practice Agile
Build 3 teams

18. Inception Preparation
Requirements – grouping and
coverage
Spiking
Systems touch points
System flow
Managing stakeholder
expectations
Engaging stakeholders from the
beginning

19. Inception Preparation - Continue
Inception planning
Roles and Responsibilities
Continuous Integration Shopping List

20. Iteration Planning

21. Team Building
Question:
How often we do team building before
starting on a very important project?

22. Is Pairing Smart?
Double the cost of doing work
When one stops, the other stops too
Fighting over the keyboard
Start from scratch with new partner
Arguments with no new code

23. How not to Pair…
• Pair for the sake of pairing
• Excuse for not doing work because not in a pair
• Not ready/comfortable to work as a pair
• Not recognising personal space
Smart Pairing
When you are training/mentoring/review
Scrum Master make the call

24. Two Pairs

25. Four Pairs

26. Can you really do Agile with
remote teams?
Agile manifesto says co-location
Not physically possible to do pair programming
from distance

27. How not to work with remote teams
• Not treat them as second class citizens
•Play to their strengths and recognise their
weaknesses
• Not find excuses - Make it work
•Organisational reality
•Invest in them
•Invest in tools
Extension of Team
Treat remote team members as full team
members
Be inclusive
Invest in training – bring members over and
vice versa

28. Ideas tried
• Change working hours to have some overlap
• Use video conferencing facilities (e.g. Skype)
• Assign appropriate work to remote teams
• Lead and organise work for remote teams (initially)
• Send local staff to remote teams and vice versa

29. How do you hire the right
people?
Train existing staff?
Convert non believers?
Hire agile leaders?
Outsource to agile companies?
Believers who are pragmatists
Not evangelists who are purists

30. • Not everyone wants to do or get TDD
• Not giving team freedom to learn and make mistakes
• Not letting it become religious wars
• TDD or not
• Pair or not
• Intellij vs Eclipse
• Jira vs Mingle
• SQL vs NoSQL
How not to manage people
Everyone is doing agile
Recruit Agile leaders – conversion takes
time
Be a Leader - People over process
Self organising but not self steering
Keep learning and adapting

31. How Agile should you be?
Agile S/W Development vs Agile Product Development
Your team is Agile , but not rest of organisation
Being agile Agile – The Wiley AGU story

32. About Wiley and AGU Partnership
• Wiley’s largest revenue generating society
owned partnership
• ‘Flagship’ product in the subject area of
Earth, Space & Environmental Science
• Not-for-profit corporation dedicated to
furthering geophysical sciences
• World’s leading society publisher in Earth
and Space Science, accounting for 25% of
journal articles and 40% of citations in the
geosciences
Crowdsourcing weather
using smartphone batteries
13 August 2013
The OpenWeather smartphone app
collects temperature, humidity and air
pressure information from users
around the world to track weather
conditions in real time

33. The Deal
Contract signed on 5 Sep 2012
Largest society deal in Wiley’s 200+ year
history
Challenging Timeline
• 4 months to achieve everything in the
contract

34. Measurable Success (and Failure)
1. Contractual Obligations to be met from January 2013:
1.1 Start revenue earning from publishing new content
• 20 Accepted Articles per day
• 20 Early View Articles per day
• 19 Issues per month
1.2 Give AGU’s 60,000+ customers and users access to all licensed content
• 21 journals (160,000 articles)
• 33 personal choice products (i.e. virtual journals)
• 743 special sections
• Migrate all customers, users, products, licenses and alerts data
1.3 Vendors, systems and business processes in Editorial & Production ready to
publish 2013 content
• Integration with new editorial system
• Changes to workflow
1.4 Achieve similar functionality on AGU site with 60+ enhancements and all
content converted, improved, loaded, tested and accessible on a single
platform,
Wiley Online Library
Failure is not an option
Challenging Timeline
• 4 months to achieve everything in the
contract

35. The Challenges
Key Challenges
•Resolving unique ID for journal titles in both internal and external systems
•Content with no issue number and no pagination
•Journal with 7 parts, of which 3 of those parts have sub-parts!
•Many moving parts within Wiley - 17 systems to check
•Content completeness and quality (and external vendor)
•Unknown unknowns - coping with changing and emerging requirements
throughout development phase
Non standard practices and variations (that we
didn’t know until we started)
•New licensing model
•Create Special Sections as another slice of content view
•New workflow for handling daily society data updates
via feeds
•Changing content workflow for legacy vs current content
•Start development before requirements were clear
•Complete testing before we had all the content
•Cannot complete certain types of testing
•Break some rules

36. • Significance of achieving project success
• Project goals achieved in 4 months – typically projects take at
least 3 months to get going
• Major releases typically take 9-12 months to complete
• This project had two major releases in 6 months with more
than 90 enhancements
How to become even more Agile?
60-Day Plan
6 weeks (6 x weekly iteration) for dev
2 weeks for end-to-end testing
6 dev teams in 4 locations (London,
Russia, Singapore, Switzerland)
People over Process

37. The Plan = The Wall + Excel
Finding the best people
Singleton work
More than 1 stand-ups daily
Quick decision making – rest of team
elsewhere
Flexible and adjust daily
People over Process

38. • Use of Enabling Technologies like MarkLogic
• As XML Store for content
• Use of technology with unintended side effect for
troubleshooting, auditing and reporting tool
• As a search engine, saves a lot of time from the native indexing
when loading new content
• Achieve rapid software development
• Enables rapid implementation of 60+ enhancements in 6 weeks
• Reuse search service for alerts and loading of saved search
• Reuse vocabulary service to help with hierarchy of index terms
• Supports faceting through configuration, no extra development
required
Enabling Technology

39. Recognition for Team
Wiley’s
President
Award for
Excellence
Visit by
AGU CEO
in May 2014
Customer
Excellence
Award
Celebrate Success
Strong team work
Excellent business and technology
collaboration
Team never met – no time!
Calm
Bonded for life!
People over Process

40. Conclusion
People over Process
Forget what I say
Remember to do one thing differently

41. Play Hard!

42. Which Agile Approach is Better?
• Does not matter
• Remember the core
values/principles of Agile
• People over Process