Using a Business Canvas in a Government Environment

At least some of you know I worked at the Environmental Protection Agency in the Office of Pesticide Programs (OPP).  At one point I and a colleague created a Business Canvas for our office; this concept comes from Alex Osterwalder’s book, Business Model Generation.  Below is what I can remember of our canvas (we did this about 5 years ago and I did not take it with me, so this was reproduced from memory; it’s mostly correct).

OPP_Biz_Canvas

These high level items allowed us to identify quite a few useful things. I’m not going to go through every box at the moment, but what we found we could do with this was identify weak spots (our IT contractor at the time was a weakness for us) and the primary activities to leverage to create our value propositions.  We did some postulating on new possible customer segments and thought specifically targeting farmers (one of the largest users of pesticides) may be a good thing to call out.

We then did an analysis on various trends. One trend stuck out; while we were a monopoly, we still were subject to market forces. The economy at the time had been in recession for a couple of years, a pretty severe one at that.  PRIA registrant fees funded much of our work. If the economy is tanking, less pesticides will be purchased (farmers in particular will try and get with less to lower costs). This in turn normally lowers the amount companies will invest in R&D. Without R&D, less new pesticides will be rolling out for registration, meaning less funds and work for OPP. There isn’t anything magic here, but the canvas had us postulating on it.  We went to talk with our IT Director as we wanted to find a way of testing this hypothesis as it would have a severe impact on the work we do; he showed little interest.

Later that year, the Office Director for OPP announced we were going to have the least number of registrations on record since the Office was founded. I can only envision had we tested our hypothesis we would have had a leading indicator as opposed to the lagging indicator of watching the number of registrations trend significantly lower than expected.

Most Government organizations have only appropriation.  Even so, thinking in terms of the value propositions being delivered to customer segments and the activities and partners needed to do this can be really advantageous.

Agile Dialogs – Why We Need It

Agile_Dialog_Logo-2Recently I have noticed conversations in the Agile Community getting increasingly hostile.  Whether it be about scaling, self-organization, estimation, or a variety of other topics, there seems to be some reason one side or the other has to be ‘right’. I’ve personally been in the crossfire and not once was there any inquiry about why I had my opinion, only some circumspect attribution as to my opinion being off the mark.

Perhaps it was… Perhaps not… Who is the judge?

So something I and a colleague (@Ryan Ripley) have decided to try is put together is an unconference to bring together people to discuss these thorny conversations. And by discussion, I mean dialog, not debate.  In other words, the point is not to prove someone wrong or right, but rather understand there position and whether it is valid for your context.  Using a philosophy espoused by Peter Senge, we need to expose and elevate our assumptions so that we can find what works and doesn’t between the positions. We call this Agile Dialogs and have set-up a website (rudimentary at the moment).  Our first dialog will be about how to predict value with or without estimates. If you have an opinion for against or somewhere in the middle, we hope you will join us. You can find out more info at the Agile Dialogs website; please consider taking the short survey at the end and of course joining us on November 13th at the Navy League Building in Arlington, VA..

The Dimensions of Choosing a Scaling Approach

boy_Ladder_into_clouds

From Issue 26 of Compute! magazine, July 1982

As many folks know, I have been exploring what scaling means in various discussions. I am no fan of the Scaled Agile Framework (SAFe); I got and let lapse my SAFe Agilist certification. I chose to get it mostly as it was offered to me at extremely low cost AND it allowed me to hear about what it was about straight from someone certified in it. I am not here to bash it though; it has its place. It’s not for EVERYWHERE you need to scale as it is portrayed though. This post will explore the scaling approaches available to you and when to apply them.

Let’s start with some “definition” of what is meant by scaling first…

