Influences
If you haven’t read the work of Dr. Russ Ackoff, you should. I became acquainted with his work a few years ago, and I was immediately drawn to his approach and his style.   He reminds me of my dad.  Like my dad, he was an architect by trade, and a driven systems thinker.

As I launch into another critically important change effort in my career, I’m aware of the importance of a key systems thinking lesson:

Leading change in a complex system is a holistic process, characterized by an understanding of the “system whole”. It’s not the sum of the behavior of its component parts, but their interactions that count.

Analysis – The Way We Learn
As children, we are explorers. We learn rapidly, and one of the ways we learn is by breaking things. Literally breaking them…not always because we’re destructive (although it looks that way). Sometimes we simply want to know how something works — so we break it. We take it apart, all the way down to the core objects it’s built from. We do this so we understand how the thing works. We are, in practice, “analyzing” the world.

In school, we are taught to solve problems exactly the same way. Take a problem and break it apart. Break it down into the smallest parts we can so we can understand the problem in an attempt to come up with a solution. We do this in school, and as kids, very naturally. As we learn, analysis is actually a very powerful concept, and in simple systems (or even mathematical equations for instance) analysis helps us quickly solve problems, often with ease.

The Complex Systems Challenge
In a complex system, a problem arises. Analysis doesn’t always get us there.  By way of a grossly oversimplified “Ackoff” example, you (you, the complex system and human being) cannot be understood or defined by your component parts. (Humor me) and think about your hand. Your hand does not write — YOU write. To test the theory, separate your hand from YOU and see what it does. Similarly, your brain doesn’t think, YOU think.  Your feet don’t run, YOU run.  You get the point….

The same can be true of automobiles. If you take the best car components available today from all the manufacturers and put them together (best engine, best suspension, best alternator, best transmission, etc), would it yield the best car in the world? The answer is obviously NO. You wouldn’t even have a car. The pieces don’t fit!

With these examples, Ackoff teaches the critical lesson.

A complex system can only be defined by the interactions of its parts, not the parts taken separately. It is the interaction of the parts that counts!

In this way, “synthesis” is the key concept, not analysis. And synthesis is not natural for humans (kids or adults), and worse, its rarely taught in school.

What does this mean for business?
Businesses (or projects, or divisions, or schools) are also incredibly complex systems. As such, the primary leverage to understand (and change) a business should be its component interactions, NOT the components themselves. We sadly don’t run businesses this way. We systematically break them apart in an effort to improve. We align ourselves by departments, silos, component parts. We work like crazy to make each department “perfect” and then try to put perfect pieces back together, all under the pretext of improvement. As system thinkers know, this improvement is an illusion.

Awareness
As I reflect on the journey I’ve taken in my career, I realize I’ve fallen victim to this gap in awareness over and over. The awareness that analyzing problems in complex systems isn’t enough. And all along the way, many (I should say most) of my leaders and managers have been cheering me on from the sidelines – cheering me toward certain disappointment. It’s what makes us all comfortable, like kids in the driveway taking apart our toys to see how they work.

Happily, through some sort of cosmic serendipity, I find myself in an organization challenging itself to think differently. An organization hungry to change, yet patiently aware of the analysis trap that lay in front of us.  I’m hopeful.

I will let you know what we learn.

I think it’s time technologists in corporate IT settings pay closer attention to integrating systems thinking into their leadership.  To enable our businesses to get the most value from IT, there are some simple steps leaders can take to rethink the way they deliver IT in corporations. These suggestions follow the simplicity and advice of John Seddon of Vanguard fame, incorporates lean IT concepts, and good old fashioned leadership ingenuity. The primary formula goes like this: Understand, Improve, Pull IT.

Understand:
We have created a role within our organization patterned (stolen) from Womack and Jones (who also stole the idea) called a Value Stream Manager (VSM). The primary point of creating this role is to give ownership of a value stream, from end-to-end, to a single person in the firm for a product line. From a systems perspective, it is critical to ensure someone is reviewing the entire value stream “outside-in” (from the point of view of the customer). The point is that we need our managers and leaders to truly, deeply understand the nature of demand for their products, as well as the current capability of the system (that they find themselves in) to satisfy that demand. They need to understand where the waste is in the system. They need to know their team’s primary challenges delivering this value to their customers. They need to know where these processes break down, even if they need to cross organizational boundaries. They need to recognize how value flows from end to end. If you’re a fan of Japanese concepts, ask your managers to “go to the Gemba” – go to the place value is created, the “factory floor”, and see for yourself.

