Team Launch Misfires…

I’ve been conducting Team Launch workshops for awhile now; some for teams doing software development work and some for other types of supporting products.

I_love_my_awesome_teamI’ve noticed teams that go through a significant amount of effort on these types of chartering exercises seem to always be “awesome” compared to most of their peer teams. They get more done; what they get done is more on target with what the end user needs; and they have less post-deployment problems. I really don’t think this correlation is a coincidence.

My views on launching teams are 99% +/- 2% congruent* with Ainsley Nies’ and Diana Larsen’s views as expressed in their book Lift-off. (If you don’t have this book, go get it!) I had about 5 categories of agreement I used, but they easily collapsed into the 3 from the book: Purpose, Alignment, and Context. Now I use those.

Out of these I view Alignment as the most important one. If I can get to a team that is aligned in HOW they will work together, they can overcome the shortcoming in understanding of the purpose (or on a project where the purpose is emergent) and certainly they can handle an evolving context as they probably thought about those ever shifting sands.

The teams I see that are challenged almost always short change this area as it feels soft and squishy. Why should I understand what my co-workers value? Who cares how decisions are made – let the boss do it as he always has… Why do we need to think about what and how we celebrate things? Ignoring this ignores the first Agile Value: Individuals & Interactions over processes and tools. Launching teams correctly celebrates the former and ensures the latter is subservient to it. Every team I see struggling as of late has short-changed this Team Chartering, particularly around Alignment. A guarantee the missile will miss the mark.

Want more info on how to be successful? See my post on Excella’s blog. And/or get the Lift-Off book and think about what Purpose, Alignment, and Context mean in your environment.

 

*You’ll notice that the upper end of this is 101% which is where I think my congruent thoughts are most of the time…

Symptom of Anti-Agility: CRM Groups

Collapsed_Bridge_Narrower

I haven’t written in a bit (well I have actually, but on Excella’s Insight blog), but I wanted to write about an anti-pattern I am seeing in one of our clients. Many have written that management seems to think of “Agile” as only within development teams, and forget that this Lean and Agile thinking needs to permeate everywhere.  It’s a dysfunction to continue working on…

So let me give you the example I am seeing so we can talk in more concrete terms.

The organization has had a rocky past between central IT and the business. Software development is distributed in various business units as well as a central IT shop (I’m staying away from actual terms the customer uses BTW). Central IT also does considerably more though, such as manage the network, run a server farm or three, manage cloud providers, email and content management services, etc.

The complaints from the business have been articulated as (in no particular order):

  • I have to know who to call in order to get good service; any official channel for requests is difficult to know.
  • Service is often slow and paper/form intensive.
  • When I use any official channel, it doesn’t necessarily get routed to the right location.
  • I’m not told everything I need to do to get my request fulfilled, resulting in delays.
  • I don’t know the status on requests that have a longer time to fulfill, nor have I been told or know where to go to find out my status.
  • I’m uncertain if any feedback I provide is acted upon.

I’m certain everyone has seen these before in some mix.  IT also has a set of complaints:

  • People go to whoever they happen to know that is related to the request they want to make to get service. This eats into people’s time without management having much knowledge of it (perhaps the immediate supervisor knows, but no one else).
  • IT needs to begin a charge-back model due to budget restructuring that is removing a great deal of central ITs funding, thus more knowledge of requests and services is needed to be known. The manner in which requests are coming does not provide a means to track it.
  • The business sides doesn’t see the great work we are doing.
  • The right people in IT don’t receive the needed feedback.
  • IT has a blemished image/brand and are thus not viewed as a valuable partner.
  • The CIO can’t keep up with the requests given to him by his peers; too many are bubbling up and being made directly to him.

If you work in an IT organization, particularly as a senior manager type, how many of these have you seen? Before I go into how to handle these with some Agility, let’s look at what this organization is doing that I consider an anti-pattern; literally anti-Agility thinking.

The senior manager tasked with solving this sees this primarily as a communications problem in 3 areas:

  • Routing to the right people to do the work
  • Taking in feedback on ITs performance
  • Improving the communications on good performance (improving the “brand”)

To solve this, they are standing up a Customer Relations Group that will take in initial requests/requirements, receive feedback about performance during and at the end of the work and provide it to the group(s) that performed it, and get the word out on the good stuff IT does.

