A while ago, I received an interesting scientific article from Gunther Verheyen titled “Getting Things Done: The Science Behind Stress-Free Productivity” (Heylighen & Vidal, 2007). The article discusses possible scientific explanations for the success of a personal productivity approach called “Getting Things Done” (GTD; Allen, 2001). The authors apply insights from cognitive psychology and cybernetics to better understand why this approach is so effective. Although GTD is focussed on individual time management, the authors mention the potential for collaborative work. Their paper provides useful insights into why the Scrum Framework might be so effective when it comes to managing complex work. Their article inspired me to apply the same insights to Scrum and to extend it with my own.
In this post I will argue that our cognitive abilities are limited. This limits our ability to deal with complex problems. Software development is (generally speaking) very complex. Using the aforementioned cognitive limitations, I will argue that approaches based on a fully rational analysis (e.g. waterfalls) are very likely to fail. Approaches based on a more empirical (inspect-adapt) approach (e.g. Scrum/Agile) are more suitable to deal with complex problems because they are more attuned to our cognitive abilities.
What is complex work?
Before diving deeper into this blogpost, its helpful to have a working definition. A more detailed explanation can be found here. The summary is that work is complex when more is unknown than known. This involves both how well you understand problem that needs to be solved as well as the steps involved to do so. The success of complex work often depends on an unpredictable interaction between many variables. And this applies on many levels. Developing a new product requires understanding of the users, of the technologies involved and what makes something valuable (or not). Implementing a single feature in a product is often complex because it requires many assumptions about what the users like and understand, how to best use technology to make the feature possible and how skilled the people implementing it are.
Why our brain is not built for software engineering
Although our brain is a marvel of evolution, it has not evolved to excel at the kind of knowledge work (Davenport, 2005) that we actually do most of the time. ‘Knowledge work’ refers to tasks that take place mostly in our minds, like predicting scope, setting up plannings, considering consequences of changes to complex systems, working out test cases and estimating complexity. It involves activities like linking information, prioritizing, conceptualizing, analyzing data, etc. Below are some of the limitations of our brains that we have to consider.
“Although our brain is a marvel of evolution, it has not evolved to excel at the kind of knowledge work (Davenport, 2005) that we actually do most of the time.”
Limitations of our working memory
Miller (1956) identified a cognitive limitation that inhibits our ability to comprehend complex problems. Our mind is, on average, capable of maintaining seven objects in our ‘working memory’ (plus or minus two). We can usually keep track of up to seven ‘objects’ (ideas, numbers, consequences, etc) at the same time for up to 20 / 30 seconds. This is called Miller’s Law. This law is relevant because it imposes a cognitive limit to the amount of complexity we can keep in our ‘working memory’ at any one time. There are certainly mnemonics that can extend this capacity somewhat, like chunking. But even then, our capacity is limited to about 4 chunks. Of course this limitation impedes our ability to carefully consider all the variables that make work complex, because there are so many variables to keep in mind. This will affect all estimates and predictions.
Limitations of attention
Attention is the process of selectively concentrating on one aspect while ignoring other aspects. It is a mental process and a limited mental resource (Ashcraft, 2002). When performing difficult tasks, attention is required. This implies that other tasks cannot be given attention. Humans are not good at multitasking at all. In fact, switching attention between two (or more) tasks tends to double the time needed for individual tasks and increases the number of errors (Rogers & Monsell, 1995). So, answering your mail and writing some code at the same time is going to decrease productiveness. Of course this limitation impedes our ability to carefully consider all the options that make work complex, because a lot of attention to detail is required in this case. This will affect all estimates and predictions.
Limitations of our decision-making abilities
The limited capacity of our working memory and our attention are some of the reasons why most economists and psychologists consider our brains as generally not very good at making accurate predictions and decisions. Instead of basing our decisions on a full rational analysis of all the available data (rational choice theory, Becker, 1976), we make sub-optimal choices. Our minds are bound by cognitive and other limitations (bounded rationality, Herbert, 1957). In a practical sense, this is why we are not good at detailing scope for a project upfront, consider consequences of changes and estimate the time it will take to complete tasks. This might all be possible when our minds would work like a computer (and has full information). But our brains have not evolved for this kind of work. Instead, our brain has evolved to make quick, knee-jerk decisions based on the immediate environment. Instead of applying full rational analysis, we use heuristics (simple rules) to make decisions. Examples of these heuristics are ‘what do other people think?’, ‘what is my gut estimate?’ or ‘what do similar experiences tell me?’. In fact, simple heuristics can actually lead to better, quicker decisions than theoretical optimal procedures (Gigerenzer, 2002).
Limitations of thinking
Despite what you might think, humans are not great thinkers. Most of us find it very hard to concentrate on the train-of-thought necessary for continuous thought. Nevertheless, the motto of software development is often ‘first solve the problem, then write the code’. This implies an active thinking phase, which is subject to (among others) the limitations mentioned above. But there is another limitation; thinking itself.
Have you ever wondered why, when thinking, you find yourself scribbling notes down on a paper to help you think? According to cognitive psychologists, this is because our minds require interaction with a real environment to help it think. This is called situated cognition (Clark, 1997). According to this theory, we think not by manipulating symbols in an entirely internal process in our mind, but by iteratively performing small actions in our environment which, in turn, lead to new thoughts and actions. Simply speaking; the act of writing your thoughts down (or capturing them in some other way) and perceiving them again helps us think and come up with new ideas. In this case, we use our environment as an extended mind and offload a lot of the memorizing and thinking to a more reliable and less energy-consuming external memory. This frees our limited minds to consider new actions and thoughts.
A good illustration of this point is made by the Danish architect Bjarke Ingels. In the documentary ‘The Creative Brain’ , he explains how, at his firm, they switch to physical and tangible materials as quickly as possible while designing buildings. Rather than spending a lot of time with drawings and computer-generated models, they’ve found that when people have physical objects to touch, pick up and turn around, more ideas are generated. This is a great example of situated cognition.
How to handle our limited brains?
We have identified some important cognitive limitations of our brain. Despite it’s evolutionary marvel, our brains are not optimized for heavy-duty ‘knowledge work’, where the primary effort of our work lies in thinking, analyzing, estimating, prioritizing and planning. Even so, we still have to deal with complex problems. So, what can we do?
- Optimize for heuristics: because we are not capable of full rational analysis (not accurately, at least), we should not try to analyse, predict and plan everything upfront. This will not work. Instead, we should optimize our work for the rapid application of heuristics (Gigerenzer, 2002). It’s better to hit the ground running and inspect frequently than spending valuable time trying to overthink everything;
- Continuous feedback: because we use heuristics to drive decisions, our process should be optimized to provide us with continuous feedback to evaluate the success and accuracy of those heuristics. This allows us to correct for deviations, learn from mistakes and improve our heuristics;
- External memory: to accommodate our limited memory, we should create environments that encourage situated cognition by creating physical traces of those memories in our environments (e.g. stickies, models, posters, flips);
“Because we use heuristics to drive decisions, our process should be optimized to provide us with continuous feedback to evaluate the success and accuracy of those heuristics.”
Together, these three considerations accommodate a process called self-organization. And this is where Stigmergy comes in.
Feedback, stigmergy and self-organization
In a sense, we often use our environment to leave ‘traces’ to further our own thinking. This is where the cybernetic concept of feedback control is useful (Heylighen & Vidal, in press). According to Wikipedia, feedback control is:
Feedback is a process in which information about the past or the present influences the same phenomenon in the present or future.
In cybernetics, a feedback system is always trying to minimize the difference between a desired and an actual state. Consider a thermostat. If an apartment thermostat is set to 21 degrees Celcius, it will begin heating the apartment when the temperature falls below the intended temperature. It will periodically measure temperature and turn itself off when the intended temperature has been reached.
And what does this have to do with offloading human thinking to our environment? Heylighen & Vidal (in press) argue that the feedback control loop that is prevalent in situated cognition helps us think about complex problems by constantly performing small actions and evaluating their results (trial-and-error). If we have not reached our intended goal (the solution), we will attempt further actions that will probably decrease the distance between the intended and the actual result. In other words, our thinking is one big feedback control loop where we perform actions in the world, evaluate them and determine our next action.
Stigmergy and stigmergic action
So, with our situated cognition, we recognize that thinking is not something that takes place in our minds exclusively. Instead, we include our environment as external memory and to aid our thinking (Heylighen & Vidal, in press). In the terminology of cognitive psychologists, we leave traces in our environment that we or others can pick up on to stimulate next actions.
A powerful example of the above can be witnessed in termite colonies (Camazine, 2003). Although individual termites have very limited cognitive abilities, the behavior of the termite colony as a whole appears to be quite intelligent. Together, termites construct complicated nests, with arched corridors and a variety of specialized rooms. Termites achieve this by leaving small traces of pheromones for other termites. In turn, this stimulates these termites to perform next actions. This is a form of swarm intelligence; although individual agents have limited abilities, the simple act of following a simple set of local rules allows them to solve very complicated problems. Without strong top-down (or rational) control.
Stigmergy can also be witnessed in human organizations. Good examples are wikipedia and open-source projects (Heylighen, 2007). The individual agents (people) perform small tasks and leave traces (commits, ideas, bug reports) that are picked up by other agents. Together, they are capable of building free encyclopedia’s, kernel’s or frameworks. All examples of very complex work. This, again, is achieved without a (strong) top-down control structure.
Of course, the quality of the traces left behind by individual agents predicts the quality of the next action (taken by the same or another agent) and the quality of the stigmergy as a whole. Within the context of me writing this post; the quality of my notes determine if I will pick up on them later or ignore them. Maybe I failed to capture a novel idea in a note, which propably means I will fail to see the point of the note in the future and skip it.
A trace is considered of quality when it is ‘actionable’ (Heylighen & Vidal, in press). That is; the trace is specific enough to basically necessitate the next action (a stigmergic action). So, again, in the context of this post, a good trace would be ‘Write conclusion by tying together insights with Scrum’ instead of ‘Finish post’. Only the first specificies what I have to write about. A stigmergic action is so self-explanatory that another agent can pick it up and execute it, resulting in potential new stigmergic actions.
Cognitive paradigms, applied to Scrum / Agile
Scrum presents a very different paradigm to managing complex work. Instead of top-down control (through planning and upfront designs), Scrum allows control through self-organization and very frequent feedback control loops.
When a Scrum Team starts work on a Sprint (e.g. 2 weeks), they begin by selecting work from the Product Backlog that is necessary to achieve the goal for that Sprint. Instead of a full rational analysis of the required work, Scrum Teams capture the essence of the work in short ‘Product Backlog Items’ on an ordered Product Backlog. Instead of using the Product Backlog as a form of documentation and knowledge transfer, it is used to facilitate communication and stigmergy within the Scrum Team. As such, it can be considered an external memory that contains traces (actionable items) that aid a Scrum Team in their own thinking process but does not attempt to replace it.
How much work can be done in a Sprint is uncertain and unpredictable. Rather than using detailed rational analyses, teams instead rely on rough indicators like story points, other forms of relative estimation or simply gut feeling. This is an intentionally heuristical approach to allow teams to quickly discuss and select work to populate a Sprint Backlog. The only way to learn about what is actually needed, is by doing the work. Although this admittedly rough and imprecise, Sprints allow many opportunities for teams to evaluate their progress and adjust as needed.
During the sprint, Scrum Teams communicate progress and synchronize their work through the Sprint Backlog (often visualized on a Scrum Board). It contains all the items that are needed to achieve the goal of the Sprint. Because the items are simple (usually only one sentence), and with only a few details (acceptance criteria and specific examples), they can be considered as actionable traces. In a sense, the Sprint Backlog represents the external memory of a team during the sprint. It also helps the team think during the sprint. The simple act of pulling items through the a workflow of ‘todo’, ‘in progress’, ‘test’ and ‘done’ causes new actions to be initiated (‘ok, this is done, so it has to be tested now’ or ‘this item is too big, let’s split it up into tasks’). The Sprint Backlog is also a locus of stigmergy; as members leave traces of their work (new items, changes in status), other members can pick up on those traces. In effective Scrum Teams, members simply look at the Sprint Backlog and pick up the tasks that are suitable for them, instead of someone assigning the items to them. This is a good example of self-organization and stigmergy. Teams distribute their own work and, through the synchronized actions of individuals, complex problems are solved. This also gives credibility to the idea of using physical boards, instead of hiding the external brain in a tool like JIRA.
“This also gives credibility to the idea of using physical boards, instead of hiding the external brain in a tool like JIRA.”
During Sprints, Scrum Teams periodically evaluate the progress. They do this at the end of a sprint, during the Sprint Review and the Sprint Retrospective, and every day, during the Daily Scrum. These moments serve as important feedback control loops. Because there is no top-down control and no detailed plan, teams constantly evaluate the progress together. This allows them to (safely) experiment with new functionality and determine if the end goal is still reachable or if adjustments need to be made.
“The biggest difference with traditional approaches is that the Scrum Framework allows teams to think by Sprinting instead of thinking upfront (and suffer all the cognitive limitations).”
The biggest difference with traditional approaches is that Scrum implements a process that allows a team to think by sprinting instead of thinking upfront. This offloads a lot of thinking and memory capacity to the process itself. The sprints, the Product Backlog and the Sprint Backlog act as aids in the situated cognition of the team. This in-process-thinking stimulates the creation of a ‘Team Mind’ that allows sharing of knowledge, instead of big design documents that attempt (but fail) to achieve the same goal. As such, the stigmergy that is apparent in Scrum’s iterative approach is a more effective means to manage complexity. Instead of trying to comprehend everything upfront, teams continuously re-organize, learn, think and adapt to get the work done and improve their own process. As such, the Scrum Framework is a much better fit with our limited cognitive capabilities when it comes to comprehending and managing complexity.
In this post, I applied insights from cognitive psychology, cybernetics and human factors to explain why Scrum is a more effective approach to dealing with complexity compared to traditional approaches. The bottom line is that our cognitive abilities are limited. We cannot fully comprehend the full complexity of a complex problem. Our brains have not evolved to do so.
The Scrum Framework provides a more useful alternative because it supports our cognitive limitations. It promotes the use of heuristics to make quick decisions. But it also implements strong feedback control loops to inspect and adapt the process and correct deviations as they happen. By following a few simple rules, Scrum allows for self-organization (or stigmergy) to happen in teams. Self-organization is apparent all around us (from termite colonies to wikipedia and open source projects) and shows an alternative, more natural way, for controlling complexity and solving complex problems. And the Scrum Framework is an excellent example of this.
- Ashcraft, M. H. (2002). Cognition, New Jersey: Prentice Hall;
- Becker, G.S. (1976). The Economic Approach to Human Behavior. Chicago: University of Chicago Press;
- Clark, A. (1997). Being there. Cambridge, MA: MIT Press;
- Davenport, Thomas H. (2005) Thinking for a living. Boston: Harvard Business Press;
- Gershenson, C. and Heylighen, F. (2004) _How can we think the complex?Retrieved from http://cogprints.org/3439 on December 17, 2012;
- Gigerenzer, G. and Selten, R. (2002). Bounded Rationality. Cambridge: MIT Press;
- Heylighen, F. and Vidal, C. (2007): Getting Things Done: The Science behind Stress-Free Productivity. Retrieved from http://cogprints.org/6289 on December 17, 2012;
- Heylighen, F. (2007). Why is Open Access Development so Successful? Stigmergic organization and the economics of information. In B. Lutterbeck, M. Bärwolff & R. A. Gehring (eds.), Open Source Jahrbuch (2007). Retrieved from http://www.opensourcejahrbuch.de/download/jb2007/osjb2007-02-04-en-heylighen.pdf on December 17, 2012;
- Heylighen F. & Joslyn C. (2001): Cybernetics and Second Order Cybernetics, in: R.A. Meyers (ed.), Encyclopedia of Physical Science & Technology, Vol. 4 (3rd ed.), (Academic Press, New York), p. 155–170;
- Rogers, R. & Monsell, S. (1995). The costs of a predictable switch between simple cognitive tasks. Journal of Experimental Psychology: General, 124, 207–231;
- Simon, Herbert (1957). A Behavioral Model of Rational Choice, in_Models of Man_, Social and Rational: Mathematical Essays on Rational Human Behavior in a Social Setting. New York: Wiley;
- Camazine S., Deneubourg, J, Franks, N. R., Sneyd, J. (2003). Self-Organization in Biological Systems (2003) New Jersey: Princeton University Press;