Another Move Back to Central IT for the Feds?

Federal Computer Week recently ran an opinion article by Michael Garland, a former BearingPoint procurement veep and currently under contract to help the government with Acquisition Reform; you can read this article here: “Why acquisition reforms fall short“.

In this article, Mr Garland states the following, “…there is no centralized, integrated strategy supported by a corresponding organizational structure. The government has been intensely fragmented when it comes to IT acquisition.”  He then purports how the Government should act as a centralized enterprise when it comes to acquisition and management of IT. He begins with a statement that the Government acts as a “holder” of a portfolio (much like a financial portfolio) and then later states the following:

“That approach lacks cohesion and inhibits the ability to develop and exploit best practices. It has been an ad hoc structure devoid of an enterprise strategy. The fragmentation also hinders the ability to develop valued expertise or deploy any of the various continuous improvement methodologies that have been so useful for the private sector.”

Having worked for many an agency as a Fed, Navy officer, or contractor, I can say that centralization causes many woes, the largest one being that no central IT strategy (acquisition or otherwise) can be attuned to an Agency’s unique needs.  Integrating custom systems of systems command and control software for a Naval ship is entirely different than acquiring a human resources application, to deploying a mortgage loan lending package, to building a custom-built analytical program for determining pesticide safety.  It appears his mental model is all about cost efficiencies and not value production.

What can be promulgated to help each agency is guidance (not rules) for helping procurement officials make the appropriate decisions on contract types so that risk can be minimized and managed effectively locally, while also producing maximum benefit/value for the Agency’s mission for supporting the American people. Central rules destroy customer experiences in almost every industry. (Actually only the most risk averse/safety-centric industries gain from central rules.)  Central rules sets are designed for cost efficiency at the expense of effectiveness in delivery; I contend this is not a strategy to pursue.

I also contend that a portfolio of holdings is EXACTLY what we want; and what we want to extend is thinking that helps our brokers (the Agencies) invest better on our behalf in ways that respect their missions.

Think alignment over control…

—–

Follow-up: a colleague passed me a pointer to an 18F article on Ghost Writing RFPs. This is a step in the right direction if this is used to enable improvement throughout agencies in how they write RFPs.  Unfortunately, at the point of writing an RFP, an acquisition strategy may already have been made and depending on the flexibility and remaining options (in terms of time) to modify these later, the various Departments and Agencies may have a tough time taking advantage of this service.

Locking Cadences to Optimize the Whole Scaled System – Not Really…

I had a reminder through some recent comments that people view locking cadences in step as a means for optimizing the whole of the system and not for individual teams (by allowing them to choose the cadences at which they wish to deliver).  this is used to justified in the case of when you have a need for a program.  I think this is missing the point, so I am going to go through some explanations.  I really like how Jurgen Appelo has applied David Snowden’s Cynefin framework to work systems so I am going to illustrate my rationale using some of his work.

So let us start with a team:

Programs_Explained_in_Mgmt3.0_speak-1Teams are simple to understand, predominantly because of their simple structure with few people; however they are  complex in nature because we are dealing with humans.  Sometimes we can’t even predict our own behavior, much less a whole team’s.  Next, let’s think of where most policies and processes wind up…Programs_Explained_in_Mgmt3.0_speak-2Good processes (and their accompanying policies), try to add order into systems; this is particularly true of many of the scaling systems out there (SAFe, DAD, to some degree LeSS) where structure and process is imposed on the ‘program’ system in order to achieve more predictability.  Unfortunately most of these are quite complicated in nature; some have helped by providing well diagrammed (some even animated) pictures, but there is still no denying the complicated nature of their arrangements to attempt to get predictability.

This is very well intentioned, yet what happens in reality is the following:

