Arborescent Consciousness

Although we can properly say little about what consciousness is, we can begin like Kant by describing its modes of operation. We may hold thought as a strategic trait, then elucidate what it gains in practice. Machinic Agency sustains the tension between feeling free and observing determinism, feeling optimistic when surrounded by entropy. Just as quantum physics relies on the assumption of uncertainty to produce probability, the assumption of freedom within a system of rules itself produces liberty. In each case, the Observer plays an active role in framing and anchoring the system of values. Wherever there is observation, the combination of intelligence and consciousness, there is arborescence.

Arborescence is the branching of representations that occurs under the generalization and abstraction of semiotic analysis. Analysis splits perceptions repeatedly, creating dichotomies even where there is no perceptible opposite. This long series of breaks when drawn begin to look tree-like. The Observer creates many trees of knowledge. Philosophers are interested in cultivating these forests.

That which appears as power-law and arborescent when we focus on a trait of a population disappears into chaos and nonsense when we are not looking. That is not to say that there is no existence when we are not the Observer, but that our mind filters, prioritizes, and obscures experience like the lens of a camera, and it narrows perception through framing as well. We overlay representation in the act of analysis, and do so with increasing selfishness and optimism unless some other tree of knowledge competes for the light of the sun.

It should not surprise us that we find fractals and branches everywhere we focus, recording causality and determination along the plane of observation; these are the operative processes of the human recording of production. Moreover, we can fully expect that consciousness will succeed in making sense of what is under observation at the expense of what is not under observation. Patterns suddenly come into focus. Melodies suddenly fall into proper rhythm, shutting out contentious noises. Analysis gives us a normal distribution, spreading, branching upward from the trunk of paternalism. It is the stubbornness of the Observer to remain at the trunk once so many branches have spread that drives the role of paternalism and centralization.

It is metaphor to say that the conscious mind is arborescent, even more to speak of an unconscious at all. These are expressions. When we apply observation, gather data, select a plane of significance, truncate outliers, cancel noise, homogenize particles and investment vehicles, we as the Observer are generating the Fractal Ontology we find, creating but also projecting logic where we have no evidence of design. Just outside the peripheral vision of the mind is everything that does not need observation for The Moment. Concentration, consistency, coherency, abstraction, derivation – these are paternalistic controls over representation. The more we develop our semiotic system, the more repressive it becomes in the service of the Observer.

This implies two basic universes of thought become possible. First, we can imagine consciousness like an astronaut recording a video, floating, spiraling in space; if we keep turning we get a 360-degree image of what surrounds us (consciousness) but understand only derivations of the role or substance of the camera itself or the person recording the images. This places the intelligent observer at the center of a personal universe of representation. Second, we can imagine walking in a circle around a fixed center until we observe the entire 360-degrees available by looking at or beyond the central axis point. In this case unconscious remains in the feeling we can never attain full confidence that behind us, beyond the limits of our peripheral vision, there may not be something we are missing. In either case, Observation is the strategic outcome of the thought-drive, operating like the drive for hunger or sex. We continuously record, focus, frame, anchor, and bias our experiences (consciousness) until the moment our thought-drive must recuse itself and ask “What have I missed? What lurks in the shadows? What if there is something just behind me? What if I am dreaming and great danger awaits my body in the real world?” We can see the immediate value to the Observer of this continuous experimentation with uncertainty, lest he get so lost in his forests of knowledge as to be eaten by a cougar or bear!

The “trunk” of these two conceptions digs into something, remaining unseen but that our observable universe of thought convinces us must exist. It is the prerequisite for sense-making, this assumption that either the world “behind” our representations has substance or spirit, or that the world “within” has equivalent constituents or a ghost. We are never content, except with enormous discipline of practice, to believe that either there is no soul in our machine; or that there might be many forces working in concert, like a well-formed orchestra no longer in need of a conductor; or that this identity itself is the great lie, that we have no soul to lose or preserve at all.

This is the Rhizomatic Unconscious in which we never fully understand our own camera or relate it perfectly to the film, and can never fully incorporate into the image all the elements not captured in each shot. In this way, we observe logic and perfection in the universe not because it is there, though it might be the case. We only know that we observe an apparent logic, but wonder if we ourselves create it. We try to overcome the uncertainty principle, a mathematical solipsism of sorts, through combined will-to-power. We say, “If several observers stand in the center together, looking outward, while even more observers stand in a circle around them, looking at them and beyond them; then we can get a perfect and complete view! Then we can be sure there is not threat or uncertainty!” This very combined effort makes the feeling of liberated will at odds with the determinism of collective observation.

