1. Funambol: introducing
SCRUM in
software product
development
Edoardo Schepis

2. Summary
• Funambol
► the company
► the product
► the team
• Releases
► one year and 3 releases to become agile
• Challenges
• Conclusions

3. Funambol – the company
• #1 mobile open source company
• ~70 employees worldwide
• Headquarted in the US (Silicon Valley)
• Engeneering team in Italy
• Sales presence in the US, Dubai, Beijing and Germany
• http://www.funambol.com

4. Funambol – the product/1
• Funambol is a product company
► i.e. No consulting
• Push email product
► Blackberry open source
► MobileWE
• Client and server components
• Carrier grade server
► Many components
• Synchronization server
• Push server
• Inbox listener
• PIM listener
• Connectors

5. Funambol – the product/2
• Multi platform clients
► WindowsMobile (SmartPhone & pocket PC)
► Win32/fat clients (Outlook)
► Symbian
► JavaME
► BlackBerry
► iPhone
► Android
► Mobile Linux
• Online portal (my.funambol.com)

6. Funambol – Engineering team/1
• Based in Pavia
• 20 developers
► 18 in Pavia
► 2 in Portugal
• 9 QA
►5 in Pavia
► 1 in Palermo
► 2 in Romania
► 1 in the USA
• 1 Technical Writer
• 1 Release Engineer
• 1 Scrum Master

7. Funambol – Releases
• A major release every 6 months (the islands):
► Elba (v. 6.5): January 2008
• Waterfall
► Capri (v. 7.0): August 2008
• Agility introduction
► Ischia (v. 7.1): January 2009
• Very close to Scrum
• Minor releases aka packs:
► phone packs
► client packs
• Customers Projects
• MyFunambol

8. Elba
• Waterfall and Gantt
• 3 teams around technologies:
► Server
► C++ Clients
► Java Clients
• Teams lead by technical leaders and architects
• Features in some wiki pages
• Pros
► teams were maximising skills and expertise
► high focus on software layers and components
• Cons
► nobaclkog - no user stories – no priorities
► boundaries between components also in process

9. Capri
• CTO said: “I want SCRUM!”
• Engineering said: “Are you crazy?!?”
► Elba has been perceived as a good release (“why should we
change something that works?”)
► But... it required a patch release just after one month (Pianosa)
• Let's apply some agile methods from Scrum:
► Iterative Development
• 4 weeks long
• 4 Iterations for dev
• 2 for integration and regression testing
► Product Backlog
► Planning game
► User Stories
► Splitting teams around user stories (4 teams)
► Scrum Masters (one per team)

10. Capri Results
• Results...
► “Oh my god a release every month!”
► “My team leader is also mastering my scrum team...”
► Backlog in a spreadsheet not up to date
• user stories lacking of details
• business value not properly set
• no burndown charts
► Estimates made by tech leads and architects and then assigned to
teams
► People still working in waterfall way
► Quality not meeting the expectations – many new bugs
• But...
► No need of patches
► Many new features and software components
► Release perceived as a good one by the management (not by the
developers)

11. Ischia
• Injecting in a better way agility and Scrum in the process
►3 teams with technologies focus
• no roles
• no leads
►1 Scrum Master
• just this goal within the company
• only one for the 3 teams
► Backlog managed in Agile/Scrum way
• user stories
• DONE definition
• estimates performed by the teams
• right tool for distributed teams (RallyDev)
• burndown charts always up to date
• Technical Debt backlog
► More Scrum karma
• teamwork
• communication

12. Ischia Results
• The Highest level of communication and knowledge
sharing
• People feel the agility
• Teamwork
• Management loves receiving feedback, comments,
proposals from the teams about user stories and features
• User stories really done (almost there)
• Continuous Integration
• 3 Iterations for development
► velocity = 180 s.p./iteration (3 teams together)
• 1 for Integration and Regression aka SprintGA

13. Done Definition
• Changes Log updated
• Unit tests implemented and passed
• Acceptance tests defined and passed
► no new bugs or regression bugs introduced with a new u.s.
• Releasable (installable on a demo server)
► documentation
► upgrade impact
► backward compatibility
► performance impact
• No increased technical debt: reduce unreadable,
duplicated, untestable, undocumented code

14. Ischia Charts

15. Ischia Charts

16. Retrospectives

17. Improvements
• Committing less and better estimations
► iterations 2 weeks long
► split user stories and define tasks
• Reduce Impediments level
► customers
► the fireman role (?)
• More Agile Methods
► Code review or pair programming?
• QA role in Scrum and agile methodologies
► automating mobile devices testing
• Scrum of Scrum
• Open Source and community contributions

18. Conclusions/1
• User stories definition
► Size of the User Stories
► Estimates
► Managing inclusions and dependencies
• Iteration planning
► Difficult because of the above
• Cultural switch
► From centralised responsibility to distributed responsibility
► Agile is much easier to pronounce than to apply :)
► SCRUM requires discipline and teamwork
► Human factor is fundamental

19. Conclusions/2
• Controlling the chaos!
► Teams working in parallel
► People shocked by the new process!
► Co-ordination challenges
• Development
• Building
• Testing
• Releasing
• Overall architecture
► How to fit the “GA” release process
• Quality assurance
• Bug fixing

20. Q&A

21. References
• http://www.funambol.com
• http://my.funambol.com
• http://pragmatic-agile.net