Believe it or not

Leo Antoli @lantoli

I refuse to go to

any conference

that would

have me for a

keynote speaker

Passionate about Software Development

no agilists were harmed in the making of this presentation

Previously:

Consultant / coach

Now:

Developer & IT Responsible in a startup

We do...

Scrum (by the book)

Sprints (2 weeks)

PBI ready before starting, everything Estimated

Scrum Master

Product Owner (not a proxy)

Co-located work much better than remote one

Physical boards (even being in remote)

Pair programming

TDD / BDD always

Code coverage > 80%

We REALLY do...

We DON’T do/have

Scrum

Ready PBI before starting

Scrum Master

real unique Product Owner

No TDD / BDD

Code coverage, really ?

We really do…

No branches, master always ready to be deployed to Production

Continuous deployments several times a day

Production monitoring and exception handling

All commits potentially reviewed

We really do… Kanban (kind of, no WIP limit)

Remote workThere isn't a simple dichotomy of remote versus co-located work, instead there are several patterns of distribution for teams each of which has different trade-offs and effective techniques suitable for them. While it's impossible to determine conclusive evidence, my sense is that most groups are more productive working in a co-located manner. But you can build a more productive team by using a distributed working model, because it gives you access to a wider talent pool.

http://martinfowler.com/articles/remote-or-co-located.html

No pair programming

Are Tools important ?

Try it yourself

One size fits all ?

Studies, surveys ...

Pair programming

http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

EVERYBODY SHOULD BE USING IT !!!

Economics

Pairs spend about 15% more time on programs than individuals. However, the resulting code has about 15% fewer defects. Along

with code development time, other factors like field support costs and quality assurance also affect the expenses. IBM reported spending

about “$250 million repairing and reinstalling fixes to 30,000 customer-reported problems”. Pair programming significantly reduces these

expenses by reducing the defects in the programs.[2]

StudiesThere are both empirical studies and meta-analyses of pair programming. The empirical studies tend to examine the level of productivity and the quality of the code, while meta-analyses may focus on biases introduced by the process of testing and publishing.

https://en.wikipedia.org/wiki/Pair_programming

Pair programming

Pair programming

In 1999, a controlled experiment run at the University of Utah investigated the economics of pair programming. Advanced undergraduates in a Software Engineering course participated in the experiment. One third of the class coded class projects as they had for years – by themselves. The rest of the class completed their projects with a collaborative partner.After the initial adjustment period in the first program (the “jelling” assignment),

http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Pair programming

Empirical studies

On simple tasks, which the pair already fully understands, pairing results in a net drop in productivity

Thus the meta-analysis concluded that "pair programming is not uniformly beneficial or effective"

Pair programming

Economics

IBM reported spending about $250 million repairing and reinstalling fixes to 30,000 customer-reported problems [7]. That is over $8,000 for each defect!

(mixing data)

Skeptics assume that incorporating pair programming will double code development expenses

Pair programming

How pairs were formed?

How time spent was measured ?

Satisfaction ?

because working together?

Happiness studies are useless

TDDHowever, little empirical evidence supports or refutes the utility of this practice in an industrial context

4 teams in the study: With the TDD group, test cases were developed mostly up front as a means of reducing ambiguity and to validate the requirements, which for this team

was a full detail standard specification. UML class and sequence diagrams were used to develop an initial design.

http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

TDD thesis 2009Conclusions: This study provided substantial evidence that Test-Driven Development is, indeed, an effective tool for improving the quality of source code. Test-Driven Development offered an overall improvement of 21% over code written using the test-last technique. Considering the sheer volume of the codebases being analyzed, it's reasonable to conclude that the substantial difference is noteworthy. Test-Driven Development was most effective at decreasing the complexity of the code, with an improvement of 31%. Complexity deals exclusively with the code inside of a module, ignoring any relationships with other aspects of a system. ... The next-best improvement was on cohesion metrics, an improvement of 21%. ... The smallest improvement Test-Driven Development offered was on coupling metrics, only 10%.

This work created two code samples - code that was written using Test-Driven Development (the experimental group) and code that was written without it (the control group). Surveys were sent out to the developer mailing lists for dozens of Open Source projects.

http://biblio.gdinwiddie.com/biblio/StudiesOfTestDrivenDevelopment

Scrum studies

Example in Scrum Alliance website

Defining success:

- customer satisfaction, i.e., meeting requirements, fulfilling customer needs- budget and schedule, i.e., meeting time and budget goals- business success, i.e., the level of commercial success or market share- future potential, i.e., opening new markets, developing new technologies

IMPOSSIBLE TO KEEP ALL OTHER FACTORS EQUAL, CORRELATION NOT CAUSATION

