Agile methods and Mathematics

The Agile Brazil 2009 meeting gave me something really nice to think about (and play with).For those who still do not know, I have studied Applied Math at USP and switched to Computer Applied Math. During my earlier years at the university, I have had a mentor who had his specialization in dynamical systems and chaos.

As a programming geek, many of my early efforts at Java and bytecode compilation using Janino were to build a software that was able to run iterative methods in order to qualitatively find specific conditions in a dynamical system, that was Pulga.

An attractor

Mathematically thinking, an attractor is a set which over continuous iteration of a function f, attracts some sets in such a way that, no matter how close i want to get to my attractor, i can get, in other words there is a finite number of iterations over f which, after those iterations, the distance of the result of any following iteration to this set is lesser than the distance that i want.

This – unformal – definition of an attractor is broad enough to let me define either a point or an open set as an attractor.

An initial condition over constant iteration through the f function can lead someone closer and closer to this set (which might not be unique) but all of the sudden, after a finite number of iterations, revert its situation to something else, as a chaotic behaviour for instance.

But who is attracted? The set of points whose orbit converges to this attractor is called that attractor’s basin of attraction. This means, that whichever point your start at, if its contained in that attractor’s basin, its orbit will converge to the attractor.

Agile iterations

During the event, one of the presenters made an really interesting comment on agile iterations and iterative methods. Iterative methods can be used to find minimums and maximums of functions – either locals or globals. Non-linear programming is (hated by many students) a subject which studies those methods and most of the comments I heard were somehow connected to either this subject or simulated annealing.

In an iterative development process, one can think of the retrospective as f function, which – we believe – will improve our situation over every iteration (time). The methodology used in the first iteration is the starting condition of our system and the infinite open set of possible methodologies  is our domain.

Every time the retrospective takes place, f is applied, and we get a different methodology which will be applied. This does not mean that it will converge to a local or global minimum as it might converge to a local or global maximum. Even more complex, its orbit might converge to an attractor set which is composed by methodologies situations that we perceive both as good and bad or our project and our team’s health.

During the talk, i was in doubt on how could we tell that applying f (the retrospective), the results were better. Of course, we have a lot of subjective ideas that might give us the perception of “improving”. The presenter also told about a good way of measuring results, the velocity.

Velocity is based on perception as the importance of features for the client might not be the improvement reality for the company. The guys at globo.com told me they were using “new open bugs” and “received calls” at the support desk as a measure of improvement. It seems like the “new open bugs” approach is really good to measure quality improvement but still not so good to measure “new features capability” improvements.

Mathematically thinking, improvement itself can be temporary and “f” can be leading us to even a worse attractor as it might not yet have reached a fixed orbit (or any similar set), giving us the impression that we are better right now and surprising us in the next year, when everything corrupts.

Parallel improvement

One of the fastest ways to find such attractors is to iterate many starting conditions instead of just one. The odds of finding attractors sooner is bigger. Even better, after a specific number of iterations over f, one can combine the conditions and create different ones – “genetically modifying your conditions”.

In the development world, that would be similar to, after realizing that the retrospectives are not helping any further, grab ideas which improved other projects within your company and bring them to your project, leaving the old ones to who else wants it. This leads to even more different conditions and increases, again, the odds of finding global minimums or attractors.

Why is it interesting for you?

I was really happy to see someone talking about development processes in such a way that we can mathematically define. Although it seems not yet mature for (myself) writing papers on it, the idea of iterative methods was always close to my life, and i have never noticed how it was part of my professional life.

Its the mix of math and other areas that allows us to see how we can create and innovate the way of thinking. So far we created a lot of things with our science base, now its time to take it to another level. Iteratively improving might help myself, what about you?