Planning Events with Covid-19

I’m going to go a bit ‘off-topic’ from my typical Agile, Leadership, Lean, Software, etc. topics and try and provide some information that may help people in these communities. With so many states starting to open up businesses and such, you may be wondering how you can decide when you can plan your conference or meet-up to start meeting in-person again.

So we’re going to focus on a formula that George Mason economics professor Alex Tabarrok wrote. You can find the details behind this at his post COVID-19 Event Risk Assessment Planner. This assessment planner focuses on the US population in its risk assessment. One of my primary concerns is to help people that plan regional events and meet-ups.

Stand by, we’re going to be doing some math….

In that article, there is a formula:

1-1(1 – c/p)^g
from COVID-19 Event Risk Planner by Professor Alex Tabarrok

Where c = the number of people carrying the disease, p = the population, and g = the group size planned for the event.

He has a nifty graph also that shows this for the US. (Though we now have gone off the scale on the left hand side, so it would be worth extending it.) Note that this is a logarithmic graph, so I’d recommend recreating it on logarithmic graph paper.

When planning a regional event like a meet-up though a calculation at the US level (or any other country) is probably inappropriate. Here is how you can extend that to a regional view…

I am going to do some calculations based on two meet-up groups here in Virginia as a start. First is the Games for Agility, Learning, and Engagement (GALE) meet-up we hold at Excella. It is based in Arlington, VA and draws people from a few surrounding counties and cities (DC, Alexandria, and Fairfax County mostly). [Note: I’ll show what happens if I add in Montgomery County in a moment.]

So first I need to know the populations. Some googling gives me the following:

City or County	Population
Arlington	237,000
Alexandria	144,000
DC	702,000
Fairfax	1,010,000

These numbers were from 2019 projections taken through google search results and rounded up to the nearest 1000. These should be good enough… So the total population about is 2.093 million. We’ll set that aside for now…

Next we need to figure out the number of carriers. For this I am going to turn to the wonderful graphics from the Data Wrapper page on 17 (or so) responsible live visualizations about the coronavirus, for you to use and in particular the map portrayal titled: Number of confirmed COVID–19 cases in US counties. (You will need to scroll down about 2/3 the page – the page has lots of graphics on it, so expect it to load a little slow.) I’ll zoom in a bit and scroll over to Virginia.) This data gets pulled daily from a set of data at Johns Hopkins University.

We’ll pull the ratio that reflects the ratio of the population that is infected. I could pull just the number known I suppose, but it states that number has or had, which means it includes deaths (people no longer around) and recovered (people who no longer have the disease). I get this by hovering over the appropriate dot. So here is an example:

Let’s add this information to our table:

County	Population	Ratio	Calculated Carriers
Arlington	237,000	1:180	1317
Alexandria	144,000	1:150	960
DC	702,000	1:120	5850
Fairfax	1,010,000	1:220	4591

This makes the total number of carriers we’ll use as 12,718.

We need one more number before we can run the numbers through the formula. The size of the group. So using GALE first as our example. Our largest in-person meet-up size was 16 (we’re a small niche interest….). This goes in for the g in the formula, which you will observe is a factorial. As Alex writes in his Risk Assessment Planning post, this is the biggest factor in determining risk as it is bringing people from the population that has been exposed together.

Running the numbers…

1-1(1-12718/2093000)^16=.092… or about 9%

So if I ran GALE today, there is an almost 1 in 10 chance someone in the crowd would be bringing the disease (unknowingly) into the meet-up group. Personally, I’d want this to be below 1 in 500 (0.2%) before I’d feel comfortable (that’s a meet-up group of 3 in case you are wondering).

Let’s now look at how the DC-Scrum User’s Group would look. They regularly have 50 people showing…

1-1(1-12718/2093000)^50=.262… or about 26%

This means they have better than a 1 in 4 chance. Yikes! But wait, they regularly pull people in from Montgomery county, MD also. Mongomery county’s population is 1,051,000 with an infection rate currently of 1:170. This yields an additional 6182 carriers. So for the same size group the formula looks like…

1-1(1-18900/3144000)^50=.260… or still about 26%

Not much change. But if 60 people decided to come I’m now at about 30% chance of someone being a carrier.

