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?
No comments:
Post a Comment