Towards Agile Scalability: From Component To Feature Teams

Post on 15-Jan-2015

2.944 views 0 download

Tags:

description

 

Transcript of Towards Agile Scalability: From Component To Feature Teams

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