This has always been the goal of our institutions, from the nomadic tribe or primitive commune to our most advanced scientific laboratories and most complete mathematical models. If we work as individuals, we can take greater risks with potentially greater rewards, but if we work collectively we can attain more complete information regarding potential risks and opportunities. We tend to oscillate between extremes, both in single lifetimes and as a species.

In the meanwhile, wherever we focus, we axiomatize. The only method we have found as a collective to help the individual with their unconscious is to shout at them from across the circle, hoping they will believe us if we describe the bear behind them with enough intensity. Unfortunately, many never turn around in time. Death has already come for them in their ignorant distraction.

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.

Agile Priorities: Keeping Documentation Lean

Agile Transformation

If you want your agile transformation to fail, allow the development team and all supporting functional teams to focus on the waterfall deliverables and dependencies to which they are accustomed.

In “Fixed Budget, Fixed Scope? Be Agile Anyway.”  I argued that agilists, especially newcomers, must understand that the Agile Manifesto is a statement of priorities – at times, tools and interactions, comprehensive documentation, contract negotiation, and following a plan are all part of the product that is created by the process that keeps your teams in business.

In software development, this is the exception rather than the rule.  

For “core” Scrum, the proverbial “one-team-in-a-garage”, this is pretty simple.  Everyone you need is in one room.  When scaled, a delivery organization is often “compound-complex” – it is “compound” when two or more independent functional knowledge areas must cooperate and “complex” when at least one knowledge area has dependency on another (these aren’t fancy concepts, just basic grammar).  The moment a delivery process moves beyond one-team-in-a-garage Scrum, there is compound-complex value stream:

The web team and mobile team will build a user-facing experience, while the middle tier team provides RESTful services, only after sales executes the contract and the Product Owner builds the backlog; meanwhile, UX, BA’s, and QA’s will provide documentation.

In this value stream, the “Wildly Important Thing” is the software that a user will consume in order to drive revenue.

Because Communities of Practice have their own traditions and methods of proving extrinsic value, shifting their priorities is much more difficult at scale.  Plan to change the physical distribution in order to overcome the functional “clumping” that Waterfall encouraged.  Moreover, agile transformation will require finding and eliminating the agency dilemma of managers who built their kingdoms around waterfall values.

Resolving Wasted Effort

If agile at scale has not improved company-wide quality and velocity, it is likely due to waste in the overarching process – you must remove any activity that does not drive value creation that a user consumes and the business will capture.  This is the central rule of the User Story – if it does not make a difference to the user (and occasionally the owner) it is wasted energy, a distraction.  You find this clearly stated, often, in Jeff Sutherland‘s various descriptions of “Bad Scrum” – without delivering working software that matters to the user an organization will be stuck in a self-reinforcing cycle of inefficiency and ineffectiveness.  No one is making a difference in the world, selfishness increases, velocity never improves, no software is delivered.

For a compound-complex process to stay agile, the Lean principles of Just-in-Time and Just-Enough to must be applied to all forms of documentation – business rules, persona descriptions, wireframes, UI designs, sliced assets,  value mapping, technical constraints, market conditions – all are a means to pleasing the user, not the end goal (software that a user values).  The User Story is the cornerstone of efficient, effective product delivery because it is a “reminder of a conversation” about a result from which a user will derive value.  For some teams, a set of wireframes can all but replace “cards”.  An image of a login screen is sufficient to drive the conversations a team needs to have about client-side validation, security requirements, and authentication method.

The Product is Everyone’s Deliverable

To move to next-level agile, at scale, an organization will need to blur its understanding of “business planning”, “requirements documentation”, and “UX Design”.  While there may be a need for full, distinct teams of experts at each of these disciplines, these approaches to defining what the software will be should converge on a single goal – building great software.  A popular article on Lean for UX, Lean UX: Getting Out Of The Deliverables Business leads with this statement:

Wireframes, site maps, flow diagrams, content inventories, taxonomies, mockups […] crystallized the value that the UX discipline brought to an organization. Over time, though, this deliverables-heavy process has put UX designers in the deliverables business — measured and compensated for the depth and breadth of their deliverables instead of the quality and success of the experiences they design. Designers have become documentation subject matter experts, known for the quality of the documents they create instead of the end-state experiences being designed and developed.

