Energize your team: analogy between agile teams and lasers

Electricity, magnetism and time are tightly intertwined. You can try to work separately with them but that will not give you the whole picture. While if you consider the dynamic relation between all three, you can do magical things. For example, you can “bounces” electrical energy back and forth into magnetic energy resulting in alternative current, which magically almost avoiding the need to actually carry “real current” (which is expensive). Or you can “juggle” these energies while moving forward, and thereby creating photons and light.

In project management, tasks, resources and time are also tightly intertwined. You can try to work with them separately but again at risk of being inefficient.  It is a bit of a stretch to compare project management with electromagnetism, yet it is intuitively pleasing. In electromagnetism, work is created by “applying” electrical currents and magnetic fields on each other. In project management, work is creating by “applying” tasks and resources on each other.
I could argue how a waterfall process is comparable to an electrical motor with a rigid physical setup to maintain a well-calibrated cross product between the magnetic field and the flow of currents, but instead I would like to focus on the photonic aspect of light and how it can be compared to an agile process.

Here is the idea: a photon of light is a “self-encapsulation” (wavelet) of oscillating electrical and magnetic fields. (I am not a physicist, so please excuse an abuse of interpretation here). Comparing this to a work process, the photons can be seen as agile work cycles that are “bouncing” between defining the tasks and applying the resources on them. Every cycle of an agile process (e.g. Scrum), can be seen as the photons running through a single frequency cycle.

Agility is the ability to “bounce” your energy between “defining” tasks and “doing” tasks. Stretching the analogy a bit, you might say that the repetition of each agile iteration (or sprint) and with its generation of client deliverables and new future tasks, is a bit like a laser where photons “hit” energized states and generate new photons. The beauty of this analogy is that we can all “feel” how the coherence of light produced by a laser is somewhat similar to an agile team efficiently bouncing past results and knowledge into the definition of new tasks, and then efficiently executing these tasks within an agile iteration.

The laser analogy goes even one step further: lasers produce light that usually goes all in the same direction with the same frequency. If you are very lucky and your product backlog is very much aligned with what the customer needs and your past work always matches up with your new needs, then yes, you too can have a “laser” agile team that goes straight and coherently over your tasks to your goals. But, if your backlog needs to undergo changes (e.g. because there is important new information to interpret), or if you have made mistakes (and we all do!), then this focus on coherence and “straightness” is actually a great risk: a “laser” like team may well end up with the wrong product and possibly with the wrong technology. Again, the issue is that if you try too much to make your new tasks match up with your previous work, you end up going straight, but not necessarily in the right direction. And although the product owner may realize that something is amiss, it is not easy to understand what. One reason is that the team does not understand that it could turn away from an obvious “coherent and straight line” future, and therefore may never indicates to the product owner that the future could be different. Another reason to by wary, is that being a “laser team” feels good: it is great to feel tasks fitting together with marvelous coherence, it is great to have a fantastic history of “little refactoring”. Yet that great feeling is also blocking the team from questioning its actions, because that “would not feel as good”. Without enough self-questioning the team is too much influenced by its previous actions and may end up elsewhere than desired.

So what should a team do about this? The thing is, if you are aligned with your long-term goals, then following the feelings of coherence and alignment is the right thing to do. It is only if you are not aligned with your goals that you are fooling yourself. The product owner is therefore key here: he or she must work hard so that when the team feels that everything is fitting together, the team is also going in the right direction. Said differently, the product owner’s or product manager’s primary job is not to check that the team is aligned, but to ensure that when the team feels “right” it is also going in the right direction. To use the laser image again, the product owner wants to assure that work will be aligned with the overall goals at the creation of each photon. He/she cannot do so by physically controlling each creation and execution of task because that would simply not scale. Instead the product owner strives to provide a “higher level” guidance that ensures this alignment. In scrum, this is why the stories are not tasks. In practice good product owners evangelize their teams so that they “see the goals” and therefore produce tasks that are aligned.

Lasers work because the materials are in “energized states”. Pushing our analogy all the way, (and using scrum), we can say that the product owner energizes the team in such a manner that when the team creates and implements tasks, in a coherent and aligned manner, these tasks are also directed towards the product goals.

Who wants to work with clunky electrical motors when we can all have high-powered laser devices?

Two algorithmic trading software requirements

This blog post is about two basic requirements when asking developers to write a very fast algorithmic trading systems.
Designing fast system seems initially an easy task. You hire developers that are in touch with the physical nature of computers and networks. And you ask them to write fast code.
Nevertheless, there are difficulties. The first is that allocating and freeing dynamic memory slows you down, so ideally you want to do without dynamic memory. Yet developers usually have a hard time with this requirement. One reason that developers are insecure in doing this is that they have been brought up with languages that only work with dynamic memory. The other reason is exactly the language issue: modern languages do not make it easy to program without dynamic memory allocation. Therefore it is best to present this requirement differently, in a form that is much easier to swallow, which could be as follows:

Make sure to preallocate your dynamic memory before activating your algos, and minimize any later reallocation.

Now this first request seems a bit heavy because it tends to use a lot of memory and brings the code back thirty years. Yet, as you expect your very fast system to make lots of money, you need to start by assuming you have no limits to you infrastructure costs, and are willing to pay for terabytes of memory if needed. In addition, languages like C++, with a wise use of templates, or functional languages with mutability (like Ocaml or F#), can actually do a good job with this requirement. More importantly, this requirement leads me to the next requirement, but first I need to repeat my “motto” in trading, which is:

"It is easier to make money than to keep it".

Which leads me to remind you that there are two very distinct activities in trading: making a profit and trying to prevent a loss. This may sound pretty trivial, but it is a key concept, and not all developers understand it. (I have reviewed enough trading code to know that). What it means to an algo system is that as much effort and thinking must be put in the code that actively tries to make money as in the code that actively tries to prevent losing money. As a requirement, I would state it as:

Given that trading algos can be in three different states: profit making, idle, and preventing loss; Put as much effort and optimization in the transitions from each of these states to another as you put in staying within each state.

Said emotionally:

I want no delay when I slam my foot on the brake or on the gas pedal!

If you have written a few complex real time systems, you may realize that this is not a trivial requirement. And in fact, it is even harder to implement than the first requirement. But I can tell you that it is easier to achieve if you also worry about the first "no dynamic allocation" requirement.

All original content copyright James Litsios, 2013.