If you are deciding to restart your in-person meet-up, the guidance I would advise on this is to cap the maximum number of attendees AND be transparent on the percent chance someone would be a carrier. (If you could set-up the meet-up such that it had social distance as a part of it and perhaps specified masks you might be able to allow a slightly higher risk than what the numbers may indicate as the formula isn’t factoring those things in.

If I were planning a multi-state regional event, I would use the population and ratios of the states attendees would be coming from… plus the ratios of the counties or cities of where speakers were coming from… if different from the attendees. So for example, Agile & Beyond frequently gets attendees from not only Michigan, but also Ohio, Pennsylvania, Ontario, Indiana, and Illinois. I’ve spoken at Agile & Beyond (so factor in Fairfax County, VA if I am selected); so has George Dinwiddie, so factor in his county as well.

I’d consider at this point calculating a straight average of the infection ratio and throw out any that were outside a significant factor different. Example, all my ratios are between 1/120 and 1/330, but two speakers come from places where ratios are 1/2730 and 1/1850; I would throw these low ratios out. I would not throw out an outlier at a higher ratio. This averaging with throwing these out would actually bias it to be conservative and thus safer for everyone.

For international events, you can use the countries from where people are attending.

How can we project when we can return to in-person events? The COVID-19 tracker at Virginia Department of Health provides a hint. If you look at the Number of cases by event date graph it is showing a downward trend, but we need this graph with the total number of infections in the population, not by event (which is a daily number). Then one can use the rolling average on the rate of change over say 3-7 days to project how the # of carriers will change. Perhaps you could do this with the number of daily events; I just don’t feel comfortable with that projection as the disease persists and daily events are more sensitive to social distancing, business closures, and other lockdown policies.

Another place to keep your eyes on is the Institute for Health Metrics and Evaluation (IHME.org), they are the organization producing the models that forecast deaths, hospital usage, etc. and these take into account changes in patterns of mobility and social distancing. Hopefully we’ll start seeing some additional projections of rates of changes in infection rates actually being produced.

I hope this is helpful for people that are trying to figure out when and how to plan in-person events again.

Retrospective Storytelling, a #RFG19 Session

It’s been a long while since I wrote… Well that is not entirely true; I’ve been writing a considerable amount on Excella’s Insights. It’s about time I returned to a post on my own blog.

I had the honor of attending the Retrospective Facilitator’s Gathering this past week with 19 others. I was invited by my friend George Dinwiddie. He invited me several years ago and checked in most years, but it just never worked out until this year. This is a week long Open Space event that began under Norm Kerth. It’s a wonderful community.

I held a session on Storytelling in Retrospectives. I wasn’t very good at keeping notes as the stories were too good 😉 This is my attempt to capture my memories of the session in the hopes it may help others.

I kicked off the session by establish the purpose of understanding techniques and their uses of storytelling in Retrospectives. I started with sharing how I use Dixit cards. I utilize these beautiful cards in two ways. The first is for check-ins and similarly for quick end-of class/workshop/conferences (that I run) retros where people select a card, share the card they selected and explain why they selected. It gives them a complex metaphor to explain. The longer retros I have run anchor this same selection, explain why, but ask people to go into the details of the card and how they represent what they have encountered over the period of time the retro is covering. I ask the others to listen to this story and capture the pertinent items (positive or negative events/issues) from the storyteller. This has the effect of getting people to truly focus and be present. The storyteller isn’t busy trying to do this capture and there is an interesting side effect; because people have their own points of view, these get captured into their notes. The cards are beautiful and most can be interpreted in both positive and negative ways.

Aino told us how she has used Rory’s Story Cubes to invite people to tell stories in a similar fashion. Kim mentioned that she has also done that and also how she has had people silently draw a story together, this digressed in a bit of how improv can be used to tell a story of a particular event and outcome with half the people being the audience and the other half being participants. For a little humor, while still keeping a storyline, this can be a silent improve. This does indeed lighten things up.

The drawing together reminds me an Art Gallery retro where different people that work together draw/diagram how they see the work processes from their point of view. This was a cool technique I learned at Problem Solving Leadership. You end up effectively telling stories as well.

Ainsley mentioned that storytelling has been a consistent topic that appeared at RFG since the early ones.

Somewhere along the line, I mentioned I like to close retros on occasion with the Hero’s Journey; “Once upon a time…”, “Until…”, “Then…”, “Happily ever after…”. The Until is/are the root-causes that created problems for the team, where the Then is the retrospective’s actions. Only if they put these actions into play can someone see the Happily Ever After part.

As Diana and George arrived in our session they reminded that in many ways, any activity we do is a story being told. Sometimes with data, sometimes by people… And even the arc of the Retrospective creates a story.

Towards the end, I wanted to run an idea I had thought of for a Retrospective. I call this the Newspaper Retro. Newspaper articles tell stories based on facts. So my thoughts were to let people in a retro individually brainstorm onto (probably larger) sticky notes news articles of 1-5 sentences about various aspects of what went well or didn’t go well. Everything should be based on fact. These get categorized the following news sections:

Politics are all articles about team collaboration
Technology is all about tool usage
Business is all about the process
Science is about new discoveries or learning the team has made
Foreign Affairs is all about things external to the team
The Nation is the section devoted to things about management

After the initial creation of stories, the team would come together and combine like stories. This is where multiple perspectives now are coming together. The team would take these similar stories and provide analysis on these stories, collectively writing what they think is happening. Finally, they prioritize the 1-3 that will appear to be on the front page, analyze those as well (if not analyzed because of similarity) and then create the planned elements or experiments that will be done to correct these (or amplify them if they are positive), adding these onto the story.

Final front page stories then wind-up being 1-3 factual statements of the problem, 1-3 sentences of analysis, and 1-3 actions that can be taken. A few other stories later in the newspaper wind up being factual statements and analysis, and most are just factual statements. These would be categorized into the appropriate sections and later retros could review the newspaper in future retros.

The group seemed to like this idea for a retro; just realize it is untested at the point of this writing. If you decide to try this, I’d LOVE to hear how it went! I will be looking for a time to use this, but as we know context is important, so I don’t want to use it with a team where it wouldn’t fit.

Shortly after this, we closed… I am certain I forgot some stuff, so I hope attendees will chime in and remind me of what was forgotten.

How do you measure sustainable pace?

This was a question posed by my esteemed colleague Bernd Schiffer (@berndschiffer) on Twitter. This is a complicated thing to measure. We all know what effects unsustainable pace has, AND often when they show up, it’s too late. I’m going to divide this post into two segments; first will be early warning signs that a pace may be becoming unsustainable, so you can try and nip it in the bud early. Second will be how to determine that your pace is likely sustainable. (I say likely as it’s always possible these possible metrics may not catch everything.)

Early Warning Signs

So let’s start with signs that one (most likely a coach or Scrum Master or other suitable servant leader/team facilitator) may use to find out if a team may start to hit an unsustainable pace. None of these on their own may be enough to indicate encroachment of an unsustainable pace, so ensure you get a balanced view.

If you have access to time card data, and if people are honestly reporting their hours, you can look at how the hours they record are trending. This can help you spot both individuals that are undertaking an unsustainable pace as well as the team. This really needs to be complemented with a gemba walk so you know what are normal hours for people and when people may be burning the midnight oil. The occasional late night may be ok; perhaps the individual or team has an interesting problem they want to solve before going home. If this is a regular occurrence, then you most likely have an indicator that an unsustainable pace is starting to happen.

Look at check-in trends. Do they become more rapid in pace at the end of an iteration or before some significant milestone? Do these correlate to an increase in broken builds or failed tests? Does test coverage slip around these? These may be indicators that people are getting rushed in their work. Along with these, trends in escaped defects may also indicate whether a team is receiving pressure to deliver.

If you are running a Niko-Niko or otherwise taking a pulse of the team, then downward dips or loss of stability in happiness may likewise be an indicator that the pace may be becoming unsustainable.

Lastly, consistent carry over of uncompleted work between iterations, measured in story points if you are using them or just in the number of stories, tasks, et cetera, can be an indicator of possibly approaching an unsustainable pace.

None of these on their own though make for a good set of measures, only by cross-correlating them can you possible get a sense of a team’s pace getting to where it may begin to collapse under pressure.

So what should you do? Well if you are seeing these metrics, you will need to 1) confirm that the pace is truly becoming unsustainable and 2) remove the pressure in a manner suitable to getting the desired results. For both of these, sitting down one-on-one and having some conversations as well as conducting some retrospection as a team on what is happening may give more insight than any metrics could. This will also uncover the pressure that is causing it in the first place. The pressure may be appropriate; what may not be appropriate is the reaction. For example, suppose the product owner is not accepting many stories because of a team not meeting all their acceptance criteria. The team decides to begin working late rather than reduce the number of stories they take in as a means for ensuring they get all the acceptance criteria completed. The response is the issue, not the pressure.