Having started my career as a Business Analyst, this is painfully resonant.  It is unfortunately easy for management move from training “the tools of the trade” – spreadsheets, slide decks, requirements documentation, technical specifications – to judging the tools independent of the software to be delivered.

Here are a few rules to follow to get UX, UI, and BA’s out of the deliverable business and into the well-formed team:

  1. Never say “final sign-off” regarding artifacts – whether working for internal stakeholders or external clients, if software is the deliverable, it is the only item requiring sign-off.  Every other artifact is is a tool for getting working software in the hands of users.  Make sure you are “responding to change” at the request of real users of working software – no amount of planning or documentation will survive contact with the user.
  2. UX/UI Refinement should mirror Backlog Decomposition – Prioritizing working software does not mean there is no product roadmap, it does mean that time and resources should only be invested in the software most likely to be built in the near future.  This starts as a process diagram of all possible Epics that could be built, and how the user gets to each of these features.  The upcoming 2 to 3 features should have relatively actionable wireframes.  The team should feel certain about the UI design of the current and next sprint.
  3. Create paradigms, not screens – the most important expectation to break is the annotated UI composition per screen.  Some screens absolutely benefit, many do not.  A well-formed team should have enough shared understanding of technical constraints, design paradigm, and business context that a conversation is sufficient to drive the whiteboard-to-working software process.  Wherever possible, establish a paradigm for a product is intuitive to build.  If it isn’t intuitive to the developer without extensive documentation, how likely is is it the user will find it intuitive?
  4. Document releases proactively, but in accordance with your level of certainty – If there is a product that will require knowledge hand-off, a support guide, or other formal documentation, maintain the tension between what makes sense to proactively document (so you don’t spend a full week post-release) while wary of what will change (likely anything more than a sprint in the future).

Following these rules, the software development process in an at-scale, compound-complex organization can focus on the user enjoying a working product.  Aligning vision and expectations along the agile priorities will remove fear of failure or criticism, increase team velocity, and result in the best possible products.  Then, your team, business, and enterprise can pursue kaizen – and the real magic can happen.

Enterprise Mobility – You and your team need more green time!

As a consultant and delivery owner for custom mobile application development, discussing with people outside the industry regarding the various ways in which people think about “enterprise mobility” is always a great conversation. There are three basic ways the terminology is used:

  1. Mobile Device Management:  Devices and data security management in enterprises environment that COPE (corporate-owned, personally enabled) versus BYOD (bring your own device)
  2. Consumer Marketplace Apps: Consumer facing solutions created custom by an independent contractor (I would typically point out this is not what I consider enterprise mobility)
  3. Internal Enterprise Apps:  Proprietary solutions used exclusively by a single enterprise, in which the operational effectiveness gained with on-the-go, on-demand employee activity that is supported by one or more mobile applications

Let’s talk about #3.  I love enterprise mobility and being a member of the mobile workforce.  I love to build and manage employee solutions for enterprises.  Every day is a good day when I am consulting, planning, and delivering on-the-go, on-demand, notification-driven enterprise user experiences – that is my specialty.  Part of how I stay “in touch” with the users these solutions serve is by finding and using the marketplace and proprietary apps they use, getting out of the office and off wifi, making every effort to be an ultra-mobile worker – and I love doing it!

Worker Mobility

Talking Stick Resort – Scottsdale, AZ

Why do I love being an on-the-go, on-demand employee?  Less screen time, more green time.  As valuable as note-taking can be when it truly captures the full context of what is discussed, I find conference calls and meetings where I have a computer in front of me are consistently sub-par.  So when I have several calls in a row (with no screen sharing), I plan to spend that time at a park or forest preserve.  I love walking meetings – not the indoor kind on treadmills (though I support that option too) – so when I need a one-on-one “meeting of the minds” with a mentor or mentee, we take it outside and walk around.  I go to the gym at lunch most days to give my eyes a break and get my body awake.  After all, I can chat, text, and email as easily by mobile between sets as I can between bites at a desk.  When there is a tough problem to solve, a couple beers and a whiteboard can help a small group hash out a solution better than a chat group.

We are part of an increasingly mobile workforce.  Take advantage of that freedom, encourage it with your peers, empower your employees.  You will see immediate benefits!

Walking Meeting

Illinois Forest Preserve – Chicago, IL


Connect With Me:

LinkedIn       Twitter