Generally, when folks say they want to scale something, it means they want to expand its use or its capacity. So to now to fill in the ‘it’, to expand Agile’s use is to replicate Agile teams over more of the organization and to expand Agile’s capacity is to allow what is currently working to do more. These are different classes of needs. The act of replicating Agile teams (and more importantly its benefits) is solved by “scaling out” and requires thoughts on cultural change, choices of approaches and practices, and how these teams should be instantiated and organized. The act of expanding capacity of current Agile teams to accomplish more is “scaling up”. Here the choices are how to help existing teams work together effectively and gain more product throughput. The confusion on which of these apply stems from the fact that both expand overall organizational capacity.

So I’d like to provide a means for thinking along a couple of dimensions to determine which one applies as you decide to scale up. People in an organization may be choosing different approaches based on what their needs are at any one time, but I want folks to understand when and why to choose specific approaches. I plan to apply the Cynefin framework to classify problem spaces as simply a means of determining what types of approaches may be more effective. Lastly, I want this to focus on the end result of your organization’s value stream and what it needs, not on simply making choices for your organization in a vacuum.

To do this, let’s look at the following graph; it has two dimensions, both attribute of the end product lines of a value stream. I actually use the term product lines (could also be service lines) to indicate that these have an inter-relationship. So the vertical dimension is one of interdependency among products, which formulate a product line. Let’s take a concrete example: an Enterprise Resource Planning system. There is a core product and a set of product modules; this is a product line produced by a value stream. The company may have a different product line totally unrelated; say machinery control software used in factories that may be its own product line – the end result of a different value stream.

The second dimension is how responsive a value stream (and the products produced by it) may need to be to the market. (For organizations not driven by a market, say government agencies, replace market with mission.) As the market changes, so does the needs of the resulting products (or services) the organization is providing.

Scaling_Dimensions

These two dimensions can define the ‘space’ for our organization’s business agility needs. So let’s explore this space now to understand how and when to apply scaling….

If our market (or mission) is slow to change (i.e. our demand for market responsiveness is low) AND we have few products with interdependencies, then we are in the Obvious domain (this used to be called the Simple domain in Cynefin terminology). In this space, we have a simple, stable product line. We are probably the market leaders with little competition to worry about. If this is our domain, we don’t need to worry about scaling; if we are transitioning to use Agile/Lean approaches, we are probably doing this to remain ahead of our competition as a proactive component in our strategy (or maybe we have always been Agile or Lean). The key here is few products and the need to respond to external market forces is low; our need for agility is low.

So what if the market is rapidly changing or the mission is rapidly evolving? Our need to respond is high… This is where start-ups generally find themselves; they are constantly reacting. This is the Chaotic domain. If our organizations are still exploring how to fit customer needs, there may be several competitors trying to do this as well. There are no market leaders yet. Or maybe we have a small product line and have found ourselves facing new and stiff competition. This demands agility, but not a need to scale as the product line inter-relatedness is low.

As the number of our product lines increases, so does our need to scale our Agile capacity. This may be able to first be accomplished by simply using some lightweight activities like a Scrum of Scrums to help coordinate interdependencies. Eventually though, we’ll need to think more formally about how we want to scale and when we look at interdependent product lines and whether a scale up or a scale out approach is more appropriate.

So let’s return where our now interdependent product lines have market stability; the demand to respond to market changes is low. The primary driver now for any agility is to coordinate product line activities together into cohesive releases. We may be a market leader across most, if not all, of the interdependent products that make up our line. A scale up approach can handle this need for cohesiveness via coordination. We can roll the products into a program and use it to coordinate activities, thus a hierarchical approach to organizing will work. Approaches like the Scaled Agile Framework (SAFe), Disciplined Agile Delivery (DAD), and the lesser-known Enterprise Agility framework can be applied. We can take time to analyze the situation and provide a means for gathering product needs and rolling them out to the product teams; this is the Complicated domain.

If the need to respond to the market though is high, each individual product (within the product line) needs to evolve fairly rapidly so that it can meet customer needs. This does not mean that there should not be some form of congruency among teams. Our scaling approach should be one of scaling out teams that are networked together to maintain this congruency; there needs to be allowable deviations so that we can keep pace with the market (or mission) needs. Each deviation needs evaluation to ensure this isn’t a new path for the entirety of the interdependent product line. This is where probe-sense-respond comes into play, the Complex domain.