Programs_Explained_in_Mgmt3.0_speak-3The complicated-ordered process thrown on a simple-complex team yields a complicated-complex result.  This isn’t achieving what we wanted… and we’re just talking about a single team! And if we expand this to many teams such as we would have in a program, this is the best case we can hope to achieve.  It may become complicated and chaotic as the additive results yield less predictable results. Programs_Explained_in_Mgmt3.0_speak-4So why is this happening?

It’s because we humans create complex social systems.  There’s a reason why we value individuals and interactions over processes and tools; the latter can be complicated in nature perhaps and yet they are ordered in nature, while people systems can be either simple or complicated, yet are always at best complex.  People aren’t robots, so our behavior is never entirely predictable.

And yet… we try and put systems in place that have unintended consequences, such as imposing cadences on teams to get more order (predictability) out of them.  Think about the last time you had something forced on you that you disdained; it probably had you at best working at less than motivated – it sucked the motivation out of you, so you didn’t perform as predictably as desired. And at worst case, you went and found a new job and now the team was thrown into reforming and restorming to get back to renorming and performing.

Each team and its individuals will be different, perhaps some won’t care that much about the ‘normalization’ of cadence.  But some will have deep negative impacts that will occur.

So I ask you what ‘system’ are we trying to optimize? The process or the people?  Imposing a process to de-optimize how humans perform seems to me have many potential negative longterm effects; besides losing good people or demotivating people, even if this happens to only one team out of ten, it sends a signal that people don’t control their work system at all, that any element can be changed on a whim. Basically apply the pants principle and let teams adopt as simple a process as possible, including the orchestration.  As Saint-Exupery said, simplicity is not achieved by deciding on not when there is more to add, but deciding on when there is not more to take away.

Programs_Explained_in_Mgmt3.0_speak-6 Does this mean that locking cadences can’t ever be adopted? Not at all… Facilitate teams to select a good cadence within themselves firstand then collaborate with other teams to find how to best orchestrate delivery.  This may result in lockstep cadences or perhaps a creative branching and merging strategy. This could be done during team chartering by holding a futurespective. Regular intra-team retrospectives could help teams identify when changes need to occur. Simply installing a locked cadence at the beginning may result in a sub-optimal approach as it overlooks the people part of the equation.

Calculating Joy and Fulfillment

At the Path to Agility, several of us got together and had an open discussion about what possible relationships Happiness, Joy, Purpose, and Passion had.  In attendance was Ryan Ripley, Faye Thompson, Joe Astolfi, Jeremy Willets, and Kevin Goff.  Others dropped in from time to time as well and provided some input.  Ryan kickstarted it with a premise that focusing on pursing solely creating a happy team(s) destroy longterm joy and fulfillment.  The discussions were contained in the photo of all the stickies (semi-organized into various areas):

image1

We discussed many different things, and I’ll mostly focus on my take aways and contributions.  We’re still discussing this (primarily via twitter currently), so it’s an ever evolving concept and I am not sure we’re all in agreement yet.

Happiness was felt to be a short term thing, while Joy yielded a long term gratification. I started my (useful) input showing how happiness of a team over time can be captured via a Niko-Niko calendar and that this is useful in understanding whether a team is working well together.  Ryan still said that a happy team may not be joyous, but we did at one point all seem to agree that at some point if a team had little to no happiness occurring, then it was unlikely they would feel joy.  This got me to drawing a stacked area chart; the x-axis is time and the y-axis is the amount of joy felt by the team.  The areas that add up to this happiness (which is more volatile), passion (mildly volatile), and purpose (little volatility).

I wish we had spent more time coming to some form of agreement on Passion and what it means; I defined Passion as the collective sum of the motivations I have.  I really like the CHAMPFROGS set that Jurgen Appelo has created.  I think some of the inconsistencies showing up in our Twitter convos deals with each of us having a different mental model around passion.  These passions can change some over time.

Alignment on a purpose is also very important and alignment of this purpose with my longterm passion is also very important. It’s this latter part that gives me motivation to pursue it, yet if it is a continuous unhappy environment then I will also find it difficult to stay focused. We ultimately settled into this equation, which I wrote onto the whiteboard under the advertisement for our session:

