Happier Teams Through Tools

Понравилась презентация – покажи это...

Слайд 0

Happier Teams Laura Frank @rhein_wein Software Engineer @codeship

Слайд 1

Happy people are productive people.

Слайд 2

Happiness and Productivity

Слайд 3

Can a team’s choice of tools make developers happy, and therefore more productive?

Слайд 4

Yes. (duh)

Слайд 5

Each process and tool impacts how developers spend their time.

Слайд 6

The Happiness Equation

Слайд 7

Слайд 8

University of Warwick Study • People treated with positive stimuli were, on average, 12% more productive than the control group • People treated with negative stimuli were similarly less productive • Still, hard to quantify what we consider ‘negative’ and ‘positive’ • tinyurl.com/warwickhappiness

Слайд 9

Track Your Happiness

Слайд 10

Happiness Metrics • How do you feel? • What are you doing right now? • Do you have to be doing what you’re doing? • How productive are you being right now? • Do you want to do what you’re doing?

Слайд 11

Time-based pressure is nearly universally negative

Слайд 12

Fun Fact Commuting to and from work is typically the unhappiest time in a person’s day

Слайд 13

The Real Happiness Equation happiness = autonomy + no interruptions + no time pressure

Слайд 14

“The driving force seems to be that happier workers use the time they have more effectively, increasing the pace at which they can work without sacrificing quality.” – DR DANIE L SG ROI , UNIVE R SIT Y OF WARWICK

Слайд 15

There are several areas within development where we can maximize for happiness ✨

Слайд 16

Team Communication

Слайд 17

Employees report feeling stressed when they are either being unproductive or interrupted

Слайд 18

All incoming communication needs to have a process behind it.

Слайд 19

Слайд 20

Centralized Manager (Pivotal, Trello, Jira, ZenDesk etc)

Слайд 21

Treat your task manager as a means for persistent communication

Слайд 22

Remember that commuting to and from work is typically the unhappiest time in a person’s day?

Слайд 23

Persistent communication is essential to a remote team.

Слайд 24

Слайд 25

A clear, persistent record of business decisions.

Слайд 26

This type of communication is ‘pullbased’. You can choose when to consume it and it’s not as disruptive unless you allow it to be.

Слайд 27

Meetings ಠ_ಠ

Слайд 28

“This meeting could have been an email.” – E VERY P ER SO N EVER

Слайд 29

Unnecessary meetings are disruptive and expensive

Слайд 30

Meetings are good for complex discussion… But they go against the pattern of persistent communication.

Слайд 31

You MUST document the discussion and outcome of a meeting if you intend to have a team that can function remotely.

Слайд 32

My team uses Google Docs in place of many meetings.

Слайд 33

Слайд 34

Choose one mode of communication only Try to make it as least disruptive as possible Document the discussion and outcomes

Слайд 35

Architecture Patterns

Слайд 36

“Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” – M E LVIN CO NWAY

Слайд 37

Conway’s Law Any piece of software reflects the organizational structure that produced it

Слайд 38

If you have three engineering teams working on one piece of software, you’ll probably end up with three pieces of software

Слайд 39

super-cool application

Слайд 40

super-cool subsystem super-cool subsystem super-cool subsystem

Слайд 41

The interaction between components reflects how well teams communicate.

Слайд 42

Similarly, a unified team will selfseparate to tackle a problem with discrete components.

Слайд 43

super-cool service super-cool service super-cool service

Слайд 44

super-cool service super-cool service super-cool service

Слайд 45

In a SOA or microservices architecture pattern, each of the services is autonomous and can operate independently

Слайд 46

A service team can choose the correct tools — like languages, deployment processes, and incident management systems — specific to their component

Слайд 47

The pattern for people and the pattern for software mirror one another. Conway’s law in action

Слайд 48

Smaller teams with a targeted focus have autonomy over the software they build. autonomy happiness

Слайд 49

Continuous Deployment

Слайд 50

A human-initiated and monitored deployment is a huge disruption, distractor, and demotivator.

Слайд 51

Deployment should be an automatic step triggered by a change to a designated branch in your repo.

Слайд 52

We call this Repository-Driven Deployment.

Слайд 53

push Dev Team automated tests feature review and merge continuous delivery master review and merge production timed release

Слайд 54

push Dev Team automated tests feature review and merge continuous delivery master review and merge production timed release

Слайд 55

• The team shares responsibility for deployment, and each engineer is empowered to control the flow of his or her code into production • Your customers are always getting the best product you have to offer

Слайд 56

“Embrace the green button, Laura.” – NICK GAUT HIE R , CO DE SHIP

Слайд 57

I hate(d) the green button.

Слайд 58

If the checks pass, merge it. From bed. Or from the U-Bahn. Or wherever.

Слайд 59

Incident Management

Слайд 60

Interruption is sometimes necessary…

Слайд 61

Don’t confuse priority with urgency

Слайд 62

Priority measures how important a task is, relative to other tasks.

Слайд 63

Urgency is a measure of how quickly the task must be completed.

Слайд 64

A P0 incident is urgent, and communication for this incident requires interrupting people in order to accomplish the task

Слайд 65

“You pay for urgency with interruption; and you should understand whether or not you are getting a good deal.” – NICO APP E L, T IGHTOPS.COM

Слайд 66

Have policies, training, and docs that allow each developer to solve incidents assigned to them.

Слайд 67


Слайд 68

With a better system in place, I can have more autonomy and reduce the duration of the interruption

Слайд 69


Слайд 70

“If an engineer is on call, make sure he or she has access to logs, metrics, and the ability to deploy new code to production.” – CAP TAIN O BVIO US

Слайд 71


Слайд 72


Слайд 73