Balancing Global & Local Authority within the Organization

Organizations frequently have difficulty managing diversity as they scale to larger number of programs/projects. A balancing act is required to determine how much freedom to give versus how much control to take when determining how to manage and govern. Most clients I have spoken to describe the pendulum as having swung in a specific direction.

Many organizations I have worked in or what appeared to be laden with a top-down, restrictive, and prescriptive governance approach, or conversely, are not properly engaged with what's going on, suffering from ad hoc, siloed initiatives that appear out of control.

Many folks I talk to have a very partisan/polarized view around which state is better. The agile community tend to bristle at any oversight and governance that comes from outside of the team, many rightly point out that governing from afar isn't particularly effective, and the people doing the work have the best context and knowledge around what decisions are necessary to manage their work.

More traditional mindsets advocate that enterprise initiatives run through strong governance, typically by some kind of counsel that reviews spending priorities,make sure that projects are being run according to appropriate quality, budget, etc. these folks point out that extra work and control is required to make sure that all the pieces in an organization are moving in the same direction, share common standards, and that work is aligned with strategic objectives of the organization.

I strongly advocate that both of these perspectives have something to offer...


A global perspective and strategic thinking is required to get you where you need to go, however, it won’t get you all the way to your destination


A good metaphor for global governance and global authority is a cruise line. A cruise line is a great vehicle for moving a large number of people in the same direction. The cost of moving each person is relatively low, and it's easy to drive efficiency when using such a large vehicle.

In other words, global authority is great for setting direction, driving uniformity of purpose, and increasing efficiency.







Unfortunately, a cruise ship is not very agile, if you try to turn too quickly using a cruise ship you will most likely fall over.

Organizations that rely exclusively on top-down, command driven approaches, and standardized/commoditized processes we'll never have the flexibility required for today's fast changing business environments. While costs might be contained, this type of organization is unresponsive to the market, and takes a long time to deliver.


No one would ever think that you could take somebody all the way to their destination by using a cruise ship. Left unchecked, relying solely on the global authority will cause your organization to crash.

Optimizing based solely a global perspective can interfere with organizational agility, causing a stall, or even a crash

Local autonomy is required to be flexible and responsive to change, but can be expensive, and makes coordination and alignment difficult

Likewise a good metaphor for local authority is a motor boat. Motorboats allow you to travel fast,and they can get a small number of passengers exactly where they want to go with precision in a very short period of time.

Also, motor boats are more fun to ride than cruise ships :-)

In other words providing local authority/empowerment enables workers to make decisions as they need to to create value, less time is spent focusing on the organization and the organization's way of doing things, and more time is spent looking outwards, and what the market is demanding.

Motorboats are not just fast, they are agile. Organizations with a high level of local authority can react to, and even anticipate change, delivering quickly and being responsive to their customers.












Motorboats however, are not fuel-efficient, and are not the best choice for long-distance travel. I don't know anybody who would consider taking a motor boat all the way across the ocean. Local authority and team empowerment allows you to be fast, but it can be expensive(per passenger) and a lot of resources can be consumed in order to accomplish something.

it's hard for organizations to get any kind of efficiency through common approaches if there is no centralized authority or centralized governments, too much localized authority creates a suite of many organizational silos, all operating independently from each other.

local authority can make it hard to optimize and react to global market trends, and bigger issues that are hard to see from a local perspective.

This can cause smaller initiatives (and even larger ones) to be completely upended, and marked as failure because of forces much larger than within an individual units control.

When left unchecked local decision-making can erode organizational value, creating independent silos that conflict with each other

Use global authority to set global priorities, enterprise policies and align capacity to objectives, use local authority to come up with the tactics on how to respond

Since I'm talking about ships, the Coast Guard provides an excellent example of how global authority and local authority both play an important role in meeting both strategic and tactical objectives.









Overall objectives and strategic directions are made at the highest levels of authority. Policies, solutions, and tactics vary greatly depending on the exact situation, and context.

organizations should not be overly focused on one-size-fits-all solution/processes/standards, there are a huge variety of problems to be solved, there are a large number of solution sets, and approaches handling these problems.


What's even more important to ensuring a successful mission is that units on the ground are empowered to make decisions just in time based on information gathered using tight feedback loops like OODA(Observe Orient Decide Act).

