Presentation about managing distributed software teams.

1. https://dev.to/rly

2. Who is Jilles?
www.jillesvangurp.com, and @jillesvangurpon *
Java (J)Ruby Python Javascript/node.js
Servers reluctant Devops guy Software Architecture
Universities of Utrecht (NL), Blekinge (SE), and Groningen (NL)
GX (NL),Nokia Research (FI), Nokia/Here (DE),Localstream (DE),
Inbot(DE).

3. Inbot app - available for Android & IOS

4. Trends/context
Freelance jobs & short term contracts are common
Job security is a bit of a myth
Internet tools mean it is easier than ever to work remote
Most programmers don't actually live in San Francisco; how to use them?
Building software requires a lot of different specialists
Robots are eating our jobs

5. The modern workplace
Cubicles, open spaces, …. really?!
Home office
Shared desks
Coffee shops
Couch surfing
Beach
Anywhere with internet access & suitable "work-context"

6. Industrial Revolution
Economies of scale through
- colocating resources
- minimizing transport
- scale by sharing resources
- minimize space used
- cheap, plentiful labor available locally
Is all this still relevant if all you really need is specialists with a laptop + internet?
Creative work doesn't happen in factories.
Are you a "resource"?

7. Renovating your house analogy
- Talk to an architect
- Hire a foreman
- Foreman gets brick layers, carpenters, electricians, painters, etc. to show up at the right time
- Typically self-employed
- You find a person that knows a few others and they work together to do the thing
Very pre-industrial revolution, trust & relationship based.
You don't get economies of scale by putting programmers in cubicles
You don't get any benefit from only hiring local talent in crowded market
It's a global village now, this is the post industrial revolution

8. How local are you really?
Do you talk to people on different floors of your office building?
Or down the street?
Outside your team?
How often?
And about work?
How many people do you interact with professionally on a day to day basis?

9. Rest of this presentation ...
Software Engineering is & "True-isms" about SE
Distributed Software Teams

10. First SE conferences organized by NATO in 1968 to solve the
"Software Crisis"
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/NATOReports/
https://www.nasa.gov/50th/50th_magazine/scientists.html
Water-fall: apply engineering principles to big SE projects
Royce, Winston (1970), "Managing the Development of Large Software
Systems", Proceedings of IEEE WESCON, 26 (August): 1–9
Waterfall -> Spiral Development -> Rational Unified & 4+1 model
-> Extreme Programming -> Scrum -> Kanban -> ...
Sofware Engineering, a brief history
At the start of the Apollo program, the
onboard flight software needed to land on
the moon didn’t exist. Computer science
wasn’t in any college curriculum. NASA
turned to mathematician Margaret
Hamilton, of the Massachusetts
Institute of Technology, to pioneer and
direct the effort. With her colleagues, she
developed the building blocks for modern
“software engineering,” a term Hamilton
coined.

11. "Laws" of Software Engineering (1)
Conway's Law, "organizations which design systems ... are constrained to produce designs
which are copies of the communication structures of these organizations"
Parkinson’s Law (1), "work expands so as to fill the time available for its completion"
Parkinson's Law (2), "people in groups tend to give disproportionate weight to pointless
discussions."
Law of Demeter, principle of least knowledge. Each unit should have only limited
knowledge about other units: only units "closely" related to the current unit. Each unit should
only talk to its friends; don't talk to strangers. Only talk to your immediate friends.

12. "Laws" of Software Engineering (2)
Peter Principle, "managers rise to the level of their incompetence."
Brooke's Law, "adding manpower to a late software project makes it later"
Two Pizza Rule
(There are two hard things in computer science: cache invalidation, naming things, and
off-by-one errors)

13. Seniority: Listen to uncle Bob
I estimate that the world, today, has twenty-two million programmers[2]. One of of every 300 people is a programmer. In the US it’s
closer to 1%. But in 1974 the number of programmers worldwide was vastly smaller, and probably numbered less than 100,000[3].
That implies that in 40 years our ranks have increased by a factor of 220. That’s a growth rate of 14.5% per year, or a doubling
rate of five years.
If the ranks of programmers has doubled every five years, then it stands to reason that most programmers were hired within the last
five years, and so about half the programmers would be under 28. Half of those over 28 would be less than 33. Half of those over 33
would be less than 38, and so on. Less than 0.5% of programmers would be 60 or over. So most of us old programmers are still
around writing code. It’s just that there never were very many of us.
What does this imply for our industry?
Maybe it’s not as bad as Lord of the Flies, but the fact that juniors exponentially outnumbers seniors is concerning. As
long as that growth curve continues[4] there will not be enough teachers, role models, and leaders. It means that most software teams
will remain relatively unguided, unsupervised, and inexperienced. It means that most software organizations will have to endlessly
relearn the lessons they learned the five years before. It means that the industry as a whole will remain dominated by novices, and
exist in a state of perpetual immaturity.
http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

14. SE Reality Check
Engineering metaphor is a fallacy, there's more to it than blueprints & math
Big heavy processes tend to not work as advertised
Agile the good: adapting to changing reality; less upfront planning, building stuff
fast that is actually useful
Agile the bad: new bureaucracy (story points, retrospectives, velocity charts, ...),
dogmatic application of unscientific ideas, waterfall in disguise, technical debt, ..
Small teams are easier to manage, need less process (more Agile)

