I’m going to present you something obvious. Why? I think that obvious gets often dismissed exactly because it’s so common. However, understanding and defining it more sharply allows us to not dismiss it, and use it as a useful tool for analysis and reflection. Everywhere.
Let’s start with some example. The computer modeled upon Von Neumann’s architecture is basically a black box with a CPU and a memory that processes an input an returns an output, iteratively. The user centered design process in the ISO 13407 standard is a four phases loop: specify context, specify requirements, design solutions, evaluate. The problem-solving approach of Action Research is split in three iterative phases: plan, action and result. Agile methodologies have the concept of sprint, where you start with a sprint planning, you do a few days of development and then you end with a retrospective. Looking at a different discipline, in biology many systems are based on the concept of stimulus, elaboration and reaction, where in an amoeba we have a chemical process while in a cat the whole loop is mediated by the nervous system. The embodied cognition explains that the process of knowing is a loop between behavioural interaction and perception, between the action on the environment caused by a motor system and the perception of that same environment by a sensory system. In the nervous system you can easily see the same pattern again in each and every neuron, and within the neuron in every synapse and down to every chemical receptor. In cybernetics you have the analogous feedback concept.
Did you notice the commonalities? Once you start seeing this pattern, it’s recurring everywhere we look, even in extremely different disciplines and scales.
Let’s review these commonalities:
- they are all loops, no inherent ending
- they can be all synthesized in about three phases
- they exist at very different scales, often one inside the other (think about the loop of a living organism and the same loop of its own cells).
- every loop is short, in its own scale and context
The Dot Loop
We can abstract all these common parts identify the “Dot Loop”: do, observe, think. This loop exists everywhere you see something that works.
Why is this important? For three reasons:
- It’s a baseline for processes: any process you are going to use or build needs to have those three levels, nothing less than those, like a dot in geometry.
- It’s a validator for processes: if the process you are looking or the one you are building is missing one of those steps, then something is either wrong or hidden behind something. If it’s hidden, it’s better to understand why and make it more explicit.
- It’s the minimal building block: you can’t have nothing less than this, but also if you have something right like this then you need to go deeper, because it’s not enough, it’s too abstract and needs to get practical. For example you can say that one phase is “Design”, but unless you know how you are going to do that (card sorting, wireframes, visual layouts, prototypes) then it’s too abstract to be useful.
It’s very interesting because it’s something that inside a process can be repeated multiple times at multiple levels. Think for example the sprint in the Scrum Agile process: at the top level you have the building of a software: the client asks something, the team builds it, and it gets released back to the client. But inside that very high level (and not very useful) explanation you have a lot of iterations, again matching the Dot Loop, and inside each one of those each user story is prepared, developed and accepted. Again a Dot Loop.
Notice also that the starting point isn’t fixed. You might think that a project starts with the Observe phase, or analysis. But from another point of view, the clients starts with a request, so it’s a Do phase. And usually you can go back the loop more and more, without being able to define a starting point.
Notice also that in every following iteration each phase can do different things: for example the Observation phase at the beginning could refer to the business scenario, in the middle could refer to user interaction testing and in the end it could be the feedback from the users.
Example: Agile & Scrum
The Agile Manifesto explains the four core elements of the discipline: individuals and interactions, working software, customer collaboration, responding to change. Even from this point of view, you see that a Dot Loop process intuitively matches Agile.
If we take the Scrum methodology alone we can get into some details and see that a single sprint is exactly a Dot Loop:
- the sprint planning: Think
- the sprint itself: Do
- the sprint review and retrospective: Observe
But also, if we look inside the Do phase, we notice that the developers are:
- designing the solution of each user story: Think
- coding the tests and the solution: Do
- testing the solution: Observe
It’s obvious now, right?
Of course, if you go even more in depth things start getting a whole more complicated, but if you are doing things right, you are still working in different Dot Loops at different abstraction levels. Jacopo Romei, an Agile coach friend of mine, modeled the agile process as a sequence of feedback loops in its Software Feedback Loop, I think that’s an interesting higher-level perspective.
Some other examples
But how can something so obvious be useful for you? You don’t have to be a business engineer to use this simple and basic concept. Managers, designers, developers, and many more can apply the Dot Loop to their own field.
Think about a company starting to deploy a new intranet. In a typical scenario, it’s going to choose the technology, building the service and then releasing it one day with a communication through mail. As you can see, it’s missing a critical step that’s easily spotted once you see this through the Dot Loop: there’s no feedback, no following Observe phase after the release and probably not even tests with final users during the development of the application.
Another good example is made when companies see the new world of social media and start to use them straight away, creating pages on Facebook, accounts on Twitter and starting to push content through them. Even if the loop goes on, it’s missing the Think phase in between, that would have aligned the company strategy with the correct communication.
Think about the typical waterfall model, that leads so often to mediocre products. This basically happens because it’s like making one single Dot Loop, instead that taking the output feedback from the Do part and analyzing it to perform a following new action. Even when the feedback is take into account, often it’s just “check if we reached our objectives” and nothing after that. Instead creating a virtuous cycle is the correct way to both solve problems and evolve existing solutions.
If you want to build or evolve a social network the biggest error is going to be to start developing it assuming a specific behaviour of the users, but this rarely happens. You need to plan a social network in a sequence of iterations where you check what’s going on and adapt each step to the community evolution that surely happens each time.
You probably don’t have to look around much to see companies and consultants that are proposing their own “magic” process. With the Dot Loop you can have a first insight if they are saying something worth listening, or not: is there a missing step in the process? Flawed. Is it not a loop? Flawed. It stops with the three steps? Too shallow. It has these three steps, or more steps that could be synthesized in Do, Observe, Think and they go in-depth describing what they do in each one of them? Great. They probably have something.
Notice also that sometimes this knowledge can be hidden. I’ve seen once a company that was delivering high quality products, but its formal model was waterfall. In the end it was again a Dot Loop – very similar to agile – but placed inside a structured process that in the end was just a logical explanation, not a process by itself.
As you might guess, the list could go on a lot and every one of those problems could be avoided understanding the Dot Loop, since it’s the minimal possible process.
Other “Dot Loops” variations
- “Build, measure, learn” (2010) E. Ries
- “Probe, Feedback” (2015) C. Bargmann, et. al.
- “Scan, focus, act” (1996) J. Channon, F. Burns, L. Nelson.
- “OODA: observe, orient, decide, act” (1976) J. Boyd.
- “PDCA: plan, do, check, adjust” (1959) E. Deming, W. A. Shewhart, S. Mizuno.
This was originally a shorter post for the Headshift blog (14 Dec 2010).