Don’t forget Social Media in your Digital Transformation

If you’ve seen my YouTube playlist on the market-based view of lean-agile in digital transformation or read my posts on the necessity of operationalization metrics then you already aware that I don’t measure the responsiveness of a brand based on the lead time from golf course to cash, I measure the feedback cycle time from Twitter to production release. This isn’t just a lean-agile approach to connecting marketing with consumer technology, of course, this is about the ability of an enterprise to graduate from DevOps to Hypothesis-Driven Continuous Delivery.

The human body, in all its wonder, is the perfect metaphor that shows how this works. Let’s pretend for a moment that the human body is a post- Digital Transformation learning organization:

  • The hardware of the body = bones, tendons, ligaments, muscles, etc
  • The firmware of the body = the endocrine system (hormones), neurological system, and sensory organs (including proprioception)
  • The software of the body = the human mind, in its infinite creativity and imagination

So let’s say you decide to lift a boulder. The software directs the hardware using the firmware, passing along motivating signals and messages – but the boulder is too heavy. You know it immediately, and decide not to hurt yourself. Incredibly complex processes in the golgi-tendon organ, proprioceptive system, and visual cortex aligned spontaneously to tell the mind “don’t try it, buddy!” Despite all that complexity and fuzzy-weighted algorithms, the feedback cycle time is instant.

We can imagine other great examples, like our ability to feel when a basketball is stolen mid-dribble (without even seeing it happen!) causing an instant pivot to find it. When we catch a baseball, the glove prevents us from seeing if we have a firm grip on the ball, and we’re watching the runner on second attempt to steal – but the familiar snap sound of the leather of the ball against the softer leather of the glove, the sting in the hand, and the well-practiced recoil of the arm are fully sufficient.

So why are we so bad at hand-eye coordination in the enterprise?

In dozens of organizations I’ve helped through their digital and lean-agile transformation, the numbers are never “added up”. Deep learning occurs through hypothesis-error-backpropogation; but no one is will to look like their hypothesis failed. There is no experimentation, so there is no innovation.

If the leadership of the company is the mind, it seems like most enterprises have a serious proprioceptive delay.  A strong sensory system combines and related all “the numbers” – the technical metrics (webservice availability, response times, page loads errors), user behavior / product metrics (completion rates, dropoffs, conversion funnels), social listening (not only on social media, but also the chat widget, feedback form, call center, and even UX interviews), and finally strategic KPI and accounting measures.

If these don’t come together, or take a very long time to make sense, the only way to manage coordination is visually – with the mind specifically thinking through each action of the body. That’s alright if you’re competing with players who are similarly bad at proprioception, but you’re guaranteed to lose against the “professional athlete” of your industry.

So don’t treat complaints and requests on social media as a closed dialogue, treat it is a signal from the market; check for information asymmetry. Don’t keep Twitter analytics in a private folder or let your social media analysts sit in a silo. Connect those brand marketers directly to enterprise operations, sales, digital media, and consumer product technology.  The cohesive view of how well the enterprise operationalizes leadership strategy should be a matter of proprioception, not visual observation.

PS – The social-to-production feedback cycle time for Keener Strategy is less than 24hrs.

 

 

 

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.

Are Robots Stealing Our Jobs???

I interview people at all levels of an organization during a Digital Transformation. Since the business case for transformation assumes lean process improvements, I have two goals:
– Make the information that runs the business into data a computer can “understand”
– Replace the non-human, monotonous tasks related to information with computers

To give away the ending here – the robots aren’t taking over. When I am done, all the social context, human relationships, and important judgement calls are still human-made. What we change is how quickly the mundane data-massaging, tiring research, and waiting between email chains that delay all of those human decisions. So I have a goal when I start interviewing: remove inefficiencies and make existing workflows more scalable. This implies automation.