Improve:
The next step in the process is to improve the performance of the system. The clearer the picture is for you from “going to see”, the easier it should be to cut the waste, create simplified processes, eliminate unnecessary steps, challenge the status quo, and refine the end to end system to perfectly achieve the value you intend. This is the reason the system and product or service exists, and value should begin to flow incredibly fast (and smoothly) toward the customer. The colossal lesson here is that IT solutions (at this point in the process) actually serve to HINDER your ability to design a system best suited to create or deliver value for your customers. “IT” makes change harder, more costly, and only serves to codify dysfunctional system design. This step is where Value Stream Management becomes a full contact sport, employing “Kaizen” (small scale, continuous improvements) and “Kaikaku” (disruptive, dis-continuous improvement events) to accelerate the value of your product or service. This is where the vast majority of the value is realized, and all without so much as a discussion about Software Design Specs, Gartner Magic Quadrants and vendor RFI’s.

Pull “IT”:
At this point, the time has come to review the simplified value stream (waste removed and flowing smoothly) and “pull” IT into the process, only where it belongs. With your profound and complete knowledge of the value stream you manage and designed, you are in a position to make this determination and understand if IT can help enable further improvement.

What Have We Accomplished?:
You just shrunk your IT investment dramatically to manage a greatly simplified system. Conversely, you are now deriving considerably more value from it.

Interesting how that works.

I want to try and describe a topic I have been confronted with lately related to agile project delivery – discipline.

There are a number of ways projects and programs can fail.  Teams that aren’t equipped with engaged and talented professionals, suffocating organizational politics, or teams with limited/no access to business decision-makers can all drive the probability of project success to near zero.  And these are just a few of countless anti-patterns.  Agile and Lean frameworks have emerged in the last 15 years to address some of the common anti patterns, and for many teams, this helps.  Unfortunately, there are also some incredibly common misconceptions in organizations about what “agility” means.  It’s expressed in a number of ways and many can be boiled down to one incredibly common phrase, “agile means winging it”.  Of course this is hogwash and, without guidance, many new agile practitioners adopt this world view.

In fact, this is one of the most common misconceptions about agility and the process to achieve self-managed, high performing development teams.

First, give the teams some rudimentary training activities, followed by a “let teams figure it out” strategy.  Just stick teams in a team room, give them daily standups and the 3 questions, sit back and watch the magic happen.  After all, these teams are supposed to be “self-managed”, right?  Doesn’t that imply that we stop managing? 

This line of thinking is misguided, dangerous, and will ultimately raise the probability of failure to new heights.  It might even be worse than the waterfall (command and control) philosophy of the last 30 years.  But, if we dig just a little bit, we quickly uncover in the origins of agility, through methodologies like extreme programming (XP) and Scrum, that exactly the opposite is true.  The rigor does not go away, but the philosophy changes drastically in a number of key ways.

Kent Beck, the father of extreme programming, test driven development and one of the original signatories of the agile manifesto said in his early book,

“When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that from experience I knew worked well. I would turn all the knobs up to 10 and see what happened. I was a little surprised to find that the whole package of practices was stable, predictable, and flexible.”

Does the phrase “Turn all the knobs on the control board to 10” sound like “winging it”?

Discipline and Rigor in an Agile Software Project

If all of this sounds like theoretical pablum, then let’s get concrete.  Below is a list of activities in a typical SDLC, followed by some practices we have found that work, and how we might “turn the knob to 10”.  To be clear about this list, some of these activities would be seen in projects of old, just not executed continuously.  Agile constitutes a mind-shift, similar to how lean manufacturing shifted thinking about building physical products.  For example, in 1970, American manufacturers couldn’t believe that building large consumer products “to order” was reasonable.  Big batches, queued up at every step in the value stream was viewed as “efficient”.  In 2014, the philosophy has changed drastically.

(This list is not meant to be exhaustive, but simply examples to illustrate agile activities)

