Slide 1

Slide 1 text

Stop Smashing Your Keyboard! Zoom Out and Think! Eduardo da Silva (@emgsilva|[email protected])

Slide 2

Slide 2 text

What “normal” People think we do on a daily basis?

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Popular myth(?):we smash keyboards! really fast! And make magic happen...

Slide 5

Slide 5 text

even though in reality we do not go so fast… we are still expected to go “fast”

Slide 6

Slide 6 text

Why do we need to move fast? Because businesses need “fast” to stay ahead!, there is always a sense of urgency on what we are doing… ...and that “is not bad”

Slide 7

Slide 7 text

How are we tackling this “need for speed”? Get our heads down and “just do it”! Be agile! Be lean! ... Deliver things fast! tuff

Slide 8

Slide 8 text

What is the outcome?

Slide 9

Slide 9 text

(blind) Agile and Go Fast Too much focus on speed (rate of motion)… heads down, let’s move fast!! No time to define direction! “Go with the flow/instinct”

Slide 10

Slide 10 text

Agile and Go Fast with clear(er) direction We must focus on “high velocity” We need direction (on our iterations)! Result = move fast towards the “end goal”! Decisions

Slide 11

Slide 11 text

Proposal: Stop smashing your keyboard! Zoom out and think!

Slide 12

Slide 12 text

Framework for incremental architecture design 1) Start the project by addressing the “important decisions” (=Architecture) a) What/Why/How b) Initial plan of action (start...end) 2) At each new “important decision” a) Re-evaluate the what/why/how - with the end-goal in mind b) (re)define plan of action Decisions

Slide 13

Slide 13 text

Some tools...

Slide 14

Slide 14 text

Visualization of Problems and Solutions When stuck on a problem… ● go “offline”, (zoom-out-think) visualize your problems and solutions No need of UML and formal architecture languages ● Whiteboarding is good Helps everyone get a common perspective faster

Slide 15

Slide 15 text

Architecture Decision Records (ADR) (by Michael Nygard) Lightweight documentation of the “design decisions” These are “immutable” - a design decision is taken and executed ⇒ no more stale documentation Project documentation that seats on your codebase!

Slide 16

Slide 16 text

Thank you! More on this in: