Continuous Irreducibility

Precession of a stable axis, this wobble of sociopolitical construction and distribution, reveals the distinction between “permanence” as dogmatic eternals, versus what accretive, decentralized adaptation attains irreducible differentiation through continuous shaping of an equilibrium identity. Continuous irreducibility appears stable to the pattern-designing mind, despite mutagenesis, oscillation, eccentricity, and errors. Precession allows an illusion of consistent identity, patterns so intricately interconnected to be irreducible as a system. Morality is not the realm of tolerated disagreement, it is the transformative shift, reparations of the revolutionary spin.

Regardless of the absurd acrobatics pursued by the tabula rasa empiricists or phenomenological existentialist Sartre, none of them denied that every human possesses in varying degrees of intensity and “stylistic arrangement” of psychosomatic drives. We use psychosomatic intentionally; it is an experience of physical discomfort that distorts mental signification. Like a cattle prod, the body reminds us that the mind is bodily in its operations, restricting our considerations, chasing us into the rancher’s chutes: fight, free, fuck, and food for oneself. The number of drives remain debated in psychology, business, and philosophy, primarily because too few drives begins offending the delicate masses, while too many drives lacks theoretical elegance. Every attempt to “think outside” empirical reality, when faced with human instincts and drives, finds itself in a circus of values, acrobatics of explanation. Just look, for example, of Sartre’s explanation of sex drive as an obsession with exploring holes (EHE).

Sufficient explanation in practice comes more easily to methodological naturalism: sexual dimorphism cannot self- perpetuate its gains in complexity without a sex drive, animals cannot self-perpetuate the body-system without a food and thirst drive, intelligent consciousness self-perpetuate its pattern recognition and design of tools and systems without a comprehension drive. Regardless of the path by which all these drives attained continuous irreducibility, all human history attests to what the “hullabaloo” is about: freedom, movement, sex, food, water, territory, security, and denial of death.

Kant attempted a logically necessary moral system because he hoped to supersede every variation of the precession of values modernity discovered. This was a reaction to the unravelling of simplicity underway. Colonialism and expansion of global trade gave rise to comparative culturalism. One consistency reveals itself. Rising population density requires to complex systems of domestication. That is, more bodies amassing their drives requires intricate methods of control over food, water, sex, resources, and territory. As Deleuze & Guattari describe the “Ideal State” springs into every text fully-established. Language that survives in written form never appears without massive efforts of domestication huddled around a source of abundance and power.

Relativism, a tolerance of immigrants, allowance of extreme ideals, many gods, several specializations; the average freedom decreases as more free wills amass together. The increasing complexity in their system of morals, aimed at minimization of “complaints” in its many forms. Monarchy and aristocracy were the major forms in which enough privilege amassed to accrue the power that stabilizes the lesser average freedom of the masses. For most of human history, this was gradation of rank relied on domination and enslavements, in which domestication was a single process applied by the few to the many. Restated – moral systems dictate the limits of domination in the realms of enslavement and domestication. When many internal limits compete, gradations of rank arise.

Even the axiom, “All men are created equal,” has produced multi-layered systems of inequalities, desperately to achieve sameness of treatment across all human adults, of sound mind, after age of consent, before age again removes this power. Animals, children, and other property have more rules of civilized conduct than ever, but it is premature to conclude that the intention of equality produce equality in consequence. The saying “freedom isn’t free” gains more cohesive meaning, as freedom not only requires great cost, in resources, time, and deaths, but becomes a system of restriction and incarceration.

This is not to justify any form of inequality that arises, but to add to our backlog that a system of inequalities is produced by every moral system, so our ethics must grapple which inequalities are engineered as its consequence. Thus far, we have only concluded that ethics must sustain the minimum viable resilience of systems that question morality.

Axioms of Quantum Liberty

Many philosophers, teachers, coaches, and priests attempt to hide that their arguments reach a conclusion they held from the beginning. Inspired by the scientific method, like any father who gains a moment of insight from the simple wisdom of his child, we as philosophers should be forthcoming at the outset regarding our axiomatics; we can all join this game on equal footing and with adequate forewarning, knowing the table stakes and the half-time accoutrements up front; or feel free not to play.

 

Axiom 1 – Metaphysical Agnosticism

We cannot know what is “behind” the world of physicality, but one paradigm has proven most valuable for information discovery. Methodical Naturalism, in practice, is the assumption there is nothing metaphysical. There always exists a sufficient reason for any idea, explained through causation, physicality, and semiotics. Therefore, we will treat the mind-matter continuum as one substance experienced two ways.

We cannot guarantee the origin of our perceptual reality prior to our participation in understanding it. The ubiquitous consistency of truth-value attains many explanations throughout the history of philosophy:

  1. Categories of the mental machine and its physical method of processing the world “behind” our experiences (without color, light, texture, or space-time)
  2. Equilibrium truth-values already socially engendered, becoming quietly ready for disruption (example: the Copernican revolution)
  3. The world is exactly as we perceive it “under” the light and color (naïve realism) or close enough that technology can supplement the remaining perception (speculative realism)
  4. We are in a video game or a long dream.

The simplest explanation lies in a refusal to become carried away, caught up in the distinctions between any of these possibilities. These distinctions always lie in conceptual inconsistencies rather than genuine experience. Whatever the cosmos is, we play a consistent game with rules that we may discover through diligence, discipline, and a dedication to proper questioning. Moreover, anywhere we find a metaphysical explanation we are prudent to approach its purveyors with a cautious suspicion of the power their system of belief seeks in the world. The bulk of metaphysical explanations are not only intellectually lazy but also party to a history of ideological domination and abuse. We will seek out and exploit axiomatics of the economic game of consciousness while maintaining this suspicion, even doubting ourselves.

Axiom 2 – Pragmatist Epistenomics

To the arborescent mind of the mathematician, physicist, techn0logist, or philosophical logician, the limits of valuation-signification are far from unsettling. Instead, the analyst considers valuation of hypothesis, error, and backpropogation the basis of an information-rich cosmos. The quanta of pragmatist Epistenomics is the encoded truth-idea. This code is an information commodity, always produced by a system. The truth-idea gains market dominance through exchange; there is no unexchanged truth. The equilibrium price of an idea is its marginal cost in believer actions.Axiom 3 – Fractal Cascade Ontology

Existence as we can perceive it, as endless revolutions of becoming, constantly produces self-similarity. When we observe our universe under the assumption that we distort all perception by the methods of the mind, we create valuable new paths of hypothesis. By looking for patterns, fractals, and ratios we uncover what others miss. Smashing ideas together to see what feels theoretically elegant is a reasonable path for brainstorming.

Axiom 4 – Machinic Operability

When we attempt to confirm the hypotheses we make, it is fortuitous to do so under the assumption that the cosmos is pure information-physicality, and experiment with due diligence that we may cause outcomes that exceed our control. We thus treat any multi-actor economy as capable of producing Quantum Liberty, in which Machinic Agency at one plane and apparent Machinic Operability at its Quantum are co-determinate and freely exchanged throughout.

We will treat liberty of will-to-power, exchange under representation, as an emergent property of the cosmic system. For any given particularized Level of Observation, we will find agency generated out of sufficient freedom for choice and sufficient determinism for responsibility. Moreover, we will treat this as a category of mind that does not undermine humanistic free will, but treats it as a sociopolitical construct that requires stability of semiotic laws. This further stabilizes systems that are orders of magnitude above or below the “peer” phase space.

Axiom 5 – Existential Psychodynamics

The distinctions of the mind-body duality are purely existential processes: a problem of focus rather than ghosts, caricatures, and dreams. We build axiomatized arborescence where we focus our particularized observations; all tangentially unobserved probabilities spread like intertwined rhizomes “just behind” intelligent consciousness.

Axiom 6 – The Will-to-Power

Because we cannot directly observe a Level of Observation lower than quantum mechanics, we will not discuss the substance of the cosmos. However, its clear tendency to generate creativity lies in three axiomatic nodes of Continuous Experimentation: representation, expansion, and acceleration. We will discuss Will-to-Power and its ramifications for our Fractal Ontology based upon this foundation. There is no substance “under” the quantum waves and particles, only the leaning, propensity, or vector of expansion. This emerges as first-principle and categorical imperative; to not only reproduce, but to become more. To the extent this is a probable motion, rather than a substance, we will take competing notions of fundamental substance – Truth, Spirit, Capital, Energy, and Libido – and treat them as facets of Will-to-Power as if the many heads of a single monster, all incapable of speaking the same language.

Axiom 7 – The Labor Physics of Information

The Information Age and the Postmodern Era have come to fruition, out of century of Quantum Physics and the technological revolution that it spawned from its axiomatics. The task we have yet to do as philosophers lies in backpropagating the pragmatic Epistenomics implied by quantum mechanics, its paradigm of waves and particles. Moreover, this ripple effect likely will go “the long way around” to fully cross-pollinate with our other sciences. Therefore, our goal is to merge quantum mechanics with economics to better understand the needs of a post-singularity humanity. Every philosopher up to Schopenhauer, William James, and Bertrand Russell believe that the law of contradiction was a priori infallible. Quantum Liberty, in contrast, must experiment with the problem of superposition.

Do Project Tasks go in a Scrum Product Backlog?

I get this question frequently when training agile and scrum teams:

Do Project Tasks Belong in a Scrum Product Backlog?

YES.

Since answers to this question I have seen in chatrooms are typically insufficiently argued as part of a crazed political debate full of comments taken out of context, this very pragmatic question deserves a bigger picture answer – because the need to ask the question is a symptom of a stagnating transformation.

A successful shift from stage-gate or waterfall development processes to agile, Scrum, or Kanban requires a fundamental change organization-wide: from maximizing ROI and shareholder value to maximizing Economic Value Creation and sustainable competitive advantage. If this shift does not occur, the improvements gained from agile practices will inevitably stagnate.

Jez Humble refers to this state as Water-Scrum-Fall, that unfortunate state where most agile and DevOps initiatives plateau.

Most often when I talk to development teams, Product Owners, and ScrumMasters, this is often blamed on a lack of executive buy-in.

I completely disagree.  

I have also blamed a manager or two for the imperfections in the agility of a company, so I can relate to this view. To show you why you might not even want executive sponsorship, let’s revisit the view of a corporation as a minimum viable superorganism.

Complex Adaptive Systems Leadership

A corporation is not a machine with various parts to replace or maintain in isolation, it is a superorganism. It is a biological phenomenon that is not sufficiently explained by social contract theory or through monetary theories of motivation. Judgments about this reality are very easily clouded. Unfortunately, once measurement and monetary incentives change the natural behavior of the superorganism, it is difficult to change back – making it easy to fallaciously claim this as proof of their effectiveness.

Quantum physicists have suggested that undisturbed systems in the universe naturally stay in multiple states simultaneously, unless someone intervenes with a measurement device. Then all states collapse, except the one being measured. Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.  – H. T. Johnson, “Lean Dilemma”

So when you hear “We need more buy-in from management” this is absolutely incorrect.  It is even counter-productive!  Adaptations by a complex system, that disruptive creativity and innovation agile champions desire, can only occur through organic, emergent leadership – a tribal, heretical rebellion. Adaption to a new stimulus may have a focal point, a “leader” who organically builds up energy in a new direction – but this leadership is an emergent property the complex system. In contrast, formal leadership (“management”) is a crystallization of a complex system, an attempt to reinforce a desired “normal state” – a force that exists counter to emergent leadership and adaptation. By default, formal leaders at all levels of an organism are incented (through power, money, and Agency Dilemma) to maintain homeostasis – i.e. the status quo. Even if a formal leader becomes the emergent leader of adaptation, this will be odds with her formal leadership. Unless she is willing to risk the loss of formal leadership, she will dissolve her capacity for emergent leadership and resume promotion of homeostasis – no matter how much it dampens creativity, innovation, and sustainable competitive advantage.

Evolution of a superorganism through disruption – whether a lean or digital or agile “transformation” – cannot occur if any one piece of the system is optimized in isolation from the whole because any superorganism, as a complex adaptive system, will exert tremendous energy to maintain homeostasis. The larger the superorganism, the more likely that optimization of one function or team will result in a net loss of desired adaptation (whether the desirable “adaptation” is called innovation, process improvement, or “growth”).

So, when a formal leader blesses a piloting of lean and agile practices by a completely isolated team, this is the superorganism equivalent of a mother’s amniotic sac – the team can establish itself as a unique complex adaptive system while in isolation, fed by the resources of the maternal superorganism but shielded from the homeostatic processes of the parent system. The moment this new team is re-integrated into the larger system, continued adaptation is unlikely. The company attempts to spread the innovation and creativity culture they achieved but instead can only formalize a shift in a subset of practices.  These practice, outside the context of psychological safety, a well-formed collaborative team, flop. No single activity of the pilot team will have the same value implemented outside the context of the pilot team’s “bubble” that safeguarded it against the homeostatic forces of the superorganism!

But wait – what about that “net loss” in innovation, creativity, and efficiency I claimed?

In practice, a company that adopts an agile process (let’s say Scrum) as a change in behaviors isolated to the teams developing software causes the rest of the system to expend energy maintaining homeostasis, and even more energy wasted by agents accommodating these homeostatic forces so that the development teams can preserve their no-longer organic place in the system.

I think you know exactly what that looks like:

  1. Updating documentation processes without seeing them as “artifacts” that emerge from an adaptive process rather than social contracts that require formal sign-off.
  2. Replacing one tool with another, causing a new set of employee workarounds to occur.
  3. Increasing frequency of software releases without changing the size of organization commitments.
  4. New meeting names that don’t change communication patterns or the homeostatic, status quo, “normal” flow of information.
  5. Continuous backlog decomposition as a manual transfer of a large-batch investment into small-batch development items.
  6. Oops! Another manual transfer at the end –  of small batch engineering back into large-batch approval processes.
  7. Changing job titles without addressing diffusion of responsibility and the lack of psychological safety inherent in the culture of the system.
  8. More overhead and forced “transparency” than if nothing had changed, through extra meetings, reports, metrics, and analysis, due to the natural distrust between formal leadership and emergent leadership, and the lack of trust in information flow between the homeostatic processes and the aberrant nomenclature of the development teams.

In the middle of all this, a large organization grabs their Project Managers and their Business Analysts, or anyone cheap who is around and doesn’t have the “status” a Product Manager, Director, or VP, and switches around their responsibilities to call them “Product Owners” and “Scrum Masters”.

What a debacle.

The newly-minted Product Owner receives Project Plans full of important tasks and milestones and big nasty Use Case document and an even bigger, unapproachable set of Technical Specifications – and is told to manage what the team delivers with User Stories.

Now in the midst of all this, should the Product Owner include Project Tasks in the Product Backlog?  Or to get down to brass tacks, could a task ever be a Product Backlog Items?

Absolutely!

But not all of them.

Some “Technical” Tasks (specifically not User Stories) are still Product Backlog Items

Technical tasks that create demonstrable economic value that the organization can capture, a known cost of delay, but are completely invisible to the user STILL NEED TO BE PRIORITIZED relative to other potential Product Backlog Items.

This, of course, is why the question of if these belong in the backlog is sign that a systemic shift in thinking has not occurred. If you are optimizing for project ROI, then these tasks just don’t have the marketable, monetizable potential of each Use Case. If you have a systems view of optimizing the flow of economic value creation, these tasks are judged relative to any other potential investment. Economic investment is continuous, the economic value created can be judged continuously, delivery and value capture is continuous, and you can prioritize based Weighted Shortest Job First or another collaborative decision making process about the of Cost of Delay.

“Artifact” Tasks are an Agile Anti-Pattern

There is, however, another kind of project task in Water-Scrum-Fall that SHOULD NOT be in any development team’s backlog: artifact tasks. These are things like “Complete wireframe for new home page” and “Document Social Integration for PokemonGo”. No matter how you small-batch these tasks, these are not Product Backlog Items. These are not even artifacts. Artifacts are the tangible leftovers of the creativity and innovation of a strong agile software team. A documentation, design, or planning task is antithetical to economic value flow. It is a trap. A box you put your money in and bury. It takes all the value-add, throws it in a pile, and lets it sit there, unused, as it become gradually less valuable.

This mini-waterfall process – this outrageous, lean-agile anti-pattern – surfaces in three ways, all of which I whole-heartedly reject and will actively undermine the capacity of others to pursue it in hopes that my heretical tribal rebelliousness will gain emergent leadership support:

  1. Business Kanban and Program Increment Planning tasks that lock up all creativity and innovation prior to the development team passively receiving instructions (as you see in shoddy implementations of the Scaled Agile Framework)? FAIL! TRY AGAIN!
  2. Tasks for non-developer “members” of the development teams completed as Sprint Backlog Items separate from the User Stories, thereby formally dividing cross-functional collaboration and preserving us-them Guilds (whether in dual-track Scrum or within even the shortest sprint)? FAIL! TRY AGAIN!
  3. Sub-tasks that formally divide up User Stories into function-specific tasks to complete? FAIL! TRY AGAIN!

These are all agile anti-patterns that prioritize tools, social contracts, and “process” over collaboration, communication, relationships, and creativity. You will never disrupt your organization, and your organization will never disrupt your industry, sorry.

“Milestone” Tasks are a Continuous Delivery Anti-Pattern

Since we started this asking if the BA / PM as PO ought to put Project Plan tasks into the Scrum Product Backlog, I’d hate to leave out “milestones”. Now you may say, “Andrew, that’s ridiculous, no one would treat a dependency as Product Backlog Item!” Indeed, ridiculous. But that’s the ultimate sign of your Continuous Delivery anti-pattern. Truly optimizing the flow of economic value creation across the entire complex adaptive system would completely remove “milestones” and “dependencies”. If you can’t get rid of Project Plans completely, and continuously deliver and validate Finished Story Benefits for ALL work that the organization takes from identified pain to economic value capture, whatever you started pursuing in your agile, or digital, or lean, or devops transformation, you’ve plateaued as a company.

And this is the really the paradox that made the lengthy description of complex adaptive systems leadership necessary. This hurdle is NOT something that “Needs executive buy-in.” This is something that is accomplished through outright insurgency, tribal heresy, and fait accompli rebellion.

That’s because Continuous Delivery takes more than agile ceremonies and user stories. It takes developers who are proud of knowing business context. It takes refactoring that no one approved. It takes a team move to Git from Subversion without telling anyone. It takes a handful of people setting up a Continuous Integration server no matter how often the nay-sayers tell them it’s useless. Continuous Delivery is a change in engineering practices and development culture that tend to happen without formal leaders needing to approve anything.

It just takes the right people having enough pride in being BETTER that they draw a line in the sand and defiantly announce “THIS IS OUR CRAFT!”

A Heartfelt Epilogue: Real Creativity, Innovation, and Disruption is MESSY

Now listen, human-to-human, if all you know about “agile” comes from that one book you read, YouTube, or a two-day certification, I won’t be surprised you’re thinking, “Wait, Andrew, that’s nothing like agile! How do I report you! How do I get you stripped of all your certifications?” That’s great. That reaction means I hit a nerve. Fantastic! Contact me and let’s talk about taking agility to the next level.

Truth is, I don’t look to my four certifications, five training course, three conference, my blog, OR EVEN my five years of attending, speaking at, and hosting MeetUp’s on agile as the proof of my legitimacy on these topics. I measure my expertise in the number of experiments, including the major failures I have been through with my development teams. The reason is simple: complex adaptive system leadership is an emergent property that require deep entanglement and shared experiences in the trenches. And, as it turns out, I’ve been in the thick of every kind of good or bad lean or agile possibility, trained people in that context, debated ferociously about it in multiple companies, and I have compromised my values or experimented with teams to directly challenge every single principle your little YouTube summary glossed over.

If at this point you think some teacher let me down and it’s a real shame, I’ll be happy to give you a recommended reading list and YouTube list and introduce you personally to other thought leaders that dive, like I just did, into the MUD of how you actually achieve: creative innovation, strategic and operational agility, and lean, continuous delivery of disruptive economic value.

Either way, reach out so real dialogue can get started.

Your ROI is Total BS

ROI is meaningless.  GP% is meaningless.  Signups.  Clicks.  Views.  None of these tell you anything meaningful or actionable.  None of this ensures survival.  In fact, it is through sheer mass that some enterprises survive.  It is the churn of hype cycles and perceived value that keep new customers fooled.  But it is definitely not sustainable.  Big investments end with big blunders that result in mass layoffs and enormous bankruptcies.  The name is the only thing that survives. Is that the company you set out to build?  No.

Let’s assume you are a software company selling enterprise SAAS.  Your entire company is the value stream.  The ongoing operating costs are less than ongoing revenue.  Investing in the sustainability of your model of economic value creation and capture is every dollar you spend.  Those dollars, little by little, react with the market either creating or negating value creation.

The problem is that most enterprises work from the assumption that large investments equate with economies of scale.  While this may be true of investment in automated manufacturing there are no economies of scale in software development.  It is the individual knowledge workers that create innovative software.  The velocity with which you can adapt as a system combined with superior understanding of problem-solution fit in the market is the key to competitive advantage.

The question of how to invest should be quite simple when you are a large company that has revenue growing at the same rate as costs – small investments per opportunity with maximum ability to correct an incorrect investment.

That is enterprise agility.

Enterprise Agility is the speed at which an incorrect decision is recognized corrected.  The smaller the investment decision, the faster the return is known. Lean trims the excess weight, off-balance feedback, and poor technique that undermine agility.  The effective flow of information across the creative process of knowledge workers is essential.

This is where you must realize that unless you layoff staff, you’re investing the same amount continuously.  The ROI of a project is as meaningless as the ROI of a developer day.  The input of resources is relatively static, maximizing the value stream as a system is essential.

This is why the a right-place/right-time, brilliant, socially-savvy entrepreneur-engineer is the most agile and lean possibility: perfect and instantaneous knowledge-sharing internally (in the brain), distinct competitive advantage through the extremely unique skill set (s)he has grown to master.  That is the sprinter that you want your Superorganism to become.  In the right place, at the right time, with the correct knowledge and materials, with instantaneous information flow across the value stream.

So if ROI is meaningless to decisions (because we are paying for individual pursuit of knowledge-worker-creativity regardless of rate of return), how do we possibly make rational financial decisions about innovation, discovery and exploitation of economics rents?  In fact, lean manufacturing has studied this for decades.  When the rate of investment (the cost of production) is held constant, prioritization of economic value added rather than expected rate of return should be our focus.  In a zero-sum competitive game with uncertain returns and asymmetrical information, the time between investment and value capture is the only meaningful variable we can impact.  While cost of delay versus product lifetime return on investment may be more difficult to understand when looking at Toyota and the Prius, this is easy to see with Software as a Service, because the continuous addition of value in exchange for subscription-based fees creates two roughly stable lines. The only meaningful way to improve investment is to exploit information asymmetry more effectively than your competition.  Since you are investing the same amount continuously, you must minimize the cost of delay of value capture.

To put it another way: In a system with continuous investment, only the opportunity cost incurred due to delaying an investment matters. This is not first-mover advantage at the new product-market level, this most-effective exploiter of innovation as an a competitive advantage.  This requires a shift to systems thinking and investment in strength of culture. Money is not your scarcest resource. Brilliance-time (that you’re paying rent for daily) is your scarcest resource.  To maximize value capture, you must maximize the time spent in a state of market information asymmetry.  At the current pace of innovation and obsolescence, the only way to maximize value capture is to minimize cost of delay due to incorrect prioritization.

This implies three goals:

1 – Minimize the impact of an incorrect investment of system-brilliance-time by reducing size of each commitment

2 – Increase the adaptiveness of the system to maximize throughout and future adaptiveness

3 – Minimize the time it takes to receive feedback (primarily through analytics) from the market

4 – Make appropriate risk-taking and experimentation a normal part of every creative process

What Westside Barbell has taught me about Scaling Agile

Agile Portfolio Management:

There is a new way of doing things in delivering a complex product portfolio.  It focuses on delivering value both incrementally and iteratively.  It utilizes empirical process control and hypothesis-driven planning.  It utilizes test-driven development in both convergent and emergent delivery, even when budget and scope are fixed.  It utilizes a Lean kaizen approach to maximize velocity.

This philosophy is by nature, object-oriented and modular.  No one framework is right for every product, so it is highly customizable.  It may sound new to you, but it has been around for quite awhile.  But wait – I’m not talking about Agile, Scrum, or Lean software principles – I’m talking about Westside Barbell’s approach to powerlifting.


Waterfall Weightlifting:

Powerlifting is a sport in which the lifter competes for the highest single-repetition maximum in the Squat, Deadlift, and Bench Press for their weight class.  The traditional approach to training powerlifters relied on linear periodization – a method still very valuable for beginning athletes because each phase builds on the last while progressing toward competition-specific strength.

At a basic level, here is a 12-week competition plan:

3 Week Hypertrophy Phase (muscle size, stamina): Sets of 12 to 15
3 Week Strength Phase (movement form, ability to move weight): Sets of 5 to 7
3 Week Power Phase (Explosive speed, maximum weight at progressively higher volume): Sets of 1 to 3
3 Week Peak & Rest (Highest weight, lowest volume): Sets of 1 to 3, tapering off to a few rest days
Competition: Three chances to get three lifts correct, competing against others who are doing the same

As agilists, this correlates perfectly with the “waterfall” approach we try to leave behind:

Hypertrophy phase: Business planning, creative design, and thorough documentation
Strength phase: Database layer, middle-tier
Power phase: Client-side logic, front end development
Peaking phase: Testing, beta release, focus group and stakeholder reviews
Rest days: Code freeze and marketing
Competition: Release to the market, in which you may not recover from failure

Then the lifter starts over.  If there was a big loss (e.g. an injury) pre-competition, the weight lifter might not compete at all – just like software project that gets cancelled after key engineers leave or technical debt gets too high to meet the release date.  More problematically, if there is a big loss or injury at the competition, the lifter may never compete again- just like the software team with a botched release that gets “reassigned” or laid off.


Repeating the Cycle:

The weightlifter who perseveres, win or lose, still has big “waterfall” problems.  The lifter rests a little and repeats the linear progression cycle, an exercise in bodily context-switching.  When the next hypertrophy phase starts post competition, most of what was developed in the previous cycle is gone!  The same is true of each phase.  When the lifter resumes focus on 3-rep max, some hypertrophy and stamina is lost.  As the lifter peaks for competition, the 1-rep max may increase but the 5-7 rep range decreases.  Studies show that after a few weeks in the subsequent hypertrophy phase, up to 15% of single-repetition strength is lost.  The disconnect between foundational planning (by increasing stamina and size) sacrifices a considerable amount of value captured (ability to perform the same single-rep max).

What does this specificity-switching cost the lifter?  As a beginner, not very much – any work will improve size, conditioning, and maximal strength, and fantastic progress can occur.  The discipline of repeating the movement pattern likewise increases maximal strength even with little planning.  However, once the lifter goes from a beginning athlete – a time when nearly anything will improve the lifts – to an intermediate athlete – subsequent peaking phases will see little or no increase.

The process requires disruption if total stagnation is to be avoided.

If this sounds like delivering software in waterfall, it is!  As you read this quote from a strength coach describing the “waterfall” lifting approach, think about the Waterfall PMO:

Having now gotten away from this type of training and looking back as an outsider, I can see where the program is lacking and why I had so many problems. I used to feel it was the only way to train (mostly because it was all I ever knew). It was also the only type of program for which I could find a lot of research. Some of the limitations to this linear style of periodization include:

  • It’s a percentage-based program
  • It starts with a high volume
  • It only has one peak
  • Your abilities aren’t maintained
  • The program has no direction to the future

– Dave Tate via T-Nation.com

Here are the parallel problems we see with waterfall:

  • “It’s a percentage-based program” – accounting-based statistical process controls are applied to an emergent system
  • “It starts with a high volume” – a significant portion of the budget is spent planning, designing, and fighting about features that no user wants (and if the project is cancelled, 100% of this sunk cost never drives user- or owner- value capture)
  • “It only has one peak” – A major release attempts to market itself to all segments simultaneously and a flop may kill the product line completely
  • “Your abilities aren’t maintained” – once the waterfall project plan is set in motion, market evaluation, user feedback, and stakeholder review is non-existent
  • “The program has no direction to the future” – a waterfall project plan is delivered based on the knowledge available at the beginning of the project when the least is known and has no intrinsic method of looking to the future relationship between the user market that might exist and the software that could be produced.

Westside Barbell’s “Conjugate Method”

The Conjugate Method attempts to balance all phases across preparation for competition. At the “enterprise level” three movement patterns are continuously tested as the measure of the process. At the “business level” a new variation of a similar movement may become the focus for 3 to 5 weeks (e.g. training rack pulls instead of full deadlifts when “lock out”, the upper portion of the movement, is the weak link). At the “team level” (the lifter + coach), the two-week sprint has a consistent set of ceremonies and artifacts (workout plan, workout log, the workout, etc).

Here is an example:

Week 1
Monday – Max effort lower body day (squat + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy
Week 2
Monday – Max effort lower body day (deadlift + low back + hamstrings), focus on strength and power
Wednesday – Max effort upper body (bench press), focuses on strength and power
Friday – Dynamic effort lower body (squat, deadlift), focuses on speed and hypertrophy
Sunday – Dynamic effort upper body (bench press), focuses on speed and hypertrophy

This correlates nicely with “core” Scrum concepts:

  1. Maximal strength is tested every week – working software every sprint
  2. The metric (1-rep max / story points delivered), is improved (strength / velocity over time), through hypothesis and experiments (empirical process control)
  3. The entire body is trained for size, stamina, strength, and power per every week – vertical slicing and user stories
  4. The lifter gets to experiment with new exercises without fear of wrecking a 15-week cycle – sprint retrospective, sprint planning
  5. The coach focuses exercise planning on addressing weak points – a ScrumMaster, removing impediments
  6. The Power Lifting competition is not a unique event with a long lead time – working software every sprint, TDD, XP, continuous integration and release

Now the lifter, like our Scrum team, gets to plan, experiment, and deliver often.  The overall roadmap (Lean + Scrum) might have a basic end-game or vision (increasing 1-rep competition max performed on 3 lifts the same day is equivalent to convergent product delivery), but planning only looks forward up to 5 weeks, commitment at 1 to 2 weeks.  Likewise, the lifter and coach is always looking at the most recent data, the newest lessons learned, and quickly reacts to whether a behavior, practice, or process should be continued or not – just like the Product Owner, ScrumMaster, and Team are always planning and executing based on the most recent market and team data.


Applications to the SDLC:

Now we can extend the metaphor and draw conclusions.  The powerlifter’s body equates to a complex large-scale digital portfolio.  The lifter needs to increase value three programs that focus on convergent product delivery while also developing several programs that utilize emergent product delivery.  In waterfall these two program methods are separated by functional division and project lifecycle, in conjugate (Scrum) these two are handled in tandem.

For the powerlifter, the three convergent products are squat, deadlift, and bench press.  Quality must stay constant or the increase in value does not qualify.  The same is true in software products – adding a high-value feature while allowing a 50% increase in crash on launch is absolutely unacceptable.  Your users will disqualify you!  Whether your have a three-application enterprise CRM program or a three-iOS app consumer program (see LinkedIn or Facebook as examples), adding an exciting feature to an app that causes mass user drop out is a risk no business can tolerate in today’s market.  The competition is too fierce, barrier to entry too low; someone will blow you away.

At the same time, the powerlifter needs to maintain several emergent delivery programs, some for function (increasing grip strength), some for fun (increasing bicep size).  Ongoing workout plans, building size, stamina, and maintaining joint health, addressing weak points by focusing on a new accessory exercise for 5 weeks – all of these priorities must be balanced and evolved.  Keeping a workout log is the only way to be sure that exercise volume, intensity, and density are increasing.  The relationship between the convergent product value and the emergent product investment is the only metric rationally applicable.  The same is true in software delivery.  Emergent-delivery programs like R&D, marketing, UX, product planning are all critical to the health and success of the portfolio as a whole – but the end goal must be clear.

  • Over-planning and under-delivering is not acceptable.
  • Over-researching and under-user-pleasing is not acceptable.
  • Over-designing and under-testing is not acceptable.
  • Over-marketing and and under-releasing is not acceptable.

Conclusion:

The Conjugate Method as an analogy for Agile, Scrum, XP, and Lean at scale works for me because I love lifting.  I realize it may not be right for you, especially if neither agile or weightlifting are familiar territory.  So, like everything, find how this applies to your life so that you can find inspiration in ordinary – then start a conversation about it.  I’m happy to discuss anytime:  224.223.5248

Fixed Budget, Fixed Scope? Be Agile Anyway.

Innovation is Sexy:

Scrum is typically taught with its most innovation-focused form as the example, born from fast-paced software companies who disrupt markets and kill categories.  This is the sexy version of Scrum: a highly elastic process for delivering complex products with emergent design.  In the real world this is not the only context in which Agile, Scrum, Lean, and XP principles can and are utilized to increase quality and velocity.

If you are a newly-trained Scrum professional, bright-eyed and full of hope, do not get discouraged by convergent, fixed-budget, fixed-scope, fixed-timeline projects – be agile anyway!  This is how to do it.


The Agile Manifesto:

It is important to remember that the Agile Manifesto is a set of priorities, not a set of laws. To any extent we can, we strive to prioritize in the direction of team collaboration, continuous improvement, and emergent value creation.  However, there are some occasions when you will have to put additional energy in the secondary priority.  Strategy is the art of trade-offs, so make sure your organization is aligned and the strategic vision is deliberate:

  1. Individuals and interactions over processes and tools – Never lose sight of prioritizing the people who huddle around your solution, never stop collaborating.  Encourage face time and green time.  However, there are highly regulated industries with static expectations, accounting control benchmarks, FDA guidelines, or stable dividends paid to investors for decades.  A well-documented, repeatable process for how software, hardware, or other product will be delivered over the course of a long-term project will assist tremendously with stakeholder confidence.  Make priorities clear on all sides of the contract, set the expectation that communication and availability are mission-critical, but understand that there will be little risk tolerance for out-of-control processes.  Maintain your agility by keeping your document alive and lean, maintain elasticity, but make sure the tools used and the processes adopted, and the pace of process change, gives your fixed-scope, fixed-budget project a stable context for predicting delivery and ROI.
  2. Working software over comprehensive documentation – Delivering builds early and often is the best way to be truly certain of product status.  In emergent product design with incremental feature addition this feels natural.  There is an MVP planned so an opportunity to pivot is assumed, the feedback loop on the progress of high-quality incremental delivery is the best way for stakeholders and users to see and feel the value that is emerging.  When working with waterfall-minded stakeholders – especially if they are an external client – fixed scope, fixed budget, and fixed release dates cannot always be avoided.  However, convergent delivery does not preclude the XP and Scrum best practices of well-formed agile teams and an openness to documentation-heavy products will drive velocity and success waterfall organizations have never seen.  Instead of negative reactions to the expectation of comprehensive documentation, approach documentation as a secondary product and maintain the same expectations of prioritization, collaboration, and responsiveness.  Moreover, a convergent, finite project likely came to you with extensive documentation.  This documentation will require some additional work, but it should not be ignored.  Even though this is a source of waste that is removed during agile transformation and lean consulting in “sexy” emergent product delivery, handling waterfall requirements as documented stakeholder demands can be incredibly helpful in convergent product delivery.  The Product Owner still must aggregate, consolidate, and complete backlog decomposition with the team.  The XP user story and a prioritized backlog should still set the delivery cadence.  Be open to documentation and transparent to stakeholders about its actual ROI after it is delivered.
  3. Customer collaboration over contract negotiation – Good fences make good neighbors.  Some large companies simply cannot risk an open-ended and loosely-defined relationship, especially with vendors or contractors.  If you’re competitive strategy relies on these types of contracts, inspect and adapt.  Find how negotiation can be expedited, build in the process of collaborative relationship change, and build well-formed teams that are as adept at ramp-up as they are at innovation.  The capacity of a Scrum team to quickly assimilate a knew business and architectural context will drive success in products and relationships of all types.  Answering the internal needs of various business functions or developing solutions in new industries requires a team aptitude for understanding new contexts effectively and efficiently.
  4. Responding to change over following a plan – Change is inevitable in product delivery – the demands of the market, the technological tools available, and the state of the product being developed are a state of continuous evolution.  New requirements previously unnoticed will surface in the course of a project.  Even in a mostly-waterfall project, a great Product Owner will apply XP and Lean principals to minimize waste and maximize up-front value.  Great Scrum teams will perpetually improve, increasing velocity.  We often talk about “waterfall projects” versus “scrum projects” when we really mean emergent versus convergent delivery – fixed budget, scope, and deadlines do not preclude scrum, lean, and XP practices, they constrain them to a known outcome.  The difference between delivery by a helpless group of Project Managers and Business Analysts disengaged from team performance versus delivery by a powerful Product Owner and kaizen-crazed ScrumMaster and team is not dependent on emergent product delivery!  Collaborating around the highest value backlog items up front, swarming impediments, and tracking the variance of forecasted-to-actual product-level burn down will allow fixed dates to be met appropriately.  Responsiveness to change needs to be supported by a strong relationship of trust, which must earned.  If you are in a custom software shop, responding to RFP’s and entering into fixed projects is often the inevitable first step to earning the trust that will lead to a more agile relationship, so make efforts to meet the comfort level of the customer’s stakeholders while including a healthy process for addressing requirements changes.

Conclusion:

The values, practices, and behaviors of agile, scrum, lean, and XP have wider applicability than open-ended emergent product design.  Staying open to the unique lessons that can be learned in seemingly less-than-ideal projects will be a terrific opportunity for the kaizen-driven team to grow.  If a rigid process and convergent projects have caused the shine on your Scrum mindset to dampen, step up or step out: don’t let the context defeat you, stay true to your agile values.  On the other hand, if you find yourself in a long-term no-win situation in which you cannot drive change for your team(s) and users, maybe a sexier career path is out there for you to consider.

FREEDOM: How using Scrum un-impedes our full potential!

Scrum frees teams from the tyranny of the urgent:

A key goal of the Scrum transformation is breaking the parent-child relationship between “business” and “development”.  Technical planning, implementation, commitment, and delivery is in the hands of the team while the Product Owner provides a single priority-order backlog of consolidated items from stakeholders, users, and the developers, for the team to plan around.  Once a well-formed-team finds the right mix of XP and Lean practices (especially continuous integration and frequent releases) the pressure of “we have to do this now” is easy to manage.  If major items frequently pop up mid-week on a “release train” that deploys weekly:

  • The team leaves room in their commitment for these items
  • The Product Owner sets realistic expectations with stakeholders on which release will include the request

This is part of the power of Lean planning for making strategic product and release decisions – once the Minimum Viable Product is in the open market, data from the users can determine urgency of backlog items.  Frequently, this is a point where a pivot is desirable.  Through frequent releases, the users, stakeholders, and the team can relax and look at the big picture, free from the fear arbitrary deadlines and urgent scope “creep”.

Scrum frees teams from the fear of making mistakes:

While the extreme co-dependency that drives the tyranny of the urgent is overcome by putting an end to arbitrary deadlines and poor scope decisions, the fear of making mistakes is overcome through the key roles defined by Scrum.  Note, these are roles and this label is intentional – these are NOT by necessity positions or titles.  As I describe in Why Product Owners? a role is the confluence of empowerment, responsibility, and accountability for One Big Thing that rests on the shoulders of a single person.  Teams are free to voice ideas because the Scrum framework encourages collaborative implementation planning, cross-functional brainstorming, and constant discovery of best practices.  With XP Pair Programming, this becomes even easier as a single screen and keyboard gets two minds and four eyes that can converse on best practices, mitigate against knowledge silos, and build team relationships.  In the end, all of these adults acting brilliant and mature, huddled around a problem still have the Product Owner as the proxy to the users and stakeholders.  The team is free to determine one small solution at a time, just-in-time, and just-enough – then iterate or pivot.  When tough decisions need to be made, the Product Owner makes the call, relying on the expertise of the team, sets expectations, and maintains accountability.  Moreover, the user story – as the building block of incremental product delivery – isolates risk of mistakes to the smallest valuable user interaction and continuous integration ensures that when a new increment is not “potentially shippable” it can be easily taken out until additional iteration is completed.

Scrum frees organizations from business as usual:

When things go wrong in a large Waterfall project, multiple helpless Project Managers ask for updates but are unable to check boxes, development teams are powerless to drive the direction of the product, and stakeholders become progressively frustrated by the unfinished pit into which money is being thrown.  Then they cancel the project!  What is missing here?  JOY!  Menlo Innovation’s Richard Sheridan and author Joy, Inc. describes the importance of team joy in an interview with InfoQ:

There is in fact tangible business value to joy. But understand this: our focus is external to the organization. What we want more than anything else is that the work of our hearts, our hands, and our minds gets out into the world and delights people. That’s our definition of joy. We want somebody to stop us on the sidewalk and say, “That thing you built, I love it. Thank you. You made my life better.”

When I build a new Scrum team, guiding them with the help of my Scrum Master through the process of forming, storming, norming, this is the number one fear I must guide them through:  I say “Yes, the requirements will change.  Yes, what you build today will be modified tomorrow.  What matters is that you are a creator, people will actually use what emerges, and it will make a difference to them.”

The move from cancelled projects to meaningful user feedback has an incredible impact on an organization.  The drive to constantly improve, tighten feedback loops, and evolve through empirical process control will make disruption the norm and remove the fear of inevitable change and new ideas.

Scrum frees organizations from process rigidity:

There are three overarching goals driven by the roles, ceremonies, and artifacts in Scrum:

  1. Notice ineffective processes, workflows, or behaviors quickly and cease them.
  2. Notice effective processes, workflows, or behaviors communicate this knowledge
  3. Recommending new processes or practices that can be tested for the length of a sprint

At the organization level, the same process should occur.  While the empirical methodology monitoring “the process” – a mix of lean, XP, and other function-specific practices – is held constant, the practices that are monitored within “the process” are under constant review at the team and organization levels.

At this year’s ScrumAlliance Global Scrum Gathering in Phoenix, Arizona, I attended a terrific session  “Scrum at Scale – Free yourself from the myth of one-size-fits-all scaling led by Scrum Inc.’s Alexander Brown.  Look for an upcoming post on his argument that Scrum is by definition modular and object-oriented, such that organizations scaling Agile, Scrum, Lean, and XP can utilize empirical process control and a mix-and-match approach to the various frameworks most appropriate to the unique needs of each team.

The one outcome you MUST achieve in Sprint Zero

Scrum, Lean UX, & Extreme Programming Sprint Zero:

The length of sprint “zero” for a new product and the (debatable) necessity of common sprint zero expected outcomes may vary, but there is one task that must be completed, or the full benefit of your Scrum and XP practices will suffer:

Complete setup of the repository and automated build server – and send a build.

This is a critical step in establishing team transparency and Product Owner accountability – frequently delivered builds, even with mid-sprint potentially un-shippable product increments – are the exclusive insight of the PO into the progress of the product.  It is the Product Owner’s responsibility to determine the worthiness of the stories delivered and whether additional iteration is necessary; delaying this feedback loop robs the PO of crucial insights and undermines the team’s ability to gain fast and honest feedback.

The longer the team waits to send the first build, whether due to a still-emerging architecture or lack of finalized copy and assets, the more perfection becomes the enemy of the good (or in this case, the deliverable).  Scrum requires transparency and accountability:  remove dysfunctional Hawthorne Effect as early as possible by setting the precedent – from Sprint Zero – that the build is delivered to QA and the Product Owner early and often.