Funambol introduced SCRUM to their software development process over the course of a year and three releases. They started with a waterfall process for their first release but encountered issues. Their second release incorporated some agile practices but still had problems. For their third release, they fully adopted Scrum practices like user stories, estimation, and daily standups across three teams, which improved communication, teamwork and management feedback. They continue working on improvements like reducing story sizes and technical debt.

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