towards agile scalability: from component to feature teams
DESCRIPTION
TRANSCRIPT
Protecting the irreplaceable | f-secure.com
Towards Agile Scalability:From component to feature teamsDmitriy Viktorov
AgileDays’09, December 9th, 2009
About…
2
• Has been working at F-Secure for
more than 10 years
• The company started Agile
transformation in 2005
• We are still on our journey
F-LEX – Agile Software Development Process
3
Contents
• Component team vs. Feature team
• Benefits and challenges with transformation
• Lessons learned and future improvements
• Questions & answers
4
Disclaimer
COMMON SENSE
Just because you can, doesn’t mean you should
5
What is software?
6
SOFTWARE IS COMPOSED OF COMPONENTS
…but users see it as features
From Components to Features
7
Feature Component A Component B Component C Component D Component E
Feature 1
Feature 2
Feature 3
Feature 4
Feature 5
…
Conway’s Law
8
“[...] 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.”
Component
Team A
Component
Team E
Component
Team C
Component
Team D
Component
Team B
Component Team Model
9
Feature
Request
Disadvantages of Component Team Model
10
Promotes to do
“artificial work”
Sloppy code
and duplication
Sequential life
cycle development
and mindset
Delays due to
waiting and
handoffs
Complicated
planning and
synchronization
Waste of
underutilized
people
Poor designand big quality
debt
Limitslearning and
personal
development
It is all about dependencies…
11
WHAT SLOWS YOU DOWN
To be agile, reduce dependencies at all costs
December 13,
200912
Ideal Feature Team is…
• Long-lived
• Cross-functional
• Co-located
• Composed of generalizing
specialists
13
Feature
Team 1
Feature
Team 5
Feature
Team 3
Feature
Team 4
Feature
Team 2
Feature Team Model
14
Feature
Request
Feature
Request
Feature
Request
Feature
Request
Feature
Request
Release 1
Release 2
Release 3
Benefits of Feature Team Model
15
Less waiting,
reduced wasteof handoffs
Less context
switching, more
effective work
Simplified planning and faster
cycle time
Improvedvisibility and risk
management
Self-managingand balanced
workloads
Increased learning and knowledge
sharing
Promotes better
design and code
quality
Higher
motivation and
job satisfaction
Challenges and Issues
• Organizational structure
• Change resistance
• Long learning curve
• Difficult-to-learn skills
• Common tools and practices
• Maintenance services
• Non-engineering functions
16
Solution Project Organization (example)
17
Scrum-of-
Scrums
Scrum-
of-
Scrums
Chief TESolution
Project
Manager
Solution
Architect
Product
Owner A
Solution Architect
Solution
Chief
QE
Product
Owner B
Feature Team A TSM
Feature Team A TSM
Feature Team A TSM
Feature Team A TSM
Feature Team A TSM
IT sub-project PjM
DC1
DC2
Transition to Feature Team model
• Forming teams
• Code guardians
• PdO role
• Work agreements
• Plan and communicate
18
Everything you need is source code?
• Acceptance testing
• More exploratory testing
• Test automation
• Continuous integration
• Architecture/design workshops
• Pre-planning (5% workshop)
19
USE THE SOURCE, LUKE
December 13,
200920
Conclusion
21
WHAT HAVE WE LEARNED SO FAR?
Questions? Thank You!
22