15. The point about small teams:
keep communication links down
Observation: Communication gets harder when you distribute ….

16. SE at scale: Big Software Projects/Products
Multiple MLOC, tens of thousands of developers,
reusing and depending on even more software, life
span of decades, R&D value measured in billions.
How do you 'engineer' such a thing?
Simple Answer: don't. It just 'happens' organically.
Software development happens in communities of
practitioners.
More Complex Answer: throw engineers at it,
thousands of them, and hope for the best but start
small and fail fast.

17. How to Engineer a 1 MLOC software system?
~constant: productivity of engineers is 10 LOC / day (controversial)
1 engineer, 100K days, or about 273 years, full time ;-)
10 engineers 10K days, about 27 years
100 engineers 1K days, about 2.7 years, starting to get doable
1 MLOC is comparatively small scale software
Mythical Man Month: planning doesn't quite work like that.

18. Distributed Teams ...
https://www.youtube.com/watch?v=m_MaJDK3VNE

19. Why?
You want to build X, you need people with skills
You know suitable people but they live in a different places
Why not work together & why move to one place?
It's easy to get started with people that you know, even when they are not local

20. Distributed teams - challenges
Practicalities: Timezones, cultural differences, language barriers, tools, processes
Formalities: who reports to who? who pays the bills? how do you hire/fire?
Conflicts: stress + communication challenged people = cat fight
Realities: people have different motives, goals, incentives, opinions
Same challenges as non distributed but magnified by the fact that communication is
harder: it's still software engineering!
What didn't work before, now doesn't work even better!

21. OSS development …. they can do it. How?
- Distributed by default
- Many small projects
- Some bigger projects
- Reuse & depend on each other
- Basis for 99% of most commercially shipping software and projects
- Primarily funded by for profit software companies - this is NOT charity
- Driven by people/companies deciding to do things that need doing from their
point of view.
- Work on a need to have basis.

22. The OSS community
Distributed network of professionals, companies, and other stakeholders.
Extremely well financed
Work together out of necessity
Collectively get more work done than any software company out there
Formula for distributed: Look at the stuff they are NOT doing.
So, it scales up. It also scales down ...

23. Working with thousands of people looks like this ...

24. The Amazon Formula
Write out new ideas
Incentivize team members for the long term: make them owners
Follow the “two pizza rule.”
Dedicate time to think about the future
Routinely “check in” on long-term goals
Work backwards
Jeff Bezos
http://99u.com/articles/7255/the-jeff-bezos-school-of-long-term-thinking

25. Stuff that doesn't work
(aka. corporate shit I don't miss in my life)
Standups and any process that requires them. This is where Scrum falls short. Forget about
doing retrospectives, estimation sessions, and other BS bingo that comes with scrum. IT
DOES NOT WORK. (Opinion: this is not specific to distributed teams, it just becomes even
more obvious)
Having long meetings over a phone with a large group. Just results in the wrong people
claiming all the talking time while the rest mute and try to get some work done. Twitter is 1
alt+tab away...
Trying to impose complicated processes, new ways of working, while at the same time you
are onboarding new team members.
Email, just don't.

26. Stuff that works (for us)
Weekly short status calls. Agree times that fit everyone, e.g. 11 am instead of 9 AM.
Everybody provides brief update. 20-30 minutes max.
Weekly planning meeting: discuss business, blockers + KANBAN: done, in progress, next.
Shared slides for each meeting on google docs: update before & during meeting.
1 on 1's are a great way to smooth out issues, avoid doing this in planning calls.
Work backwards from business needs. What is blocking the business? What is blocking the
technical solutions to the business blockers? How can we move forward?
Most of us are "elsewhere", this forces us to be distributed.

27. Go Asynchronous - avoid bottlenecks
Example bottlenecks: handovers, meetings, people availability, office hours, slow builds, complicated
processes, anything that causes you to wait for something or someone.
Don't wait for a meeting to announce that X is now ready when a simple @all message in Slack can do
the job. Grab somebody's attention with a @<name> instead of waiting for the next scheduled meeting.
Git is asynchronous if used properly: Send a pull request when you need somebody to look at
something. Merge 'done' work to master branch (auto rolls out to server), keep master usable at all times.
Automate as much as you can. CI, Deploys, etc. Chatops is a thing. Automated updates via slack are
great to keep track of what is happening.
Coordinate outcomes, not tasks. Outcomes have stakeholders and ownership.

28. Oh, the irony ….

29. Inter team communication = dependency mgmnt!
People dependencies. Communicate daily with people that depend on you and with people that you
depend on. Your org chart is a graph, not a tree. Team = cluster of people that need each other; this
changes over time.
Avoid tight coupling. Limit the number of people you depend on to progress. Avoid being a bottleneck
for too many others. Delegate, prioritize, do 1 thing at the time. Learn to say no.
Team cohesiveness. Make sure you have the right people, make sure everyone is working towards the
same goals. Check this regularly.
Small teams. Big teams have poor cohesiveness and large degree of coupling, lose a lot of time talking
instead of getting stuff done.
Demeter's law is relevant too: don't talk via intermediaries. Avoid Conway's law and restructure if
needed.

30. Q&A
@jillesvangurp, @inbotapp