In the Campfire Talks with Herbie No 26 Clarke Ching told how he works with Agile and the Theory of Constraint. An interesting parallel that I wanted to draw is to better outline how the TameFlow Approach relates to Agile.
During the years since the Manifesto for Agile Software Development was authored, the very notion of “Agile” has evolved and nowadays has so many interpretations that it is hard to pinpoint and agree on what it really means. To try to bring some sense to our discourse, we will distinguish between four aspects of contemporary Agile:
- The Manifesto for Agile Software Development
- Agile as the philosophy of soft skills
- Agile Management
- Business Agility
TameFlow and the Manifesto for Agile Software Development
It is a reasonable position to claim that any true adoption of Agile must be coherent with the four Values and twelve Principles of the Manifesto for Agile Software Development. And if you want to have a deeper perspective of who contributed to that, see Alistair Cockburn’s web-archived post How I saved Agile and the Rest of the World.
While we recognize the absolute importance of having shared values and principles at the foundation of the social interactions that happen between individuals within the company (and also with actors outside of the company), in the TameFlow Approach we sustain that such values and principles must emerge from within the organization itself. If they are imposed from the outside - even by referring to a manifesto with laudable intent - it will still be an imposition, and much less effective than what can and should be developed and nurtured on a daily basis within the organization itself.
It is noteworthy that the majority of the signatory of the Manifesto were actually exponents of eXtreme Programming (XP); and XP comes with its own set of Values. As I recently wrote (inspired by the recent Campfire Talk with J. B. Rainsberger) in the post eXtreme Programming and the TameFlow Approach, the XP Values map quite nicely to many elements you find in the TameFlow Approach. Even so, it does not mean that we adopt the values of XP. The way to look at it, is that the TameFlow Approach supports the adoption of those values, should you decide to refer to them yourself. In general, with the TameFlow Approach we encourage companies to develop their own sets of Values and Principles.
The TameFlow Approach and “Agile”
Here I write “Agile” within quotation marks to represent all the attempts at somehow codifying and interpreting what was originally exposed in the Manifesto for Agile Software Development in all sorts of directions, resulting in “manifestations” (pardon the pun!) of things like Scrum, SAFe, Business Agility, and many, many more variants.
Most of these approaches result in the trivialization, gamification, socialization, and infantilization of what was written in the original manifesto. Agile is being turned into a kindergarten of sorts for adults.
One common trait of these developments is the nurturing of anti-management sentiments. This originates from the very intentional and deliberate design of Scrum.
The quintessential original function of the Scrum Master was to “protect” the team from all nasty managers. It was highlighted by the Chicken and Pigs metaphor, which nowadays is no longer politically correct - and has in fact been removed from the Scrum literature. But the priming, intent and actuality remains there unchanged. With this, Scrum promotes a divisive toxic culture of “us vs them” where “them” are basically anyone outside of the team or anyone who does not subscribe to the “credo” and did not drink the kool-aid.
The original intent of the Chicken and Pigs might have been a worthy one, namely to allow the Scrum team to work uninterruptedly on what they were doing and avoid management’s “interference” and continuously changing priorities.
(Besides, the origins of both the Scrum Master role and the Product Owner role come from Borland International; see further down for more on that. As you might also know, I have the direct experience of having been there, at Borland. It is just a disgrace that Jeff Sutherland has distorted those roles beyond recognition in his reinterpretation while designing Scrum.)
So one might wonder, as someone recently asked me in a LinkedIn thread: how does the TameFlow Approach deal with (for example) this problem of the “interfering manager?”
Even if the answer is specific to the question, it reveals the general broader philosophy that I use. Here it is:
TameFlow is based on patterns. A key pattern is “Enlightened Self-Interest”. TameFlow is also based on mental models - our simplified understanding of how the world works. We expose managers to unconventional (for them) mental models which are of economic nature (“make more money today and in the future”). We grab their self-interest. Now the thing is: those new mental models and consequential management decisions will create a cascade of positive effects. In particular, at the team level, those positive effects that Scrum fails to achieve, especially in larger organizations. One effect is the pattern “Let People Work” wherein elimination of “interference” is the outcome.
Notwithstanding the specificity, maybe this little example highlights the real difference between working off Values and Principles on the one side, and Patterns and Mental Models on the other side; especially when such Patterns and Mental Models trigger actions which are propelled by the intrinsic-motivation of “Enlightened Self-Interest”.
Furthermore they show how the TameFlow Approach is much more “concrete” and “results-focused” than the rest of Agile, that is maybe full of well-meaning intentions, but often results in overall dysfunctions.
The TameFlow Approach and “Agile Management”
As Agile people have progressed in their careers during the almost 20 years since the Manifesto for Agile Software Development - many of whom have not even read that manifesto, let alone had any experience with software development - many have reached “management positions.” The natural fall-out is the attempt to apply Agile Values and Principles in management. And agile has reached “big” companies; so we have witnessed the need to “scale” Agile from the team level to the entire corporation.
Besides the fact that I am extremely skeptical about any “scaling” method to actually work, with these Agile career paths crossing roads with the Cost Accounting mindsets that are ubiquitous in the vast majority of corporations, some very worrisome dynamics have emerged.
Agile’s biased anti-management sentiments have found their tool of destruction. All of a sudden, with the additional “cost savings” justification, many levels of management can be shed, via downsizing, reorganization, process re-engineering, and so forth. Those there in the middle were not “adding value” and hence there is reason for sacking them.
From a TameFlow perspective, this is highly disturbing. Recalling the Story of Herbie in TameFlow we literally never ever leave anyone behind in the woods. By adopting TameFlow, the duties of such mid-managers can possibly change radically - as they discover new ways through which they can contribute to the “adding value” via the “Enlightened Self-Interest” pattern and the Mental Models. Moving away from the Cost Accounting dogma, we are disarming such divisive Agile management practices.
In TameFlow we never fire people (unless of course there are severe reasons, like criminal action, willful negligence, and the like). Instead we reason with the wisdom afforded by Throughput Accounting, and we understand the interplay between the Constraint and Excess Capacity. And that that provides us with the opportunity to reskill, reorganize, and repurpose any role that normally would appear as “redundant.”
Also notice how this different perspective changes the way improvement initiatives can be received by the people in the organization. In all other approaches, people resist changing for one subtle reason: i.e. the fear of improving themselves into redundancy. What’s the point of becoming agile and lean, if the gained “efficiency” will then be turned into the cost cutting exercise of shooting at the ducks that made it happen? So when a TameFlow initiative is deployed, this difference must be made very clear: we never leave anyone behind in the woods. The Unity of Purpose Pattern is always enacted. (And note well: I consider Unity of Purpose as a Pattern; not as a Principle or Value.)
The TameFlow Approach and Business Agility
An objection to the above might be that contemporary organizations need to remove hierarchy and evolve to flatter structures. In this case I have to highlight how in the TameFlow Approach we care more about the effective organization, the one that is embodied in the actual paths of communication and interaction between the individuals. Notice that when we work with the Informational Flow we are effectively shaping the effective structure; not the one that is drawn on the organizational chart. Again, this is a consequence of looking at organizations as Patterns and Network of Patterns.
In any case, after treading into the territory of Agile Management we have to witness that “Agile” has moved even further: right into the domain of Business Agility.
But then we also find the likes of Steve Denning who frequently writes on Forbes, for whom I have mixed feelings. On the one side, we can acknowledge that he has brought - and popularized - “Agile” to ordinary people, which certainly is a positive achievement.
On the other side there are many points that are not agreeable.
Isn’t this Chicken and Pigs all over gain? An artificial divide between the bad old and the good new?
David Snowden has a great way to frame these sorts of good vs. bad tables. They invoke Manicheanism, and it is a danger with all kinds of Categorization. Hear what he has to say in this video, Reimagining Leadership at around minute 14:50; and here’s a partial transcription (my listening errors notwithstanding) of the important passage:
How many of you have seen such tables and would say on the left is the bad things that are in the past, and on the right are all the really good things we’re going to do now. Have you seen that? Anything like that should be wiped from the face of the earth, because fundamentally there’s nothing wrong with rigid processes in manufacturing design around nuclear power control. Everything is right or wrong within context and that’s the key thing. You see this with the agile community at the moment. They’re trying to say all this stuff was bad, therefore we must be right. Now that’s a classic power trip. You attack other people, and then the assumption is you must be right because you’ve proved they’re wrong. But that’s just not the case.
(Besides, shortly after that passage, Snowden also warns about alignments toward common goals; and here I would have to delve into how the Unity of Purpose I so strongly promote in TameFlow is very different from all those other “alignments” of other schools of thoughts. the gist of it is again in the power of the “Enlightened Self-Interest” Pattern. Though it would require an entirely different treatise.)
Now that’s an important insight: Everything is right or wrong within a context; and it brings me to reflect on the definition of an Alexandrian Pattern as a Solution to a Problem in a Context. The TameFlow Approach is built on Patterns and thus has this quality of being flexible, malleable, fluid. It adapts, with plasticity, to any pre-existing context and evolves from there. This is very different from this Agile fairy tale that everything pre-existing is bad and must be replaced tout court.
Another recurring narrative that comes from Steve Denning is this idea that “customer focus” has to have precedence over anything else. The idea is incompatible with the TameFlow Approach were we recognize that we must cater for the needs not only of the Customer, but also of the Employees, the Investors, the Suppliers and more generally having a responsible and sustainable presence in a world that is facing several existential threats (COVID19, Climate, Energy, Food).
This idea of balancing the needs of all actors was covered in Campfire Talk no. 7 from which the above image was taken;and the tool to realize it is Throughput Accounting.
So is TameFlow Agile?
The question of whether the TameFlow Approach is “Agile” or not, is really uninteresting. What matters is that TameFlow will make your workplace a better place wherein your own basic existential needs - like having more money for your own personal income and spending less time at work and having more private time - are better catered for. A workplace that takes sustainability seriously because it wants to be around in the future; and satisfy all stakeholders whether customers, employees, investors, suppliers and simply being a responsible entity in the larger context of a planet with limited resources. A workplace where the patterns of Unity of Purpose and Community of Trust are enlivened every day. A workplace where all decisions are taken in the light of shared Mental Models and Patterns, which respects the local, contextual values and principles, without imposing any such of their own. Where such Mental Models and Patterns are unanimously accepted, not on the basis of consensus but on the basis of Enlightened Self-Interest. A workplace where all conflicts are seen as learning opportunities and are resolved with the Thinking Processess. A work place open to experimentation and learning, constantly improving its own Praxis, as theory-informed practice.
Finally, a workplace that leaves nobody behind alone in the woods - that’s how a TameFlow driven company looks like.