One key thing here: nothing your business does is just chaos. I absolutely spend more time convincing people that an algorithm can capture the complexity of what drives decisions than I do formulating the algorithm. No matter how loosely controlled or gut-feel driven the decisions are, once a business grows into the 100s of employees, I can represent most of your processes with an algorithm. I could even replace the important human decisions with another algorithm that would succeed within a reasonable margin of the average employee, but that’s too risky. Instead, we make notifications and intuitive user interfaces to let one person make the same important decisions 10x or 100x as efficiently, making everyone more scalable. Don’t lay people off. Make it easy for them to increase their value-add.

Interestingly, there is a powerful cultural influence in these conversations due to the mistaken belief that “automation” somehow equals “artificial intelligence” – when what it really means is “fairly basic math equations tied together into one big powerful formula”. The intelligence is completely human-created, human-programmed, and human-managed. So I inevitably but happily show it works prior to convincing someone it works, because depending on their place in the company, the idea of automation replacing humans can be an ideal direction loaded with false optimism or a terrifying slippery slope where unrealistic pessimism prevails.

Both cultural perspectives ultimately distort the conversation.

In its really old roots in the Toyota Production System, the introduction of an “ejector” was a huge benefit to the safety, well-being, and efficiency of a machine worker. Before the ejector, a worker would carry a part to a machine that had just finished its task on a previous part. The employee would put down the part they were carrying, take out the previous part, pick up the next part to put it in the machine, then pick up the previous part. With an ejector system, the machine gets the previous part out of the way so that the worker just walks up and loads the next part, then takes the previous one, checks it for quality, moves it along the line.

Think of all your manual spreadsheet updates, paperwork, phone calls, and email chains just like that. You’ll still check the output for quality before passing along information or making a decision, but automation, notifications, workflow rules, and algorithms can save you a fair amount of your pain by pushing or ejecting what you need when you need it (keeping it out of your way the rest of the time).

This makes the value-add or revenue potential of every existing Customer Service or Sales or Marketing employee scalable beyond what additional hiring can accomplish. Lean Process automation doesn’t mean replacing all operations with an AI. This is the foundation of “Autonomation” – where a worker no longer manually labors at one machine, but becomes a manager of multiple “machines” – multiplying the value-add per employee. Replace the painful, slow, or unnecessary steps with a computer, while keeping the human element – the important decisions, the social context, the gut feel, human.

“Digital Transformation” Beyond the Hype

Living in the tech implementation space, the most exciting moment in a “Digital Transformation” for me is near the beginning of any project or initiative.  It’s the moment someone who is integral to operations finally opens the 5″ binder that has been sitting on their desk untouched; and finding the information contained in the binder is fundamental to all company revenue.  Or it’s the moment the battle book comes out from the sales VP and the ensuing conversation shows – to the collective surprise of the rest of the participants – there is no standardized pricing, and no tracking of how prices get negotiated.  Or it’s that moment I find a clipboard and start asking about the origin, purpose, and destination of each form.

That’s the juicy part.

On factory tours, in “working sessions” and project kickoffs, or detailing the business logic for an implementation, this is the moment my work is no longer just “make it prettier and online” and the conversation starts driving an actual transformation – of the workplace experience and overarching business model – using “digital” technology.

The reason this moment is so exciting for me happens to also the answer to the question I’ve heard at more than one barbecue from an older neighbor – “And what exactly are you transforming?”

I think that’s a great question in retrospect.

What we are actually transforming is information.

  • We take the information created purely for human consumption;
  • We make it easy for “computers” to read it efficiently instead of humans;
  • We use “computers” to present the information more quickly to more people.

It’s that simple. 

Pragmatically, that’s the process that takes the hard-to-maintain spreadsheets that become binders or clipboard papers and transforms them into intuitive digital interfaces (they are also “online and pretty”). By simplifying all of that socially complex and context-dependent information into a flat table a computer can understand, you become free to add all of the social and contextual perspective in multiple ways later (channel and audience specific) instead of just one way forever (in that binder).