Bigger product is better - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu
2
The best
architectures,
requirements,
and designs  
emerge from
self-organizing
teams.
Blog: LeanArch.eu
Most popular post:
“Do Agile teams need PSA documents? Well, no!”

3
“Yeah, but this is
pure Agile”

4
“1. Organizations are implicitly optimized to avoid changing the status
quo middle- and first-level manager and “specialist” positions & power
structures.
2. As a corollary to (1), any change initiative will be reduced to
redefining or overloading the new terminology to mean basically the
same as status quo.
3. As a corollary to (1), any change initiative will be derided as “purist”,
“theoretical”, “revolutionary”, "religion", and “needing pragmatic
customization for local concerns” — which deflects from addressing
weaknesses and manager/specialist status quo.
4. Culture follows structure.”
Larman's Laws of
Organizational Behavior

5
Deliver always the highest business value / the most important
Business Agility: Turn on a dime for a dime
Optimising goals

6

7
Architecture has become a thing
Euhm,
what?

8
Agile has become a thing

9

10

11

12
A brain can handle only one pattern

13

14

15
Software
(Agile)
Enterprise
Architecture
Software
Architecture
Product
(Agile)
Software
Architecture
Agile Project
Management
Project
Scrum of
Scrums
Scrum
Microservices

16

17
“adopted <famous scaling
framework> of 2000 people
…and business didn’t
notice any difference”
Email this morning from an agile
coach in a large bank and
“successful agile transformation”

18

“Our highest priority is to satisfy the
customer 
through early and continuous delivery 
of valuable software”
19

So, less is more
20

What is a product?
21

What is a product?
22

23
Product with small
deﬁnition has a
shorter lifespan
Product with
broad deﬁnition
evolves

24

25

26

27

28
Backlog Item 1
Backlog Item 2
...
Comp A
Team
Comp B
Team
Comp
C
Team
Analyst System
Engineer
System
Testers
Iteration 1 Iteration 2
(probably later)
Iterations 3-5
(probably later
and more)
At least
iteration 6
(probably later)
Item 1
requirement
details
for Item 1
'backlog' by
component
not all teams start Item
1 at the same iteration;
they are multitasking
on multiple features system testers
cannot start
immediately on
Item 1; they are
multitasking on
multiple features
not available
until the analyst
is ﬁnished
Analysis
Design
Implementation
Test
Component teams lead to a sequential life cycle with handoff, queues, and
single-specialist groups and not true cross-functional teams without handoff.
code
www.craiglarman.com
www.odd-e.com
Copyright © 2010
C.Larman & B. Vodde
All rights reserved.

29

30
Nothing
File / Class
Sub System
Whole Product
Whole System
PotentialTechnologyworkscopeinsidetheteam
Activity (function) inside the team.
Degree of cross-functionality
Code + Design and
Unit Test
+ Analysis
and System Test
+ Co-creation
Traditional
Component Teams
Ideal state!
Hard to
achieve, good
to work
towards
Feature
Teams
Component
Problem
Extended Component Teams
Conﬂict in scope in the team
leading to duplication or
additional coordination work
Functional
overspecialisation

31

32

33
More then 8 teams, 1 product

34

So, what about
• Continuous value creation over projects
• Whole product focus over program management
• Broader product deﬁnition over fake portfolio management
• Real portfolio management is collaboration between Product Owners
• Enterprise Architecture…..eh :-)
35

Amazon
1. All teams will henceforth expose their data and functionality through service
interfaces.
2. Teams must communicate with each other through these interfaces.
3. There will be no other form of interprocess communication allowed: no direct
linking, no direct reads of another team's data store, no shared-memory model,
no back-doors whatsoever. The only communication allowed is via service
interface calls over the network.
4. It doesn't matter what technology they use. HTTP, Corba, Pubsub, custom
protocols -- doesn't matter. Bezos doesn't care.
5. All service interfaces, without exception, must be designed from the ground up
to be externalizable. That is to say, the team must plan and design to be able to
expose the interface to developers in the outside world. No exceptions.
6. Anyone who doesn't do this will be fired.
36

37
Scaling Lean & Agile
Development
Thinking and Organizational Tools
for Large-Scale Scrum
Craig Larman
Bas Vodde
Practices for
Scaling Lean & Agile
Development
Large, Multisite, and Offshore Products
with Large-Scale Scrum
Craig Larman
Bas Vodde

less.works
38

Bigger product is better - Viktor Grgric

Recommandé

Recommandé

Contenu connexe

Similaire à Bigger product is better - Viktor Grgric

Similaire à Bigger product is better - Viktor Grgric (20)

Plus de Avisi B.V.

Plus de Avisi B.V. (20)

Dernier

Dernier (20)

Bigger product is better - Viktor Grgric