24
Why agile works? Andres Kütt RIA / State Information System Architect 20.11.14

Why agile works

Embed Size (px)

DESCRIPTION

A deck supporting a speech at TopConf Tallinn 2014 on modelling software projects and our mental models of software.

Citation preview

Page 1: Why agile works

Why agile works?

Andres Kütt RIA / State Information System Architect

20.11.14

Page 2: Why agile works

We perceive the world via mental models

We also use them to make predictions about the future

Page 3: Why agile works

These models are inaccurate

Page 4: Why agile works

Because humans are not perfect

Contrary to what you might think about yourself

Page 5: Why agile works

Because accuracy does not guarantee social success

Galileo had a very accurate model of the universe that also made him very unpopular

Page 6: Why agile works

Because math gets too complex

Non-linear and chaotic processes, the three-body problem, etc.

Page 7: Why agile works

This is a three litre Bag-in-Box of Sacrifice Shiraz Red Wine. Drink responsibly!

Page 8: Why agile works

Can we find tempty based on S0 and g?

gS

S

Page 9: Why agile works

The exponent will never reach zero

Page 10: Why agile works

Yet we get the physics for this in high-school

Our mental model is not accurate enough

Page 11: Why agile works

What else might we get wrong?

What about our mental model of software projects?

Page 12: Why agile works

About the computational model used

! Shape is more important than size ! The idea is to model behaviour, not give precise numbers

! The same sort of bathtub-based logic is used ! A lot can be built by simulating interconnected baths ! Look up system dynamics, if you are so inclined

! It has been validated ! Not published but supported by research ! Makes a lot of intuitive sense

Page 13: Why agile works

Let’s get to it

Page 14: Why agile works

The simple model Let our base project be a project with 100 tasks. The team size is 200 people, each of whom can accomplish 0.005 tasks per week, this leads to…

20% of mistakes and reasonable assumptions on additional work

Page 15: Why agile works

Whoops, a 2.25 times longer project emerged by allowing mistakes (20%) and allowing them to cause additional work. Of course, the relationships are more subtle but they are way too geeky to explain here. The deconstruction rate depends on how much of the project is done: it is 0 for about 50% and grows to 1 (in the later phase, as much of effort goes into deconstruction as into rework) as the project progresses.

Page 16: Why agile works

Team churn, turns out, does not have a significant impact

Page 17: Why agile works

Projects are not linear

Not on a large scale. But agile works on much smaller timescales

What is the main assumption that we have made in this modelling thus far? We test all the time. What if this is not the case? Let’s look at typical waterfall.

Page 18: Why agile works

no testing before 30% of project duration. Which turns out to be a 25%.

Page 19: Why agile works

The sooner you test, the better

In agile, testing starts immediately

Page 20: Why agile works

The importance of skilled workforce. Decreasing the error rate is 1.5 times as beneficial than allowing it to increase

Page 21: Why agile works

Incompetence is really bad

Agile breeds and needs competence

Can agile only be done properly by such competent folks who would succeed regardless?

Page 22: Why agile works

Effects of learning will be over- and bad HR under-estimated

Decreased error rate will have a much smaller impact than increased error rate

Page 23: Why agile works

The basic structure of the model used

Page 24: Why agile works

Thank you!

Andres Kütt [email protected]