Joy_equation

This equation states that Joy is a function of the Length of Happiness I feel multiplied in the pursuit of Purpose in addition to the Passion I bring to it.  Thus if I have little time I spend feeling happy as I pursue a purpose, then I will not feel longterm Joy.  Likewise, if I have no purpose, I also get no Joy either; this because Joy is the feeling of Fulfillment we get (Joy = Fulfillment).  Lastly, it needs to be aligned with passion as if my passion would rather pursue something else, then I likewise will have little Joy.  If we bump this from an I to a We for a team or organization, it means getting alignment on purpose and passion while having a supportive environment which increases happiness.

The important aspect to me though is the role of leadership in this; when exercising leadership, our job is to discover people’s passions, help them see how they align with a collective purpose.  It also means that I want to create this supportive environment, but not pursue short term hygenic treatments to make people happy, they need to be factors that create longterm possibilities for team members to be happy.  An example of a longer term factor would be one of safety as one would find in Anzeneering. To create Joy, leaders (which in a self-organizing team can actually be any team member)  is the application of the Antimatter Principle to attend to people’s needs.

Addition (that I forgot to mention, but it was discussed and is very relevant), Tobias Mayer has an excellent post that if you attempt to encode someone’s values, you kill that person’s spirit.  This can be true even what is being imposed is happiness; this will not create longterm Joy.

Skills for a Facilitative Leader

toolbox

As folks know, I have been noodling on what a style of leadership I’ve deemed as facilitative leadership.  Some may be wondering, what skills do I need to be a facilitative leader.  I’ve given it some thought; it’s certainly not exhaustive and still may need some tweaking, but here’s some basics I’ve thought of so far…

  • An ability to engage co-workers in a manner that is both egalitarian and fruitful; co-workers includes peers, subordinates, and superiors – granted non-equal in authority people have to also release that relationship on their side to be wholly effective, suspend it if you were, but you as the facilitative leader should not be holding onto that relationship.
  • An ability to serve others and help fulfill their agenda over yours as long as it thoughtfully considers others points of view in a non-destructive manner.
  • An ability to elevate the assumptions of others in a non-threatening manner, whether it be about their agendas, intentions, or ideas.
  • An ability to humbly inquire on the path or agenda being taken to ensure it is right for the moment.

These four abilities/skills are my current essential feelings as to what is necessary for being a successful facilitative leader. There may be others. What would you add or change?

An Alternative for Identifying Classes of Service

appleorange-1

In most Kanban systems established, classes of service refer to an assessment of impact to the business.  While I personally like this approach, often this assessment technique doesn’t fit well for some teams or organizational issues.  It may also not be very informative for some work items being managed.  I have always believed in using Kanban, and particularly its associated metrics, for identifying areas to improve.  Sometimes we need abilities to slice by similar items as far as impact, but that may have other degrees in which they vary. So I’d like to present a few other styles for identifying these.  I’ll start at a team level and move upwards towards something more organizational wide.

Maintenance Activities

I often seem to find teams performing maintenance activities (upgrades, defect/bug fixes, small to large enhancements, etc.) struggling to find ways of understanding the metrics that will be useful to them.  While an Expedite class of service, with its own identifiable swimlane and corresponding WIP limit, is invaluable, a standard class of service is not when the timeframe or scope tends to skew the metrics results.  I want to be able to predict when an activity may be done with some confidence.  If I lump all of the activities into one standard class of service, the larger items will skew the average lead time to a higher number than my smaller activities and my variability will be very high.

A concrete example is an ERP upgrade versus an important (but perhaps not critical enough to go into the Expedite column) bug fix.  The ERP upgrade may fix numerous (just as) important bugs as well.  Upgrades in ERPs often can’t be broken into apples to apples comparisons as the tasks are entirely different though the lifecycle that may be managed through the Kanban process may be identical.  Additionally, the items that must be completed for the definition of done (which become cumulative entry/exit criteria along my columns) may also be different.