They are starting by creating a master catalog of services IT provides (which on the back-end will have costs associated with them). It’s unclear whether these costs and/or the parts of the IT organization that will perform them will be a part of this catalog.  So far not bad… They also will stand up a single intake service (along with an online form) to process these needs, then ‘interview’ the customer to get any additional information, and route this request to the proper parts of IT.  It seems at this point there will be a hand-off; what is unclear is how this hand-off will work if multiple parts of the organization are involved simultaneously. If software development is the primary concern, it will be handed off to a development team (or a new team will be stood up).

This new Customer Relations Group will also query the customers periodically to find out how well the various parts are doing and give this to the right part of the organization. It will also give any responses back to the customer. And finally it will create some marketing material and positive ‘press’ to help sell IT services.

To keep this from being a burden on the current IT organization, the bulk of this work will be contracted out to a big name firm that everyone respects. Sounds great doesn’t it!? Every organization needs this, right?

As well as intentioned at this group (and its contractors) may be, this creates several dysfunctions.

  1. This is actually adding an additional step that will actually slow requests getting to the right people. This will increase the time to service, probably decreasing happiness, perhaps not initially, but certainly in the long run.
  2. It adds a hand-off of information so that the people needing it are getting it second-hand. This will lead to greater misunderstandings between the groups that need to work together.
  3. Feedback and working communications are at least partly being removed from the group that needs them directly.
  4. There is an assumption that a one-size-fits-all intake process can accommodate getting all of the unique needs a customer needs to portray to a unique supplier. Requests for an email distribution list would be vastly different than one for a software development project, or just even business analysis services for a development project.
  5. Messaging (branding) will be coming from a third party not responsible for any of the results.

Even worse though, there are fundamental root-cause problems being masked over.  For example, why does the business feel feedback they give is not listened to and acted upon? This solution isn’t going to address this root-cause concern. What is causing the long lead-time for IT to respond to business needs? Why are we trying to create a standard process for intake and routing as opposed to simply better connecting people to those that would supply the services and give proper visibility into the incoming work, but allow a self-routing approach? Why do we need to do a charge-back for the services internally as opposed to getting the budget reallocated properly to pay for them?

So how would I approach these items? I’d start with challenging the fundamental way things are done. I would learn where are the bottlenecks causing the unacceptable lead-time. I’d investigate the root-causes to the image/branding and see how to solve those. I’d see how I could make a catalog of services attached to the people that provide the services and work them to create mechanisms that give me an understanding of the allocation of requests. And I would at least talk with the budget personnel to find out how I could simply get the budget allocated properly; if that couldn’t be done, I’d make my service costs transparent to those when they look up my services. If I wanted something Customer Relationship-like, I’d perhaps think about deploying customer relationship software to all the groups directly, if evidence showed it would help.

Bottomline: I’d reduce hand-offs and keep with the spirit of individuals and interactions over processes and tools. I’d do the simplest thing I think is in the right direction and then retrospect on how that is working for me.

 

TWEET Your Feedback

pixar-birds-wallpapers-movies-widescreen-images-157470

This post was prompted by Jurgen Appelo’s excellent post on giving a Feedback Wrap on Forbes.

I really like this post as it gives you an extremely useful way to express feedback in a manner that will help the receiver actually take action.  It also helps them become aware of future behaviors they may need to change.

Giving good feedback is important, whether it is to superiors, subordinates, or peers. Like Jurgen, I won’t claim to be perfect at doing this and more than once, I know I have provided useless and sometimes hurtful feedback. So to provide a bit of additonal advice as a wrapper around what Jurgen is recommending, I wanted to share an acronym I learned at Culture Camp DC 2012 from Chad Wolfsheimer of the Motley Fool.  The acronym is TWEET; here’s how it breaks down:

Take note of impact

This part is recognizing a meaning to the behavior you want to give feedback on; what is this behavior doing to you, others, a team, and/or the organization. If there isn’t any impact (or perhaps if it truly is trivial), then ask yourself is this feedback going to be useful?

Write down (organize thoughts)

Chad recommends writing down your thoughts, but he did offer up that due to the necessary timing you may not have this opportunity. None-the-less, take a mental step back and organize how you plan to present it; non-organized feedback will come across as a rambling complaint and not achieve what you want.  Using Jurgen’s Feedback Wrap technique is an excellent way to do this.

Empathize