Higher-level authority figures trust localized units because of the deep level of training that they have received, very detailed policies and instruction sets around how to handle work have been provided for a large number of situations.

Localized authority is empowered to respond to needs that they recognize because troops on the ground have been giving the tools and training to do so. Tight feedback loops between localized units and global command centers ensure that adjustments can incur should individuals strayfrom strategic objectives.

How does this apply to organizational governance and authority?

Create “containers” made up of policies, decision rules, and explicit boundaries that empower workers to make decisions independently ,but constrained by the needs of the organization

In this model senior-level authority figures in organizations switch from trying to govern all decisions to actually creating a governance framework that is based on clearly understood policies. These policies allow managers and staff to operate and respond to their individual context while ensuring that they still align to the greater objectives of the overall enterprise. Behavior can be codified into decision rules that dictate the value of making a certain decision. For example if the goal of the program is to create a lightweight product, a decision rules could be configured allowing engineers to spend a certain amount of design time per pound of weight shaved from the product.

I've been working with a number of clients on extending the Kanban approach to address concerns like governance, portfolio/strategic prioritization, and other enterprise concerns, I believe Kanban, and many of the concepts described in "The Principles of Product Development Flow" by Don Reinersten, provide the basis for creating a localized/global authority mechanism. This mechanism would leverage explicit capacity and demand allocation, decision rules for prioritizing work, and ensuring that enough feedback exists across multiple levels of the organization.

In another post I'll describe this kind of framework in more detail.

Agile belongs in a Kanban, not Tables

Alistair Cockburn put together a fine article on using various tables to track value, risk, and quality in a agile project.

I countered on twitter that a Kanban board would be a better a way to visualize this information. Alistair didn't quite grok what i was getting at and asked for a picture, now being such a boig fan of Alistair, I couldn't refuse...

:)

A Macro View of Agile

Despite the fact that the agile manifesto was signed over ten years ago agile adoption remains uneven.

One manifestation of this is how often I have clients ask me for even a simple overview of what I mean by agile.

I decided to put together this simple map that shows how the pieces fit together.






IMHO lean thinking and tools like A3 and Kanban tie all of the agile pieces together, and help organizations think and behave with agile principles in mind.


Supplementary agile practices like BDD and DDD integrate modeling with agile practices to help core agile team based approaches.

Core agile methods like XP are just that, and create the foundation for delivery excellence.

Technology focused movements like DevOps focus on upping the quality of from a technical perspective.

And while some will groan, RUP or UP provides some good lifecycle stages, roles etc,etc that can help scale agile.

The Hockey Maturity Model

IT Departments often fond themselves in a state of "low" maturity, typified by radically inconsistent processes, total lack of standardization, and a lack of transparent accountability.

Management frequently points to a lack of specialized skill sets as a contributing cause to lack of efficiency and delivery expertise. A typical reaction to this state of the nation is implement highly prescriptive process alongside very explicit (and rigid) roles and responsibilities. I've found it to be less than helpful to debate any of these assumptions head one. What I have found to resonate with some clients is what I call the "Hockey Maturity Model".

IT Departments often find themselves in a state of "low" maturity, typified by radically inconsistent processes, total lack of standardization, and a lack of transparent accountability.

Management frequently points to a lack of specialized skill sets as a contributing cause to lack of efficiency and delivery expertise. A typical reaction to this state of the nation is implement highly prescriptive process alongside very explicit (and rigid) roles and responsibilities. I've found it to be less than helpful to debate any of these assumptions head one. What I have found to resonate with some clients is what I call the "Hockey Maturity Model".


--The Little Leaguer-

The first stage of maturity is what I call the little leaguer, imagine this is the frost year your child is playing hockey with others equally new to the game. gameplay is typified by both teams swarming the puck in a chaotic fashion, lots of chopping and whacking at the puck, very little passing, and no teamwork. This is your ad-hoc, uber generalist organization, occasionally a goal is scored, but heroics are required and effort is extraordinary.





--The Table Top--





The second stage is what I call table top hockey. Now picture you are playing hockey using one of those table top games, you know the ones where different player positions located in specific slots that allow movement pre described ways so that you can simulate the typical movement of a specific position.