BTW, these types of items may be tracked within a higher level Kanban and not necessarily a team based one…

Portfolio Items

Definitely moving a level or two upward, if I have portfolio items that need to follow an identical process, but may have varying entry/exit criteria or varying typical timelines may also be worth tracking as separate classes of service though each may be more or less equally important to the business (i.e. close to the same prioritization in the backlog).  Here’s some examples: reogranizing a particular function, redesigning a business process, implementing a new application (at the highest level).  Each may follow a similar process of: Backlog -> Analyze -> Implement -> Measure Performance -> Done.  The definition of done and timelines may be quite different on each of these items.  Wouldn’t it be nice the next reorganization being proposed I understood how long my last set took in terms of average lead time and its variability so I can predictably give an answer to the board?  I don’t want to skew my data with that for my last network upgrade.

One could argue that we could (or should) use separate Kanban boards for these, but I think this is less than useful. I can think of two reasons to have these on the same board.

  1. I want to understand how my organizational WIP of change affects cycle-time overall.  This would be very difficult to do if these were spread across multiple boards. (This is not to say that each effort may not have its own more detailed board.)
  2. Also if I want to also think through alternatives approaches and compare cycle-times as a magnitude of cost (since often time is money) and benefit (time to market), having these on the same board makes this much easier.  By tracking this information, I can use this information as input to my decision-making on which approach I may use.  For example, if I can use it as input to analyze whether I redesign my current business process or automate the existing process.  Knowing the cycle-time can become part of the analysis both in terms of cost and benefit

A Quick Analysis View

So how do we determine these different classes of service? Well I have already hinted at the dimensions that we will use.  We’re going to basically categorize the work item types by time it takes to get them done (just a gut feel of time) and differences in the scope of definition of done, looking for vastly large differences.  You can place these on a grid such as the one below.

Classes of Service Matrix

So even items with a similar definition of done may have vastly different timelines, knowing this keeps us from skewing the data when we want like items.  Additionally, not lumping things that have vastly different definitions of done (column(s) exit criteria) yet follow an identical process at the level we are looking at it can also be very helpful.  The bottlenecks that may occur can be different; this also makes a useful distinction.  Lastly, I can now view all of these dissimilar items on the same board and yet have a means of distinguishing them and their corresponding metrics.

When one is stuck on identifying classes of service, or the classes of service between the items appears meaningless, give this a shot and see if it helps.  I’d be interested in other viewpoints.

Everyone Can Be Facilitative Leaders

tree_of_diversity

One may wonder why in my Leadership Quadrant post I mentioned that there is more room for people to be leaders when based on facilitative leadership thinking.  This is explained by the two dimensions…

When leadership is based on power, this promotes hierarchical formal power relationships; only so many can report to a leader under this arrangement.  An organization may choose a flatter structure, but ultimately decision-making authority rests in appointed or elected people at the top of a pyramid structure.  Only people in these positions get to wield authority.

When directing is the preferred mode of operating, there is a limit to how many directors one can have.  So even though a Utopian Benevolent Dictatorial Leader wants to help others, there is very little room for others to lead in their viewpoint. They have a sincere belief they know what is best.

In “Becoming a Technical Leader: An Organic Problem-Solving Approach” by Gerald Weinberg, he talks about how anyone can become a leader through helping others. This is at the core of Servant Leadership and when this is done in a participative manner, it becomes facilitative in nature. Leadership derived in this manner happens irrespective of what formal structures are in place.  Everyone has expertise and can lend assistance in some area and thus at any time one can be a leader; authority is derived from people’s sustained willingness to follow.