• Some ways Agile teams amplify Project Management
  • Continuous Planning:  Shifting the focus from a one-time uber-planning event, towards constant planning and re-planning.  This helps teams rely less on “the plan” that was developed in the beginning of the project (when we know the least), to relying on regular planning activities (as we learn).
  • Small Releases:  Planning and committing in small releases, versus big bang delivery at the end.  This step is challenging as the work to make this happen forces leaders to challenge the “big batch & queue” models from the manufacturing processes in the early to mid 1900’s.  (interestingly, manufacturing teams figured out this fallacy as early as the 1940’s and 50’s through the work of visionaries like Taichi Ohno)
  • Customer Engagement:  Ensure the customer is part of the team, or always available to the team to shrink feedback loops and allow for immediate decision making.
  • Process Tools:  Use tools like the planning game, the system metaphor, blitz planning, walking skeleton, MVP, and planning poker to ensure constant and realistic planning is short bursts
  • ROM Estimating and Error Bars:  A project managers ability to build trust by constantly delivering is important.  One risk to expectation setting is a project managers ability (and fortitude) in knowing how to be predictable using rough order of magnitude estimating and clearly articulating the delivery date “error bars” at the end of a release or project.  Even when a date is articulated and credible (meaning a date is imposed for legitimate reasons), the discipline of setting appropriate expectations by de-scoping is critical.
  • Hyper-Prioritization:  Helping teams pull critical features to the top of the priority stack continuously. Manage risk in this way so that we avoid ignoring issues until the end of a project.
  • Team Effectiveness & Psychology:  Constant evaluation of team effectiveness and health. If teams come to a standup daily and talk about missed tasks, or failure to integrate code, or failure to interface with customers, the project manager has the obligation to stop the line and help fix it.  Often, even when the question “what is impeding your progress” is asked daily, most people won’t tell you there’s a problem.  This is where the term “spidey sense” actually helps.  But it only helps when you know how listen, and evaluate reality against a set of agreed upon practices by the team.  That means that we need to expect the team to actually do this stuff religiously.
  • Vision, Roadmap & Release Plan:  Ensuring we have a vision for this project that it’s well articulated and that we have a consumable roadmap of prioritize features/stories.  This plan is constantly re-evaluated and compared against reality.
  • Risk Management:  Activities such as evaluating the interface between vendors and shared service groups within the organization. If team cannot get a shared service in the room to commit with the team and work with the team in a collocated fashion, they have just inherited a project risk and dependency activity.
  • Visual Control:  This can come in many forms, but one well known technique in IT is the Kanban Board.  Slightly different than manufacturing Kanban, the basic premise is that we need to visualize the teams work, limit their work in progress (WIP), and focus our teams on “smooth flow” through the IT system.  The biggest killer of effective delivery in a complex system are invisible queues (places where work products sits in a “wait state”).  If you visualize the steps that work items take to get through a system, you immediately recognize the issue.  You will immediately see very few value adding activities awash in a sea of waste.  Most work, when allowed to be invisible, is “sitting and waiting”.  And, the more you allow teams to multi-task, the more waste you are allowing in the system.

• Some ways Agile teams amplify Business Analysis
  • Continuous Requirement Elicitation:  Agile teams amplify requirement elicitation. We do this by forcing ourselves to understand the businesses view of the requirement using user stories, pictures, models, wire frames delivered by the real users of the request. Different than a BRD, stories allow us to understand why the customer wants with they want, and also allows us to create domain specific acceptance criteria through collaboration with them.
  • Triad Development and Collaboration:  BA staff are constantly interacting with the QA and developers and evaluating the work product as its produced.  This requires enormous amounts of collaboration and work, but the output is typically grounded in reality, versus the fiction of “the plan”.
  • JIT Requirements:  Rework is lessened as BA’s stop building huge requirement inventories that age and rot.  There is a constant questioning and “de-scoping” that happens throughout the projects as requirements are built as they are understood.  This allows the team to “maximize what we don’t build”.

• Some ways Agile teams amplify Software Development
  • Pair Programming:  This technique allows code to be written by a pair, where the “driver” writes code and the “observer” is freed to review the code being built real time, as well as help keep the strategic intent of the feature in mind while code is written.  This technique tends to build high quality, well-structured code, fast.
  • Test Driven Development:  Write a test, watch it fail, write code to make the failing test pass.  TDD helps dev teams write incredibly focused, well designed code that is also “change tolerant”.  This is incredibly important as we introduce refactoring.  Instead of eliminating change, we relish and encourage it.  We also employ the same concept using BDD, or behavior driven development where requirements are evaluated using code.
  • Refactoring:  Mentioned above.  This is critical as we want to allow business users to change their minds frequently so we build exactly the right thing.  This takes extreme discipline.
  • Continuous Build:  One dirty little secret of system development projects is that, no matter if the code builds on your machine (or in your development environment) it is NOT done.  In fact, many, many projects fail because they are never able to integrate and deploy the code.  This technique allows us to get over this hurdle early, and forces teams to confront reality very early in their project lifecycle.
  • Other Concepts:  Agile teams amplify software development by focusing on code craftsmanship, standards, pattern harvesting, and evolutionary design techniques as well as others to ensure that we are building quality into our products versus checking for quality at the end of the project.
  • Automated Testing:  Automated unit testing, pairing, TDD, ATDD, BDD, daily check-in, continuous integration, heavy interaction with BA/QA/Ops, etc are completely necessary

