Montague.tv

The tragedy of the commons is an economic theory which states that “individuals acting independently and rationally according to each’s self-interest behave contrary to the best interests of the whole group by depleting some common resource”.

This shows up in our personal and professional lives in a number of ways, but I would argue that the common resource being depleted at work is TIME.  TIME is a largely unregulated resource in knowledge work, but is indeed one of the key resources used to turn ideas into value for our customers.

In my personal experience, one of the activities that depletes TIME most is EMAIL, among a few others.  That said, I firmly believe that there are no bad actors in the daily use of EMAIL.  In fact, I feel everyone is acting “rationally”.  However, the collective experience is indeed tragic….everyone doing their rational best, yet inadvertently degrading the team’s ability to achieve our goals.

I don’t have an answer, but I am committed to help make it better (for me and for others if possible).  To get started, I thought I would share an interesting tool called “the email charter”.

Enjoy….

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.