Leaders that then get appointed or elected to some formal authority role (supervisor, manager, etc.) that were already using a facilitative leadership approach gain much more capacity to get things done; people were already willingly giving them authority, the new position just confirms that belief.  As long as the individual doesn’t switch too far to other extremes in the dimensions, they should be able to sustain this willingly given authority.

Facilitative Leadership Overview

IMG_1414

In my last post I brought up the concept of a facilitative leader; so what do facilitative leaders do and how do the effectively lead?

What facilitative leaders do

I won’t go into exhaustive details here as this itself could be several posts, however it is important to have some idea what makes a facilitative leader distinct and that is the behaviors they exhibit. We’ll discuss this as if the behaviors are in the upper right of the Leadership Quadrant.

So in this space, a facilitative leader exhibits a desire to serve others, much like a servant leader as described by Robert Greenleaf. They also are participatory in nature, thus rather than say define a plan for a group to do work towards a goal, she or he will help the people create the plan so that is theirs. Thus a facilitative leader is one who helps the group collectively solicit and select creative ideas for the work and committing to complete it.

They also help individuals cope with their ever-changing roles and responsibilities as the team organizes and executes the work. They act as outside observers and offer improvements to the group and overall organization at large. They help the group gain clarity in the goal. They lead through influence.

How facilitative leaders effectively lead

As we explored in the last post, in order to be an effective leader, particularly when using influence as your primary mechanism, one must maintain good will with those you are leading.

Will_Equation

When your actions are opposite of what you say you will do, they work against each other and your will approaches zero. Since influence is based on will, this reduces your leadership effectiveness.

Here’s a few examples, I say I have an open door policy and will listen and attend to people’s needs. If people bring these to me and I never listen, perhaps always finding ways to dismiss their needs, or I never take action when I say I will, I am undermining my will and thus my ability to influence behaviors, my primary mechanism to lead.

If on the other hand, I state I will observe where people appear to have roadblocks and help them through them, followed by attending stand-ups hearing of impediments outside a team’s control and visibly taking action on them, I gain will to get things done.

Side note: for most of this article, I called people a group, that was to emphasize two aspects – 1) this can be done in a non-team environment, particularly if you are a leader that has authority. And 2) you actually don’t need to have authority to influence folks through will; this generally not true where you are directive in nature, there you needed to have been granted authority in some manner.

Leadership Quadrants & the Facilitative Leader

Helping_Someone_ClimbIts been awhile since I posted…

I’ve been noodling on a many dozen things, but one that is resonating currently with me is leadership styles.  there are dozens of books on this topic and so I have decided to ignore them momentarily to give you a simple framework based on two dimensions: participation directing and focus on power others.

To help us visualize this, here is the two dimensions shown on a graph:

Leadership_Quadrants

Each dimension is a spectrum; these aren’t discrete spaces and people may move on these dimensions based on comfort level, experiences, and a whole host of other factors.  If I considered only the X-axis, the right side would those that want to be servant-leaders and the left side would be controlling leaders.  These have behaviors; the Y-axis adds in other behaviors.  For clarity, let me repeat something that Robert Greenleaf said in his book “The Servant as Leader”;

The servant-leader is servant first… It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature.

With this is mind, and adding in the degree of participation to directing, which are another form of style, we can see that a mix of behaviors begin appearing in how I execute being a leader. Greenleaf’s book focuses on motives IMHO, but the manifestation/execution also matters a lot.  While a Utopian Benevolent Dictatorial Leader wants to help people, how they do it is entirely different.  They are going to direct what they think is best and not seek input from others. This may reduce their effectiveness overtime as people gain more awareness in the fact they don’t have say; this is regardless of the leader’s intentions.

I want to emphasize that a Facilitative Leader is one that has the Facilitation Kernel at their core – they are not only serving others, but doing so entirely on behalf of the group with their participation.  They treat those they lead as peers.  Facilitative leaders lead through sheer will and thus are clear in ensuring their actions and statements match.  When they don’t, then most likely they lose power as it is all based on influence.