• Some ways Agile teams amplify QA
  • Triad Development and Collaboration:  Agile teams amplify QA by forcing QA specialists into collaborative discussions (daily) on individual user stories and features. Often you will see QA people working on acceptance criteria and helping to train others.  With a testing mindset in collaborative discussions, many features are built with the end user in mind, versus without context.
  • Automation:  QA also is responsible to set up automated testing mechanisms for the “simple stuff” so that we can have the humans move onto the complicated requirements. This requires QA to learn new techniques, become more technical, and interface often with the team (business partners included).
  • Full Team Members:  The QA staff are now full-fledged members of our teams instead of a department that gets handed a work product to evaluate at the end. This is a large shift for this group and one that forces them to be incredibly rigorous in their delivery.

• Some ways Agile teams amplify Coaching
  • Leadership & Psychology:  Agile teams amplify leadership by creating a social contract between professionally equipped teams and the goals and outcomes they are to achieve.
  • Collaboration:  The command-and-control management style tends to build teams that only know how to execute tasks and rarely improve.  This leadership model, however, is bar none the easiest to implement, and typically yields shitty results and demoralized teams. We are trying to get our teams to recognize the business need / business value and the rigor necessary to execute and to improve continually while they deliver.
  • Value Stream Management:  The value stream manager role is a servant leader position to support the team when they can’t deliver in (often) incredibly challenging environments.
  • Gemba:  Translates to “Go and See” in Japanese, this technique is critical for leadership, and one that tends to be lost in many organizations.  This concept is important as every team has different needs and contexts.  There are many developmental levels as well.  For instance if a team needs to deliver a feature using technology that is new to them, a VSM will take a more hands on approach to teaching / guiding.  If teams are well equipped for a challenge, a VSM might employ a more Socratic style to effect appropriate change and challenge the team to improve.  The only way a VSM can know what to do and how to help is to GO AND SEE.

• Some ways Agile teams amplify Operations
  • DevOps: Continuous Integration and Delivery:  Agile teams amplify the operations and deployment of software by forcing teams to integrate every single day through automated “hands off the keyboard” techniques.   Continuous deployment is delivered through a four tiered environment structure so that we can show customers real, legitimately working software every single day (Or as fast as we can deliver it)  That’s important because it allows us to shorten feedback loops to incredibly small proportions and remove waste from the system. For instance I can write the feature today, check it in, build it, have all the tests pass, deploy it, and show it to a customer and get feedback in the same day. This avoids the shit storm of integration issues most large projects suffer
  • TQM:  From an IT standpoint, the total quality movement means something very similar than the manufacturing technique of the last 30 years.  Essentially the team is committed to build quality into our systems versus checking for it at the end.  Buggy, poorly designed, rarely tested mountains of crap software are regular fixtures for Operations teams.  Using many of the agile techniques listed, the number and type of defects introduced into a production state is deeply reduced.  They are also delivered into production in tiny, easily understandable packages that are easy to remove.  The net effect is an incredibly stable environment that has reduced the risk of change to such a degree that, in many cases, the deployments can be fully automated.
  • Full Team Members:  The Ops staff are now full-fledged members of our teams instead of a department that gets handed a work product to deploy at the end. This is a large shift for this group and one that forces them to be incredibly rigorous in their delivery, as well as challenge designs of the team early and often.  This allows the team responsible for operating the system to help affect it’s design.

The following story is entitled “Three Envelopes” – the story that kicked off my foray into Enterprise Data Management:

A woman had just been hired as the new CIO of a large Financial Services corporation. The CIO who was stepping down met with her privately and presented her with three numbered envelopes. “Open these if you run up against a problem you don’t think you can solve,” he said.

Well, things went along pretty smoothly, but six months later, the organization hit issues and she was really catching a lot of heat. About at her wit’s end, she remembered the envelopes. She went to her drawer and took out the first envelope. The message read, “Blame your predecessor.”

The new CIO called a meeting and tactfully laid the blame at the feet of the previous CIO. Satisfied with her comments, the organization responded positively, things began to pick up and the problem was soon behind her.

About a year later, the company was again experiencing issues, combined with serious morale problems. Having learned from her previous experience, the CIO quickly opened the second envelope. The message read, “Kick off an Enterprise Data Program.” This she did, and the IT organization, and morale, quickly rebounded.