Measuring Sustainable Pace

With the above, you’d think it perhaps good enough to just look for the absence of those negative signs. Presuming people are truly being open and honest AND also aware of the pace becoming unsustainable then yes, the absence may work. But what if workdays have been regular, but then every so often a few extra hours go in, then suddenly there is a sharp uptick in the number of hours? That may take what was tolerable to intolerable, particularly if it causes stresses between workers where some have family commitments and others don’t and thus get ‘stuck’.

A better measure for maintaining sustainability on a team may be noting how often the team can push back on requests that regularly cause these extra hours. This means the team can choose when they want to do them or not. This is more of an observation. Combined with the Niko-Niko and absence of some of the metrics above, now we may be getting an additional dimension that says the team is working sustainably.

Another dimension can be how well the team honors the Retrospective Prime Directive, not only in retrospectives, but also during standard work. If they aren’t casting work in us vs them or treating other external stakeholders with contempt then the team is probably working sustainably.

And lastly, how often does the team celebrate? Do they take time to appreciate each other? These all are indicators of sustainable pace as well.

As you can tell, it’s probably difficult without an excellent Scrum Master/team facilitator, manager, or Coach paying attention to this.

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_team I’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.

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.
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.
Feedback and working communications are at least partly being removed from the group that needs them directly.
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.
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

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):

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:

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

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.

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.

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?

Paul Boos' Nimblicious – Making Agility Tasty

My thoughts on Product and portfolio management, Agile and lean approaches, User experience, and Leadership

Category Archives: Culture