Before jumping and giving feedback, try to understand the context the other person may have. Empathy in this case is not only what they may be feeling emotionally, but also what their mental model may be on why they are exhibiting the behaviors they are. Trying to understand this may help give you insight into how to deliver it so that it is received well.

design it be Effective

Using the Feedback wrap as guidance to organizing it and any insights you may have gained through empathizing, think through how the delivery can be made effective.  After all, if the feedback is ignored or it spawns a defensive mechanism, it probably won’t likely alter the behavior you want changed.

Time it appropriately

We’ve heard how feedback should be timely; Chad recommends and I agree to think about timing. Often just after the behavior is exhibited is the right time, but at other times it may be worth making a determination as to the most appropriate time to deliver the feedback to maximize its reception.

On top of the two great ways to look at feedback that Jurgen and Chad have presented, I also recommend including inquiry.  Asking a few key questions can help you both empathize AND open up the recipient’s mind about the behavior you want to change. Be careful what questions you ask though; for example ‘Why’ questions may put the recipient on the defensive. Try and use open-ended questions as well as this prompts some thinking.  Here’s an example of a question that may work –

After you presented your critique of John’s database design, what did you notice about people’s reactions, and in particular John’s, to your statements?

If the person you are providing feedback hadn’t noticed anything, this question may prompt them to think through what may have been happening and help the recipient self-realize the impact. This makes your job much easier.

I’d avoid the following –

Did you notice how people felt dejected, and in particular John, after you critiqued his database design?

While that may be indeed what you noticed, it is your own mental model that produced that. Even if your recipient might come to the same conclusion, this closed question places her or him on the defensive and not in a place for self-reflection of their behaviors.

I hope you found this post useful, if you have any tips or tricks you use in giving feedback, feel free to leave a comment or tweet at me!

 

A Short Essay on Using Models – Why Should You Use Them & Why You Should Create Some

EA-7L_Corsair_Line_Drawing I use many models in my thinking, whether they are mine or someone else’s, yet I don’t think of myself as a theorist. I thought it may be helpful to some on why models are so valuable to a pragmatist. Another word for model is framework…

“essentially, all models are wrong, but some are useful”

George E.P. Box

This quote is the first thing to remember when you begin using any model; you need to remember that at some point a model will break down and no longer support what you were using it for…  Like a lean start-up idea, create and use models passionately, but stop using them the moment evidence points that they are no longer helpful.  (he nice thing about a model though is that generally this means you have crossed an edge-case where the model doesn’t work any longer, but may still be useful in the long run.  If the model consistently doesn’t work, then perhaps the model has some invalid assumptions.  Exploring these assumptions then may help you refine the model into something that once again works or to find or develop a model that does work under the broader circumstances.

This brings me to the next point – ALWAYS realize models have a set of assumptions.  Explore how the model works under these assumptions.  This helps you understand when the model may be useful and when it may not. With that, why do you need them if you are simply someone (particularly a coach or manager) who needs to help people get things done?

Models help you understand systems; they may not provide a means to achieve an answer, but may simply may provide a means for organizing your thoughts.  The Cynefin model by David Snowden is one of these latter ones – it can help you understand the problem space you are exploring for decision-making. Finding models that can represent systems or at least significant and important portions of a system is mostly useful for helping you organize your thoughts.  The act of thinking through when and how these apply including valid and invalid assumptions about variables, algorithms, or organization (for more pictorial models) really helps you determine on which things to pay attention.  Even if you find the model doesn’t work, the amount of thinking you went through will serve you well.

And I invite you, particularly when you don’t find a model that seems to represent what you need, to try and think through creating one.  Don’t worry about it being perfect, you can always adapt the model after inspecting how it works.  Again, you are using this to organize your thoughts.  Creating a model could be as simple as combining models; Jurgen Appelo’s CHAMPFROGS model about motivation does this.  It appears Jurgen saw gaps, overlaps, and some inconsistencies in representation and blended a new model to make it more clear to him.

It’s also extremely useful to find where different models connect in explaining the same observations (data) differently.  This helps you understand where options may be found and where the thinking on these has many dimensions, which again exposes assumptions about the models.

Going back to the usefulness, one huge benefit for applying or creating a model is stepping back from tactical thinking to a more strategic layer.  This helps in prioritizing based on importance over simple urgency.

People serving as coaches and managers are there to help the people improve the system, you can do this best when you have your own thoughts organized. Models can be an essential tool in selecting and organizing the particular tools and techniques needed to apply.

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.

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.

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?