After several consecutive worry-free quarters, the organization once again fell on difficult times. The CIO went to her office, closed the door and opened the third envelope.

The message started, “Prepare three envelopes…”

In technology organizations, especially when technology isn’t the core business, “systems thinking” is rarely taught.  I find that interesting and deeply ironic. The more time you spend trying to help organizations transform, the more you realize how often really smart people fall victim to this gap in awareness.  The result:  much of what we call strategy is actually nothing more than ham-handed fiddling.  And that fiddling often has disastrous unintended consequences that slow the pace of change at best, and ruin careers or organizations at worst.  All this to say that in corporate IT, we need to think more like ecologists than technologists.

So Why “Ecology”?

I’ll demonstrate using a concept from ecology called a “trophic cascade”.

Question:  What is the most effective and fastest way to quadruple the size and density of Cottonwood and Aspen trees in National Parks like Yellowstone?
Answer:  Re-Introduce wolves

I know what you’re saying. “Whatchu talkin’ bout Willis?!”

To illustrate the point, below is a description of how the Yellowstone ecosystem lost Aspens and Cottonwoods (and much more) when wolves were removed:

1. Wolves were killed at scale and completely driven out of the park
2. Large herbivores, such as elk or deer, increased in number and foraging behavior changed significantly.
3. These animals over-browsed preferred plants, especially deciduous trees and shrubs like cottonwood, aspen, willow, and oaks, and spent more time in riparian areas.
4. As a consequence, “recruitment” of cottonwood and aspen (i.e., the growth of seedling/sprouts into tall saplings and trees) was drastically reduced, and uncommon plants became rare or were disappeared completely.
5. Long-term loss of streamside vegetation caused major changes in channel morphology and floodplain function.
6. Loss of berry-producing shrubs, and young aspens and cottonwoods, led to changes in the diversity and abundance – and sometimes the outright loss – of other species, including beaver, amphibians, and songbirds.
7. The disappearance of top predators triggered an explosion of smaller “mesopredators,” such as coyotes, which led to further cascading effects.

The term for this phenomenon is a “trophic cascade,” defined as the “progression of indirect effects [caused] by predators across successively lower trophic levels.”

For millennia, humans have attempted to accomplish their objectives by “fiddling” with variables using the simplistic “I want A, so I’ll change A”-style. Ham-handed as it was, I must admit, some of these issues are not simplistic at all. Who could have foreseen that killing wolves in a National Park would decimate aspen trees? Or some species of bird? Or frog?

Thinking Like an Ecologist – Indirect Effects

The item I want you to pay attention to in the above definition of a trophic cascade is “Indirect Effects“.  Ecologists understand this concept all too well.  Ecology is the study of connections and relationships, and therefore an ecological approach in business strategy forces its creators to think about the relationships a particular decision might have on the “system” around it.  Ecology is a foundation of systems thinking and helps us understand feedback loops, indirect effects, and dynamic (non-trivial) interconnected systems.

Just like the decision to artificially remove a “top-of-the-food-chain” predator has disastrous consequences for ALL species in that ecosystem, so too might seemingly rational decisions in IT strategy deeply, and negatively affect critically important teams, systems, processes, etc. (indirectly).

So What Might We Do?

Here are some suggestions to keep in mind as you build forward looking strategies in your IT organizations that uses an emergent, ecological approach to design {adapted from Emergent Design Solutions}:

• Design from top down, and from bottom up simultaneously
• Practice patience and careful observation – Only begin articulating the design when you see or experience the patterns of the system underlying the Emergent Design.
• Practice cultivating adaptive methods rather than prescriptive methods.  Discourage reliance on highly prescriptive methods that typically introduces excess rigidity into the design. Safety and rigidity are useful only as a catalytic structure for emergence.
• Ensure continued health, resilience and deepening wisdom in the system by encouraging adaptation to changing conditions within the system
• Practice Continuous Improvement – No sacred cows – Be open to questioning assumptions.
• Focus on people and their relationships rather than process – cultivate intelligence and wisdom in your human ecosystem.  Process is the guide. It is the wisdom and quality of relationships that determines the usefulness of what is produced.
• Cultivate mutualistic respectful relationships; however be aware that negative feedback loops and frictional forces are often critical to the health of a system.
• Seek to become aware of and engage wholes and nested networks of relationships rather than causal relationships and linear hierarchies.
• Encourage rapid prototyping. Fail successfully and often.
• Seek slow small simple designs over fast, large, complex ones.
• Follow the basic law of emergence – simple principles can lead to the “complex beautiful”.
• Engage diversity.