Now this a better way to play hockey than the little league approach, passing is now encouraged, and individual players in the game have clear accountabilities creating a more professional atmosphere. But closer examination reveals flaws, individuals are restricted from working out of pre set boundaries making it sometime impossible to get at the puck, and truly magnificent plays are impossible to pull off. Performance peaks quickly, and play satisfaction is low. This feeling of mediocracy and dare say stagnation is one that I've felt in organizations that have become to focus on process, and putting boxes around their employees. Look for symptoms like a developer refusing to test code because it's not his job.


--The Integrated Team--




Now let's think about how hockey is played when professionals, or even experienced amateurs do it. In this case all players are allocated to a particular position and have differentiated skills and responsibilities necessary to help them excel as an integrated team. What makes this type of hockey different is that it would be unthinkable for a defensemen to not try to score if he circumstances give him a shot. Likewise you'd never hear anyone committed to playing hockey refuse to deflect a shot on his goal. Key here is that explicit roles don't get in the way with what's more important, and that's winning the game.

Truly effective organizations deliver software this way, specialization, and clear roles don't get in the way of the need to pinch hit, and step out side of job descriptions. Net net, teamworks trump all other concerns.

Extending Value Stream Mapping Notation For Value Creation Networks

..

Extending Value Stream Mapping Notation For Value Creation Networks

When I first started reading about and using lean in a context for helping improve software delivery performance, the tools I used were either classic lean techniques (e.g. value Stream mapping) or agile practices in a slightly rebranded way (i.e. my scrum board is a kanban). This was in large part due to the fact that most of the literature I was exposed to was material straight out of the manufacturing world, or the various Poppendick books based on lean software delivery, which are in my opinion great reads, but primarily focused on explaining why agile works using a lean vocabulary, rather than providing ideas around how lean can be used to extend some of the practices already in agile.

Over the last several years I’ve had the opportunity to interact with some great minds within the lean systems and software community. Obvious names like David J. Anderson, Don Reinersten, and Alan Shalloway come to mind, but more importantly the general discussion around the lean for systems and software community has really reshaped the way I think about building systems of work to support the delivery of high-quality software.

One tool that has fallen out of favor with a significant number of the community is value stream mapping. Interestingly, this is a tool I continually reach for when trying to define either the current state of the software delivery process, or to help various stakeholders come up with what the various handoffs, activities, and order of work should be for future project, future program, or to support a future organizational design. That being said, I tend to agree with those in the community that feel that the value stream. mapping notation as it exists right now contains some significant flaws. The notation is really meant for stable, serial/linear processes. There is no real way to describe different strategies to handle variability, or the non-homogenous nature of the work entering the system.

I’ve since come up with a notation to extend value stream. mapping with some simple notations that allow me to model what I perceive to be a value creation network. The notation is certainly in its alpha form, I’m sure I’ve missed a whole bunch of concepts. I’m sure they’ll be others out there that also think that the notation still leads to defining processes that are to serial in nature, I’m hoping to post some example diagrams showing popular methods and approaches that are nonlinear in nature (e.g. extreme programming) and I’ll tweak the notation as I go.

If anybody wants a stencil that I created for Omnigraffle, you can find it here. This will allow you to leverage the value creation network notation to build your own diagrams using your Mac or iPad.

Classical Value Stream Mapping Notation

the icons below represent classical value Stream mapping. This should be familiar to anybody that has done value Stream mapping before, I have limited myself to only a couple of essential artifacts. key

Explicit Activity that needs to be completed for value to be created

one of my favorites, the need for multiple activities to be completed by a co-located team, in order to deliver value

of course activities need people to get things done, color-coded for different specialties.

When people work, artifacts are created, and inventory builds up (unfortunately).

Ye old push model. Build a bunch of stuff, when it’s finished push it to the next team, hopefully they have capacity because your top-down upfront plan was so perfect :-)

or we could always allow downstream teams to pull work when they have capacity to do so, triggering that an upstream team can start work

people don’t just move inventory around, they also pass along information, this is probably even more critical to knowledge work in this for manufacturing

Extending Value Stream Mapping to Handle Non-Homogenous Work

Of course one big difference between knowledge work in manufacturing is the number of different sources of work, and how the risk, size, and knowledge required to do the work can change dynamically. Work also can break up and merge repetitively, and work can be be completed in parallel.

Here are some notations that I’ve used to try to capture some of these concepts

All knowledge work stems from a good idea

hopefully most work delivers business value, work will often come in different sizes...

occasionally there will be emergencies, let’s hope that these emergencies are small in size

