Why agile works
2 likes890 views
Agile project management works because: 1) Mental models of software projects are inaccurate since they are complex and non-linear. 2) Agile allows for more frequent testing which improves outcomes, as testing early catches many errors. 3) Competent teams are key to agile success since they have lower error rates, which impacts outcomes more than decreases in errors. Frequent testing and competent teams help agile adapt to the unpredictable nature of software projects.
Why agile works
- 1. Why agile works? Andres Kütt RIA / State Information System Architect 20.11.14
- 2. We perceive the world via mental models We also use them to make predictions about the future
- 3. These models are inaccurate
- 4. Because humans are not perfect Contrary to what you might think about yourself
- 5. Because accuracy does not guarantee social success Galileo had a very accurate model of the universe that also made him very unpopular
- 6. Because math gets too complex Non-linear and chaotic processes, the three-body problem, etc.
- 7. This is a three litre Bag-in-Box of Sacrifice Shiraz Red Wine. Drink responsibly!
- 8. gS S Can we find tempty based on S0 and g?
- 9. The exponent will never reach zero
- 10. Yet we get the physics for this in high-school Our mental model is not accurate enough
- 11. What else might we get wrong? What about our mental model of software projects?
- 12. 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
- 13. Let’s get to it
- 14. 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
- 15. 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.
- 16. Team churn, turns out, does not have a significant impact
- 17. 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.
- 18. no testing before 30% of project duration. Which turns out to be a 25%.
- 19. The sooner you test, the better In agile, testing starts immediately
- 20. The importance of skilled workforce. Decreasing the error rate is 1.5 times as beneficial than allowing it to increase
- 21. Incompetence is really bad Agile breeds and needs competence Can agile only be done properly by such competent folks who would succeed regardless?
- 22. Effects of learning will be over-and bad HR under-estimated Decreased error rate will have a much smaller impact than increased error rate
- 23. The basic structure of the model used
- 24. Thank you! Andres Kütt andres.kutt@ria.ee