https://www.scrumalliance.org/resource_download/1156

Productivity

Good programmers are 10x more productive than normal programmers

"The book Javascript Ninja has a Samurai on the cover. That happens because JS is not strongly typed." https://twitter.com/abt_programming/status/473405923751641088

Coding dojos / retreats

Code retreat: “Este formato ha demostrado ser un mecanismo eficaz para mejorar las capacidades de diseño y desarrollo de software de sus participantes.”

http://mindfood.osoco.es/index.php/global-day-of-coderetreat-2015/

Coding dojos / retreats

Careful with the sense of securitysame for automatic tests, TDD, etc.

“If you are working on your own, doing a few katas, or working on a small application, then yes, do whatever you like. But if you are part of bigger team developing something that is significantly bigger than a kata, you will be doing your team a favour if you paid more attention to macro design and how you structure your code”. Sandro Mancuso

Craftsmanship

Engineering

Technical debt

Henrik Kniberg

Programming language is important…

Software is a means to an end, not an end in itself

Project success - Chaos Report (since 1995)- Resolution Type 1, or project success: The project is completed on-time and on-budget, with all features and functions as initially specified.- Resolution Type 2, or project challenged: The project is completed and operational but over-budget, over the time estimate, and offers fewer features and functions than originally specified.- Resolution Type 3, or project impaired: The project is cancelled at some point during the development cycle.

Overall, the success rate was only 16.2%, while challenged projects accounted for 52.7%, and impaired (cancelled) for 31.1%.

Standish redefined what "successful" means in 2015. Previously, a successful project was on budget, on time, and on target (e.g. scope). Standish admits "on target" was never a good measure because it lacked any measure of customer outcome. They even note there are many projects that met the triple constraints, but left the customer unsatisfied. So they replaced that measure with a measure of customer perceived value. This resulted in a 7% decrease in the rate of successful projects

Surveys

https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

CHAOS report

“Methodology adopted by the Standish Group left much to be desired”:

Method of calculating the overruns was no specified

Deliberately solicited failure stories

No category for under-budget projects

Costs overruns not defined

The Non-Existent Software Crisis: Debunking the Chaos Report

http://www.erikweberconsulting.com/blog/chaos2015

http://www.drdobbs.com/architecture-and-design/the-non-existent-software-crisis-debunki/240165910

Project success studies

Surveys

How is success defined ? Is the project estimation very optimistic ?

Are you happier ?

Supervivencia un mes después de la cirugía son del 90%.

Mortalidad un mes después de la cirugía son del 10%.

Imagine we have...

Controlled environment

Statistically significant

Surveys are OK

Double-blinded (Both the subjects participating and the researchers are unaware of when the experimental procedure has happened. )

Correlation vs Causation

Ice-cream consumption and drowns in swimming pools

Police, crimes and traffic jamsThe number of crimes (per capita) has often been found to be related to the number of police officers in a given area. When more police officers patrol the area, crime tends to be lower, and when fewer police officers are present in the same area, crime tends to be higher. In statistical terms we say the number of police officers and the number of crimes have a strong negative correlation.

Traffic jam where there is police

Spurious correlations

Correlation

Correlation, as a concept, means strictly that two things vary together

Graphs can lie, not all correlations are indicative of an underlying causal connection.

A causes B; (direct causation)

B causes A; (reverse causation)

A and B are consequences of a common cause, but do not cause each other;

A causes B and B causes A (bidirectional or cyclic causation);

A causes C which causes B (indirect causation);

There is no connection between A and B; the correlation is a coincidence.

Correlation does not equal causation

That team is doing pair programming and they are doing great

Therefore pair programing makes your team be great

Cognitive biasesSesgos cognitivos

Thinking, fast and slow

Sistema 1 (rápido, automático, poco esfuerzo ),

sesgos y errores sistemáticos. pensamiento experto

y heurístico