business reality will dictate that some work will have a fixed date, this also varies in size quite often

any optimal system should also spend a certain portion of its work on fine-tuning/optimizing itself, keeping technologies up to date, rThis Work Can Get Really Big (and Platform Upgrades)latform upgrades)

work can become blocked, which requires management intervention

hopefully do system will also generate ideas on how to improve the work , not just generate work itself

knowledge work will frequently start as a very large concept, scatter into finer grained projects, and further scatter into releases/stories/features/use cases/etc. so that it can be completed in small atomic units

likewise knowledge work will aggregate from discrete specific units into something of business value, think of how individual user stories can merge into a business release that the customer wants

describing worked in terms of features has become increasingly popular in the lean/kanban world

a minimum marketable feature set represents the smallest collection of features that could be deployed as a unit giving meaningful business value

Notations for Knowledge Worker Interaction Patterns

Here are some patterns that I’ve observed using various different delivery models, with some thrown in from my readings of kanban and flow

an agile favorite, let’s get a dedicated team, hopefully cross functional, definitely co-located, and have that teams swarm on the various activities necessary to create value

teams can be formed as necessary from a greater pool of similarly skilled resources

there are situations (and I will argue this to death with the agile purists folks) where a cross functional team can leverage the help of external specialists for specific tasks. Think of security/vulnerability specialists, legacy subject matter experts, or masters in a very esoteric business domain. In this situation teams can pull from a pool of specialist resources for the duration require, after which the specialists go back into the pool. this is a great pattern to handle need for resources that do not have enough stable demand within any specific team to be a full-time member of that team, book still need to work closely enough at that team t that creating a downstream specialist team doesn’t make sense

a certain portion of the work requires differentiated knowledge because of business or application concerns, or there is a reasonable amount of variability in demand across numerous business channels. It may make sense to create channel specific entry points for each business client, but to back the people representing the multiple entry points with a common pool that possesses common skill sets necessary to handle the different channels of demand. This only makes sense if the multiple entry points are supported by some kind of common/cross cutting set of skills

Notation That Described Various Strategies to Handle Variability in Demand

Again reading the works of Reinersten and Anderson have helped me to articulate many of the strategies that we knowledge workers use to handle variability, having these explicitly described I think is very helpful for all the obvious reasons

if there’s one thing that lean and agile thinking teaches us, it’s not to underestimate the value of slack time. Smart agile teams reserve capacity explicitly by limiting how many hours in the day are reserved to code. The greater the cost of delay is for a particular piece of work, the more critical it is that capacity be reserved to handle variability

if work is coming into a system with various risk/priority profiles, then it makes sense to have an understanding of this demand and to load balance it. This will allow knowledge workers to drop low priority work for higher priority work whenever it comes into the system. I really like this pattern as it allows knowledge workers to reserve capacity for high priority work by making themselves busy doing lower priority work that is still essential for improvA ent

A T shape resource is a resource who takes the time to make sure he is competent in both upstream and downstream processes. Not he gets more senior the T not only gets better at his core responsibilities , he also makes sure that he can contribute in other areas as well. Creating these kinds of people cost money, and causes them to be less effective on their core capability than if they practiced at their primary concern . This however is a worthwhile economic trade-off in almost all aspects of knowledge work, due to the high degree of variability. It is very hard to predict the fact amount of work required for each skill set, requiring more senior people to have a balanced set of skills is one of the best strategies out there for dealing with fluctuations demand.

supporting 2 or more different teams with a part-time expert is another excellent strategy for handling variability. The part-time expert spends enough time with two teams to understand the context of both to make himself useful as a part timer. When one of the teams faces a spike in demand, the part timer switches to full time (plus overtime if necessary) and significantly increases the teens capacity until things get under control

Some Other Symbols that I wasn’t sure How to Categorize¶

unfortunately some work has to get done through meetings, would it be nice if this is never so...

and the evil stage gate never seems to completely go away...

decision rules are great ways for constraining the environment so that not every decision needs to be made over and over again. Of course great care needs to be taken that decision rules do not become inflexible and permanent. I I find that a organization need to be relatively sophisticated and mature to approach this concept in an appropriate way.

Some of the best thinking from the agile world revolves around how to create automatic signaling that kicks off a automated activity based on certain events, think of continuous integration, test driven development and the like

here is a picture of the entire stencil

........

..