Will_Equation

What’s nice is there exists more room for Facilitative Leaders within an organization than there can be for the other three styles.

I have some more thoughts on what Facilitative Leaders do, but I’ll save that for another post.

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…

Organizer’s Take Note: a Plea for Improving Unconferences

This is a follow-up post from my previous post “What is the Matter with Unconferences“; if you haven’t read it, please drop by and do so – we’ll wait…

…dum-de-do-barumpadum…

Back? great!

As one other clarification, here is a Wikipedia extract that outlines what a BarCamp is, which is what most of these I have been to is based on…

They [BarCamps] are open, participatory workshop-events, the content of which is provided by participants.

After seeing issues at both UXCamp and ProductCamp, I’d like to offer some suggestions.  What saddens me in particular is that so many sessions at this past ProductCamp were presentations.  While I like that at least the type was known to me beforehand, even some pitched as workshops weren’t hands-on.  And the presentation ones seem to leave little time for true discussion.

To provide some details on the disturbing trends and to offer some unsolicitied advice on changes to make:

  • People getting scheduled before the conference. I think it is OK to find out people’s passion beforehand, but let’s not schedule sessions before the unconference; unconferences are more than just crowd-sourcing topics
  • Using voting as a method for choosing what topics are in or out. People will follow their passions; I’ve been at sessions where I was the ONLY one that showed up as the convener; that’s OK.  I either went to another session or captured my thoughts quietly; I’ve also had others come join me after about 10 minutes from the start as they tasted a few competing interests and found the conversation we created more interesting.
  • Don’t provide A/V equipment for sessions. No mikes, no video. To have participatory sessions, the sessions should self-constrain themselves to being small where microphones are unnecessary. Unlike big formal conferences, we’re not interested in trying to determine speaker or topic popularity, people self-determine that… Several workshop sessions at ProductCamp were set-up auditorium style and the participation was limited to getting small amounts of input from the audience. The default format should be open discussion; workshops should be essentially the second option.
  • Don’t have any session format connote different levels of expertise; no panels of experts or ask the expert. Unconferences are awesome because they promote peer-based discussions. That young guy out of college may have more innovation in them than the greybeard of 30 years in the industry. You are not going to unlock that by placing one over another via a self-proclaimed or given title. Let that expertise emerge from the group and people will learn what they want to use or not. If a panel of people want to convene one, that’s fine, but don’t let people call themselves experts; it’s still a conversation.
  • Consider what a Keynote does; it constrains thinking and lowers energy. If you are going to have a ‘keynote’, consider building the schedule (in Open Space, we would call it a marketplace) before the keynote.  This then captures the tone of attendees without influence.  If it isn’t aligned with the keynote, so be it; now you know what is on people’s minds.  As soon as the keynote happens, people begin constraining what must be important is centered around it AND having someone talk at me for 45 minutes to an hour lowers energy levels for proposing sessions. Also, let everyone have a chance to propose a topic before letting others offer a second one.

Select a style and focus on it beforehand: Camps tend to be more hands-on workshops.  Open Space and World Cafe formats more discussion-oriented.  Also, can I ask that space be considered a bit better?  While I thought the digs at both the Goethe Institute (UXCamp) and LivingSocial (last ProductCamp) were cool spaces, they were not conducive to moving around or running an effective unconference given the number of people; perhaps decrease the number of attendees.

I’m going to be watching what these two camps in particular do next year; I may set-up a competing model that truly emphasizes peer conversations if this is the trend for these two.

PS – This is NOT considered a knock on the organizers – who did a wonderful job at the format that they decided to do, but either they do not fully understand (or want to execute on) what an unconference (Camp) is, OR they are being seduced by ever greater number of attendees/sponsors they can get in exchange for sacrifices on the format.  I’d invite them to consider their own personal motivations and perhaps incorporate them explicitly into their message.