Sistema 2 (mínimo esfuerzo, se activa por

acontecimientos que alteran nuestro modelo del mundo,

elecciones deliberadas

Facilidad cognitiva, tensión cognitiva

Estando de buen humor nos volvemos más intuitivos y creativos, pero también menos cautelosos y más propensos a errores lógicos

Facilidad cognitiva

Una manera segura de hacer que la gente se crea las falsedades es la

repetición frecuente, porque la

familiaridad no es fácilmente distinguible de la verdad

Facilidad cognitiva

Pareto principle

Pareto showed that approximately 80% of the land in Italy was owned by 20% of the population;

It is a common rule of thumb in business; e.g., "80% of your sales come from 20% of your clients." With respect to this article, 80% of the value will come from 20% of the content. Mathematically, the 80–20 rule is roughly followed by a power law distribution (also known as a Pareto distribution) for a particular set of parameters, and many natural phenomena have been shown empirically to exhibit such a distribution.

20% percent of the code has 80 percent of the errors80% of a company's profits come from 20% of its customers80% of a company's sales come from 20% of its products

...

https://en.wikipedia.org/wiki/Pareto_principle

Facilidad cognitiva

Sistema 1 salta a la conclusión, sin darse cuenta de la ambigüedad que ha resuelto, apuesta por una respuesta guiado por la experiencia. Hacemos una elección definitiva, pero no lo sabemos

Sesgos cognitivos

Sesgo de confirmación. Aceptamos sin más las pruebas que apoyan nuestras ideas mientras que nos mostramos escépticos con las que son contrarias, considerándolas parciales o interesadas

Planning poker

La discusión abierta da demasiada importancia a las opiniones de quien habla primero.

Reuniones: Antes de hablar de un asunto pedir a todos los asistentes a la reunión que escriban un breve resumen de su posición.

Bad statistics

Consider this evidence: Though it’s statistically pretty impossible, 93% of us think we are better than average drivers.

And 94% of university professors rate their teaching skills as better than average.

https://open.buffer.com/confidence-humility/

Please STOP using unproved numbers

Pair programming is only 15% time

10x 100x 1000x programmer’s productivity

Use Pareto with caution: 80 / 20

Cone of Uncertainty +-/ 4x , “telephone game”

Stop quoting Albert Einstein

... I wish my colleagues would stop quoting the “Cone of Uncertainty” as if it were something meaningful. It’s not.

Every project ever , not misleading

Fortunately we haveCommon Sense

to guide us

do we ?

Proverbs, sayings, popular beliefs

A quien madruga Dios le ayudaThe early bird catches the worm

No por antes madrugar amanece más temprano

The sun is not hurried by early risers

Don’t reinvent the wheel

https://twitter.com/McFunkypants/status/634551356930437120

No true Scotsman fallacy

Person A: "No Scotsman puts sugar on his porridge."

Person B: "But my uncle Angus likes sugar with his porridge."

Person A: "Ah yes, but no true Scotsman puts sugar on his porridge."

No true Scotsman fallacy

Person A: "Scrum is not working in our team."

Person B: "You are not doing true Scrum."

Tricky J curve

Great Wall of ChinaThe myth of being able to see the Great Wall from space originated in Richard Halliburton's 1938 (long before humans saw the Earth from space) book Second Book of Marvels said that the Great Wall of China is the only man-made object visible from the moon

Antes era sentido común:Mito del corte de digestión al bañarte después de comer

Safe

Learn from experience

http://worrydream.com/dbx/

Urgent vs Important

Urgent ? Important ?

CFO: What happens if we invest in developing

our people and then they leave the company?

CEO: What happens if we don’t, and they stay?

Capability vs Production Capability

https://jiperier.wordpress.com/2012/05/25/afilar-el-hacha-18-2/

Sharpen the saw

Is everything lost ?

Anecdotal evidence

Anecdotal evidence is evidence from anecdotes. Where only one or a few anecdotes are presented, there is a larger chance that they may be unreliable due to cherry-picked or otherwise non-representative samples of typical cases

So failing hard data, we regularly resort to anecdotal evidence. Indeed my whole career is about spreading ideas based on the analysis of anecdotal evidence. Despite its inferiority to objectively measured phenomena, it’s unwise to dismiss it. After all, how else can we learn? We learn a lot from our own experiences, but when others tell us theirs it adds a lot to our information source.

Try it by yourself

Tradeoff between critical thinking and finite time and resources.

Cristobal Colón said: The most important thing in life is to decide what are the most important things in life

Really ?Software crisis

Knowledge

Lack of Resources? Lack of Knowledge

Knowledge

“The difference between humans and other species is in what kind of knowledge they can use (explanatory instead of rule-of-thumb) and in how they create it

(conjecture and critics of ideas, rather than the variation and selections of genes)”

We’d better be prepared for change

http://waitbutwhy.com/2015/01/artificial-intelligence-revolution-1.html

AI

agile / Agile

agile (dictionary)

Agile Manifesto

Agile Manifesto

Takeaways

Never stop learning. KnowledgeCritical thinking: don’t take anything for granted

Correlation does not equal causation, Cognitive biasesAgile, Lean, Software, ... is a means to an end, not an end

in itselfAvoid long lists

Takeaways

Never stop learning. KnowledgeCritical thinking: don’t take anything for granted

Correlation does not equal causation, Cognitive biasesAgile, Lean, Software... is a means to an end, not an end in

itselfAvoid long lists

@lantoliThank you !