Assure Ecommerce and Retail Operations Uptime with ThousandEyes
Towards Agile Scalability: From Component To Feature Teams
1. Towards Agile Scalability:
From component to feature teams
Dmitriy Viktorov
AgileDays’09, December 9th, 2009
Protecting the irreplaceable | f-secure.com
2. About…
• Has been working at F-Secure for
more than 10 years
• The company started Agile
transformation in 2005
• We are still on our journey
2
4. Contents
• Component team vs. Feature team
• Benefits and challenges with transformation
• Lessons learned and future improvements
• Questions & answers
4
5. Disclaimer
COMMON SENSE
Just because you can, doesn’t mean you should
5
6. What is software?
SOFTWARE IS COMPOSED OF COMPONENTS
…but users see it as features
6
7. From Components to Features
Feature Component A Component B Component C Component D Component E
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
…
7
8. Conway’s Law
“[...] there is a very close relationship between the structure of a system and the structure of the
organization which designed it.
... Any organization that designs a system [...] will inevitably produce a design whose structure.”
8
9. Component Team Model
Feature
Request
Component Component Component Component Component
Team A Team B Team C Team D Team E
9
10. Disadvantages of Component Team Model
Delays due to Complicated
Sequential life
cycle development waiting and planning and
and mindset handoffs synchronization
Promotes to do Sloppy code
“artificial work” and duplication
Poor design Limits Waste of
and big quality learning and underutilized
personal people
debt development
10
11. It is all about dependencies…
WHAT SLOWS YOU DOWN
To be agile, reduce dependencies at all costs
11
13. Ideal Feature Team is…
• Long-lived
• Cross-functional
• Co-located
• Composed of generalizing
specialists
13
14. Feature Team Model
Feature Feature Feature Feature Feature
Request Request Request Request Request
Release 1
Release 2
Feature Feature Feature Feature Feature
Team 1 Team 2 Team 3 Team 4 Team 5
Release 3
14
15. Benefits of Feature Team Model
Less context
Less waiting, Simplified switching, more
reduced waste planning and faster
cycle time
effective work
of handoffs
Improved Self-managing
visibility and risk and balanced
management workloads
Promotes better Increased Higher
design and code learning and knowledge motivation and
quality sharing job satisfaction
15
16. Challenges and Issues
• Organizational structure
• Change resistance
• Long learning curve
• Difficult-to-learn skills
• Common tools and practices
• Maintenance services
• Non-engineering functions
16
17. Solution Project Organization (example)
Solution DC1 Scrum- Chief TE
Project of-
Scrums
Manager
Feature Team SM A T
Solution
Solution
Chief
Architect
QE Feature Team SM A T
Product
Owner A
Feature Team SM A T
DC2 Scrum-of-
Scrums
Feature Team SM A T
Product
Owner B
Feature Team SM A T
Solution Architect
IT sub-project PjM
17
18. Transition to Feature Team model
• Forming teams
• Code guardians
• PdO role
• Work agreements
• Plan and communicate
18
19. Everything you need is source code?
• Acceptance testing
• More exploratory testing
• Test automation
• Continuous integration
• Architecture/design workshops
• Pre-planning (5% workshop)
USE THE SOURCE, LUKE
19
