Since many readers of this site come from an IT background, it is probably safe to assume that many graduated with a computer science degree and/or taken computer programming classes. One big topic in that field is how to loop through a sequence of data points continuously that either terminates or branches in another direction based on a selection criterion. One way to do that is iteratively and another is recursively.
Both methods come out with the same solution, but the means in which they do so is quite different. When you iterate, you set the number of loops and circulate through them until the set number is exhausted. When you recursively loop through it, you set a base condition and have the functional call itself until it reaches the base condition and terminates. This is not a computer science post, so I won’t dive into details or nuances of these approaches, but for the sake of this post in terms of project management, Agile as you all know is focused on iterations but what about recursion?
While there’s a clear dichotomy about iterating though a loop as opposed to recursively circulating through it in computer science, I will argue that how we plan and execute an Agile iteration, though on paper looks iterative, is entirely recursive from the cognitive perspective. We do not think in nice linear sequential iterations, but rather recursively loop through thoughts within thoughts were past and present meld through memory to make assertion about the future.
No better example of this than a passage from Marcel Proust’s incredible novel “À la recherche du temps perdu” (English: “In Search of Lost Time”) in the very first volume titled “Sway’s Way” where the protagonist of the story tastes a piece of madeleine cookie dipped in tea:
No sooner had the warm liquid mixed with the crumbs touched my palate than a shudder ran through me and I stopped, intent upon the extraordinary thing that was happening to me. An exquisite pleasure had invaded my senses, something isolated, detached, with no suggestion of its origin. And at once the vicissitudes of life had become indifferent to me, its disasters innocuous, its brevity illusory – this new sensation having had on me the effect which love has of filling me with a precious essence; or rather this essence was not in me it was me. ... Whence did it come? What did it mean? How could I seize and apprehend it? ... And suddenly the memory revealed itself. The taste was that of the little piece of madeleine which on Sunday mornings at Combray (because on those mornings I did not go out before mass), when I went to say good morning to her in her bedroom, my aunt Léonie used to give me, dipping it first in her own cup of tea or tisane. The sight of the little madeleine had recalled nothing to my mind before I tasted it. And all from my cup of tea.
There can be and has been multiple ways to interpret this from a deep philosophical, psychological and literary perspective, but for my purpose this passage highlights the fluidic, dynamic and recursive nature of how human’s loop through thoughts recursively that is juxtaposed from past episodic events to formulate in present time our future direction. Past, present and future move as one in a complex but orchestrated melody of consonant cognitions that allow us to plan our actions.
I think this is why our project plans never quite adhere to the plans in our thoughts because they are static and permanent, whereas life and thoughts are dynamic and constantly in flux. This is profound and paradoxical yet intriguing… something to ponder and explore again (and again).
What are your thoughts? More importantly, did you arrive at them sequentially, iteratively or recursively?
Good post, Don, this is a good, literary example of the complexities of dealing with humans and the need to work through systems thinking and understand the role that variation and behavior play in developing and executing projects. Quite possibly the first time I've been able to relate the writings of Proust.
It is really quite interesting and thoughtprovoking.
1. Some problems are better solved iteratively and some are better solved recursively.
In agile when you put together the potential shipable increments into a customer release I would say you do a combination of both. You have the goal to achieve the release and therefore a definite number of increments and also the base condition, that the customer is not satisfied with the increment and thus can stop the recursion.
2. Additionaly I would say that as long as you have no science degree in mathematics or computer science the concept of iterations is easier to understand than the concept of recursion. So while its hard to get agile into the world of projects it is easier to keep the concepts simple.
3. The idea of relating the topic to Proust is excellent! Thank you for sharing.
I generally like Don''s articles, and it''s good to see someone thinking deeply about these things, or even you might say philosophizing about them, but I find the recursive/iterative distinction unconvincing in the context of agile project management. The article says "I will argue.." but then presents no discernible arguments in support of the thesis.
Sometimes iterations are just iterations, i.e. successive boxes of time. In that sense, they cannot be recursions, and in fact are not. How we think about our tasks is another topic entirely, but nobody claims that is iterative in nature any more than it might be recursive, as Don asserts.