One thing to remember here is that the organizational structure and its communication paths will create the coupling of the products. This is Conway’s Law. The result for most hierarchical approaches will have product lines that are tightly coupled, while for most networked organizations, loosely coupled product lines will result.

I’ll close this post with a final thought; regardless of the scaling need, who is choosing it? Is it your people in the organization or is it someone dictating how and when you need to scale? This is the difference I see happening is that people are not exploring how they themselves can scale, but they are being told how to do it. Use this as a tool to help your people figure out what will work for them…

Introducing The Facilitation Kernel

Now that I’ve reposted a few older posts, I’ll give a new one…

One of the things I often get called upon to do is facilitate; meetings, workshops, retrospectives and other occasional agile ceremonies are all meetings I get called upon to facilitate.  I also find myself facilitating teams talking to one other (which actually goes into the encouragement to get together, not just the resulting meeting session) and sometimes what normally would be one-on-one sessions.

A few years back, I took one of the IC-Agile certified courses on Facilitation; they presented what they called the Facilitation Stance.  It’s useful.  (Because of possible IP ownership issues, I won’t present it here…) One thing that didn’t feel right was the treatment of maintaining neutrality as a facilitator; it wasn’t treated as core.  As I gave training to others on facilitation, they also seemed to question that lack of centrality.  Another area that I personally got, but others struggled with was the “stand in the storm”. So I began rethinking how to depict the concepts and came up with what I think is something easier to understand.

Facilitation_Kernel_Final

I call this the Facilitation Kernel.  It places Maintain Neutrality central to the entire concept.  This is important as if I am asked to render an opinion, where I am no longer a neutral party, the entire rest of the Kernel can be sacrificed.  This is particularly true if I am asked to give insight from experience or observations.  The Facilitation Stance doesn’t make this as explicit as I would like (though it does acknowledge it).

My personal feeling is that the ‘Stance’ over complicates itself with the internal “being” and external “doing” (of which maintaining neutrality is an external “doing”.  This may be just me, but I find neutrality at the core.  In the “doing” circle, I place Modeling Servant Leader Behaviors, Leading the Group’s Agenda, Promoting Dialog, Decisions, and Actions, and Harnessing Conflict. Let’s dissect these one by one:

Modeling Servant Leader behaviors is very important to exhibit as a facilitator; you are there for the team and to serve them.  You are not there to serve someone else or yourself.

By Leading the Group’s Agenda you are not just Stance’s Holding the Group’s Agenda; you are also leading them through their Agenda, whether explicit or implicit through design of the session or keeping a watchful eye and ear on what is occurring and needed.

In Promoting Dialog, Decisions, and Actions (which encompasses the Stance’s Upholding the Wisdom of the Group), you are gently nudging the group to a bias of action versus inaction and making assumptions explicit so that good decisions can be made.

And lastly by Harnessing Conflict you are doing more than simply “Standing in the Storm”, but are helping people through their differences to a positive outcome.

To do this, you need to maintain three states of “being”; self management (which IMHO encompasses self-awareness), group awareness, and situational awareness (this may be my aviation background talking to me). The alignment I have chosen in the model is important.  In order to Model Servant Leader Behaviors, I need to mostly manage myself; the situation and group awareness are far less important.  To Harness Conflict, I need to be able to be wary of where the group is currently (in terms of emotional state and energy) and the situation at hand (in terms of positions and opinions).

I places the Lean and Agile Values & Principles outside this Kernel as if I wasn’t facilitating in this realm, it may be replaced some other set.  I think this makes the Kernel fully aligned with what any general facilitator may provide.  I know I have found this useful when considering facilitating more generalized sessions such as Open Space (which I have had the opportunity to do twice) and various workshops.

What do you think? Is this congruent with your thinking on facilitation?