bigger product is better - viktor grgric

38
Bigger product is better

Upload: avisi-bv

Post on 16-Apr-2017

65 views

Category:

Software


2 download

TRANSCRIPT

Page 1: Bigger product is better  - Viktor Grgric

Bigger product is better

Page 2: 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!”

Page 3: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 3

“Yeah, but this is pure Agile”

Page 4: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 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 ofOrganizational Behavior

Page 5: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 5

Deliver always the highest business value / the most important

Business Agility: Turn on a dime for a dime

Optimising goals

Page 6: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 6

Page 7: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 7

Architecture has become a thing

Euhm, what?

Page 8: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 8

Agile has become a thing

Page 9: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 9

Page 10: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 10

Page 11: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 11

Page 12: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 12

A brain can handle only one pattern

Page 13: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 13

Page 14: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 14

Page 15: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 15

Software

(Agile)EnterpriseArchitecture

SoftwareArchitecture

Product

(Agile)SoftwareArchitecture

Agile ProjectManagement

Project

Scrum ofScrums

Scrum

Microservices

Page 16: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 16

Page 17: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 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”

Page 18: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 18

Page 19: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

“Our highest priority is to satisfy the customer

through early and continuous deliveryof valuable software”

19

Page 20: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

So, less is more

20

Page 21: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

What is a product?

21

Page 22: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

What is a product?

22

Page 23: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 23

Product with small definition has a shorter lifespan

Product with broad definition evolves

Page 24: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 24

Page 25: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 25

Page 26: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 26

Page 27: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 27

Page 28: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 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 finished

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.

Page 29: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 29

Page 30: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 30

Nothing

File / Class

Sub System

Whole Product

Whole System

Pote

ntia

l Tec

hnol

ogy

wor

k sc

ope

insi

de th

e te

am

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 TeamsConflict in scope in the team leading to duplication or additional coordination work

Functional overspecialisation

Page 31: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 31

Page 32: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 32

Page 33: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 33

More then 8 teams, 1 product

Page 34: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 34

Page 35: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

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

35

Page 36: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

Amazon1. 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

Page 37: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu 37

Scaling Lean & Agile Development

Thinking and Organizational Tools for Large-Scale Scrum

Craig LarmanBas Vodde

Practices for Scaling Lean & Agile

DevelopmentLarge, Multisite, and Offshore Products

with Large-Scale Scrum

Craig LarmanBas Vodde

Page 38: Bigger product is better  - Viktor Grgric

Viktor Grgic @vgrgic Odd-e Hong Kong Ltd. odd-e.com leanarch.eu

less.works

38