Changes and a Grand Experiment

After more than 20 years of blogging across four different domains, I’m changing platforms from self-hosting (WordPress, mostly) to Substack. I hope this pivot will simplify the technical side of my life and allow me to focus more on writing.

Please visit The Stoic Agilist on Substack and support my writing efforts by subscribing. You can also visit StoicAgilist.com (self-hosted on WordPress, of course) to view the same posts that appear on Substack except they will be published approximately four weeks later than they appear on Substack. Subscriber only content will only be available on Substack.

The posts that remain available on The Agile Fieldbook are a matter of record that I wish to remain public.

The Emotional Bumblebee

I finished Lisa Feldman Barrett’s book, “How Emotions Are Made: The Secret Life of the Brain,” this past week. It’s the latest exploration in my decades-long journey to better understand myself and others. There’s a lot in this book and it’s been a paradigm shift for me personally. I expect the effects from the insights gained from Dr. Barrett’s work in my professional life will be equally seismic.

As part of this exploration and effort to understand what Dr. Barrett and others are discovering, I’ve been experimenting with different ways to organize and assimilate information. For years I’ve used mind mapping and its served me well. I continue to use this approach almost daily. Ah, but the relentless advancement of technology has resulted in new tools. My current favorite (meaning the one that so far matches how my brain seems to work) is a tool called Obsidian. It’s new and is evolving quickly. I’ve been using Obsidian to organize and study cognitive biases in a way similar to Buster Benson’s work. This past weekend I began a similar process with emotions based on Dr. Barrett’s work.

It’s early but it has already yielded many important insights and benefits. I began by collecting as many words I could find (currently, 514) that are used to describe emotional states or patterns. I then entered them into Obsidian, each connected to a single node, “Words that express emotion.” Here’s a partial screen capture of the Obsidian graph:

The graph is too big to fit on a single screen and have the words show. And Obsidian does not yet have an export feature for graphs into a standard image file. So I’m limited by screen real estate. Where I take this next…I’m not sure, actually. Probably a cycle of refinement and deep dive into definitions and descriptions. I can foresee the creation of a real-time tool for assessing emotional states using a circumplex. Lots of experimentation ahead.

There is a dynamic quality to the graphs in Obsidian that is part of the fun and path-to-insights with the information. I’ve created a video to show the effect and set it to Nikolai Riminsky-Korsakov’s orchestral interlude “Flight of Bumblebee.” If/when you read Dr. Barrett’s book, you will understand why I selected the bee theme. It’s a virtual emotional bee hive inside our heads and bodies. Be sure to expand the video to full screen for maximum effect. Enjoy!

What to do while on “vacation” during a pandemic.

Build a Torii Gate, of course.

A vacation originally planed for this week in Utah was scrubbed. So a significant pivot was in order. Priorities, plans, and schedules shifted and forward motion was begun once again.

I wanted to build a Torii Gate on the East side of my property for several years. The gate and fence that was there worked well enough so it never made it very far up on the backlog. That changed last fall when the Chinook winds – which are frequent, sudden, and fierce in this part of the country – snapped  the two supporting gate posts. (The same storm also blew off the gate on the North side of the property, but that’s another project.) The gate and fence have been braced up by 2×4’s all winter. Not a good look.

Worked on the hashira (posts) over the winter. They needed to withstand the Chinooks. So, 6′ steel post – 3′ bolted within 3 2x6x10s and 3′ sunk into a concrete base – ought to hold for a while.

Time to begin the outside work.

First post had to be set perfectly. This is after it had set for a few days and most of the supports had been pulled away.

Next, the nuki (lower beam) and the shimagi and kasagi (two upper beams.)

Add a little extra flair trim to the kasagi, stain, and seal.

All that was need to complete the Torii gate part of the gate was the gakuzuka – a small brace in the center between the shimagi and kasagi – with an inscription. The weather intervened and brought us about 9″ of fresh snow.

Weather cleared, snow melted, still self-isolating – back to work to build and install the new swinging gate.

Next, dress up the top of the swinging gate with a pattern to match the fence on the north side of the property.

Finally, add the gakuzuka. The Japanese kanji on the way into the gate is “Love.” Find love here, all ye who enter.

The kanji on the way out through the gate is “Peace.” Take peace with you into the world.

Add an exterior handle crafted from ceder and the gate is done. The street view is quite nice, even before the summer vines and surrounding flowers wake up.

Time now to clean up the work site and do a little path repair.

Update – 2020.07.25

Just following a rain storm and the summer foliage starting to grow back.

Working with Distributed Teams

I’ve coached and served as scrum master for dozens of remote teams over the years. In light of current events, I’ve posted a collation of the notes I have for helping distributed teams working effectively.

The rule is, if one person on a team is participating from a remote location, the team is a distributed team. Making distinctions such as “distributed team” vs. “fully distributed team” when some or all members of the team are working from remote locations risks marginalizing team members who are working at locations away from the home or central office. 

To help ensure that the concept of “team” remains intact during distributed team conditions, this post is intended to serve as a guide for scrum masters for how best to facilitate and monitor team interactions and performance with distributed teams. 

Scrum masters have the added burden of developing the skills within their teams for effective distributed team collaboration and communication. Distributed teams can function better than collocated teams when the team’s skills for organization and communication have been improved by necessity such that they are better positioned to function effectively as a team. 

Etiquette 

 Even with ideal conditions (i.e. plenty of bandwidth for audio and video, intra-team familiarity, clear agenda, etc.) working with distributed teams will always have a degree of asynchronous communication. Fields of vision are limited to what’s in frame for the video camera, network latency issues, and a general lack of access to in-person non-verbal cues will cause people to speak over and interrupt each other and miss-read intent more than they would during in-person meetings. To mitigate these constraints, it is important to have a well understood and practiced set of etiquette rules for distributed team meetings. 

Pre-meeting Tasks 

  • The principle challenge is to keep everyone on the team focused. Shorter, more frequent meetings are better than long meetings that invite participants to “multi-task” out of boredom. Invite essential people to the meeting. Use of a responsibility assignment matrix is a very useful tool for determining who to invite. People associated with the consulted” or “informed” roles generally don’t need to be invited to formal Scrum meetings. 
  • Communicate an agenda – however sparse – prior to the meeting. Let the team know what the purpose and objectives of the meeting are so everyone knows when they are done. Agendas are scope management tools and help keep the meeting focused. Set the expectation the everyone on the team will be aware of the agenda prior to the start of the meeting. 
  • Ensure that all the necessary equipment is in working order and that all team members have verified connectivity. Test screen sharing capabilities and application accessibility prior to the meeting. 
  • It is preferred that the scrum master host the on-line meeting so that on the rare occasion they may need to take control of the meeting by muting or bumping someone from the meeting they may do so. 
  • Set the expectation that team members will participate from a location that is free from background noise and other distractions. Joining from coffee shops or while driving is to be discouraged as they end up being distractions for the entire team. 
  • Coach the team for how to take turns in a conversation. 
  • Coach the team on how to use any mute features. 
  • The rules of common courtesy apply to on-line meetings. If we wouldn’t accept a behavior in a face-to-face meeting, it shouldn’t be accepted in an on-line meeting either. 
  • Turn off notifications from applications such as email and instant messaging. 
  • Meeting participants need to be aware of what’s in the visual and auditory background and work to anticipate and mitigate potential interruptions.

In-Progress Meeting Activities 

  • Continue to stress that team members be on time for the meeting. Set the expectation that they will join on-line several minutes early to accommodate any last-minute technical issues. 
  • Meetings serve both a practical and social purpose for distributed teams. Allow time for casual conversation (and still expect everyone to be one time) as it is critical to building and maintaining rapport among distributed team members. Small talk, catching up, sharing interesting news bits, interesting (short) stories – any of these helps make the on-line meeting a more enjoyable experience and help set a positive tone for the duration. 
  • If a team member joins a meeting late, they should not announce to the team they have arrived. Doing will potentially disrupt a conversation already in progress.  
  • When a team member needs to contribute to a conversation while others are talking, the best approach is to state, “I have a comment.” or “I have a question.” and then pause. This serves as a signal to the team that you wish to speak. Either the conversation will naturally break, or the scrum master can listen for a break and offer the team member the opportunity to speak. The natural in-person behavior is to simply start talking. With distributed teams this frequently leads to several people talking at once and a degradation in communication.  
  • Ask for the opinion of someone on the team who has not yet participated in the meeting or has been silent for a period of time. This will help keep them focused on the meeting if they know they may be asked a question. 
  • Team members should leave a comment in the meeting chat window if they need to step away from the meeting for a short time or leave the meeting. Announcing such departures tend to be disruptive, but the team will likely need to know if any team members are not absent from the meeting.
  • Remain attentive to anyone who is dominating the conversation or otherwise preventing others from contributing. 
  • For stand-ups, call out the person who is going to start the conversation. Assign that person the task of choosing the next person to speak and so on until everyone has had their turn at contributing. This will help keep each team member’s attention as they will not sure when they will be called on. Similarly (but less desirable) randomly call on team members and vary the pattern day-to-day. 
  • When conducting a meeting where only one or two people are attending remotely, ensure that both the conference room and the remote individuals are using video. This will allow for additional non-verbal cues to be included in the communication and help keep the conference room aware that one or more of their team members is attending remotely. 
  • Leverage chat for one-off conversations or bringing non-priority items to the host’s attention 
  • If video is in use, be aware of the need for patience when waiting for network latency to catch up with any shared screens. 
  • Start the meeting with everyone on video. After a few minutes for casual conversation and catching up, allow team members to switch off video to reduce bandwidth issues. 

End-of-Meeting Activities 

  • Provide a recap of what was accomplished and identify any of the goal or agenda items were not addressed. 
  • State any next steps. 
  • State any action items and the names of people responsible for completing them. Action items without assigned names are in-action items. 

Troubleshooting 

  • If a member of the team has a pattern of responding to questions with some version of “I didn’t understand the question. Can you restate it?” or they have to be prompted with “Are you there?” due to a non-response, there is a likelihood that they are not focused on the meeting and busy with something else. If the pattern is persistent, the scrum master will need to discuss this with the team member off-line. 
  • Be attentive to the introverts on the team and work to have them contribute to each meeting. Ask them for their opinion or any open-ended question that has more than a yes-no answer. 
  • The metrics a scrum master may use to assess team participation and performance will need to be more robust than the usual data-based and subjective measures. Assessing morale or the presence of intra-team conflict may not be as apparent with distributed teams. Scrum masters may need to meet virtually one-to-one with each of the team members more frequently and asses any time management or morale issues.

References

Additional Articles

How to Collaborate Effectively If Your Team Is Remote by Erica Dhawan and Tomas Chamorro-Premuzic 

SwiftFest Boston ’19: Remote Connections: Fostering Relationships in Distributed Teams

Photo by Tanya Nevidoma on Unsplash (Edited)

Coder’s Lullaby

[Sung to the tune of Woody Guthrie‘s Hobo’s Lullaby.]

Go to sleep you weary coder.
Let the output scroll on by.
Hear the cooling fans a hummin’.
That’s the coder’s lullaby.

Do not think about the deadlines.
Let the deadlines come and go.
Tonight you’ve got a nice warm cubie.
Safe from all the deadline woe.

Go to sleep you weary coder.
Let the output scroll on by.
Hear the cooling fans a hummin’.
That’s the coder’s lullaby.

I know the bosses cause you trouble.
They cause trouble everywhere
When you die and go to heaven,
You’ll find there are no bosses there.

Go to sleep you weary coder.
Let the output scroll on by.
Hear the cooling fans a hummin’.
That’s the coder’s lullaby.

Responsibility and Improvement

Feral chickens on the Hawaiian Island of Kaua’i are ubiquitous. And they can be aggressive, particularly when they are roaming around common outdoor eating areas.

While the vast majority of visitors to the island honor the signs that say “Don’t Feed the Chickens,” all it takes is a couple of noob’s to put the operant conditioning in motion and keep it going with each new planeload of first-time and unaware visitors.

I watched the consequences of this play out during a recent trip to the island. I was enjoying a cup of coffee and a blueberry scone at The Spot in Princeville. (Side Bar: GO HERE! The food and coffee is FANTASTIC!) A young couple, obviously new to the island, collected their breakfast order at the service window, selected a table, and then went back to the service window to get utensils, napkins, and whatever else. Left unattended for less than 5 seconds, the chickens were on the table and a sizeable rooster had made off with a croissant.

I can only describe the woman’s response as upset and indignant. She promptly returned to the service window and asked – expectantly – for a replacement. To which The Spot employee directed her attention to the sign above the service windows that said, “DO NOT LEAVE FOOD UNATTENDED. Chickens are aggressive and will attack your food if not guarded. WE ARE NOT RESPONSIBLE FOR THE CHICKENS AND CANNOT REPLACE DAMAGED FOOD FOR YOU.”

There are two (at least) lessons to be learned from this. One by the patron and one by the owner of The Spot.

First, the patron. Five bucks (or whatever a croissant costs on Kaui’i) is a very cheap price to pay for a valuable lesson about not just the chickens on Kaua’i, but the very fact that the Rules of Life from wherever your point of origin was have changed. I’ve camped on this island many time over the years and if you are not mindful of the dangers and keep the fact you are not in Kansas any more foremost in your mind, it’s easy to get into trouble. It’s a stunningly beautiful part of the planet with many hidden dangers. Slip and fall on a muddy trail, for example, can be deadly. Lack of awareness of the rip tides and undertows at the beaches can be equally deadly.

So stay alert. Be aware. Read every sign you see. Study what the locals do. Ask questions. And do a little research before traveling to Hawai’i.

For the owner of the Spot, I have this suggestion: The chicken warning sign is written in black marker on brown paper. It’s also placed high in the service window where patrons collect their order. If there is a line out the door, it typically bends away from the service window. Patrons don’t come to the service windows until their name is called. When they do, their natural line of sight is down, looking at the super scrumptious food. It is certain their attention will be drawn away from the warning sign about the chickens (#1 in the picture below) as they focus on gathering their food (#2 in the picture below.)

Fine to keep the sign in the service window, but lower it so there’s a better chance the patrons will see it. Also, put it on white paper. Even better, put a duplicate sign on the inside of the shop viewable from where customers are paying for their food. While they are standing in line waiting to place their order and reading the menu on the wall for the 12th time they are more likely to read the chicken warning sign. Maybe include a cartoon image of a rooster running off with a croissant.

This won’t “fix” the problems the unaware types bring with them onto the island, but I suspect it will cut down on the number of self-entitled noob’s demanding compensation for their lack of awareness. I’d like for The Spot to do everything they can to succeed, which means controlling costs and satisfying customers. I’d also like for the noob’s to gain some self-awareness and take that back home with them.

Win-win.

(I dropped a note to the owners of The Spot with these suggestions. They replied that they liked them and plan to implement these simple changes. If you’re in the area, send me a note, maybe with a picture, as to whether or not the sign has changed. If so, ask if the changes made any difference! Always good to know the results of any experiment.)

Creating Cycle Time Charts from TFS

Unfortunately, TFS doesn’t have ready-made or easily accessible metrics charts like I’m used to with Jira. There is a lot of clicking and waiting, in my experience. Queries have to be created then assigned to widgets then added to dashboards. Worse, sometimes things I need just aren’t available. For example, there is no cycle time chart built into TFS. There is a plug-in available for preview for VSTS, but as of this posting that plugin won’t be available for TFS. With Jira, cycle time and other charts are available and easily accessible out of the box.

Sigh. Nonetheless, we go to work with the tools we have. And if need be, we build the tools we need. In this post, I’ll give a high level description for how to create Cycle Time charts from TFS data using Python. I’ll leave it as an exercise for the reader to learn the value of cycle time charts and how to best use them.

To make life a little easier, I leveraged the open source (MIT License) TFS API Python client from the Open DevOps Community. To make it work for generating Cycle Time charts, I suggested a change to the code for accessing revisions. This was added in a subsequent version. For the remainder of this post I’m going to assume the reader has made themselves familiar with how this library works and resolved any dependencies.

OK, then. Time to roll up our sleeves and get to work.

First, let’s import a few things.

import csv
from requests_ntlm import HttpNtlmAuth
from tfs import TFSAPI
import numpy as np
import matplotlib.pyplot as plt

With that, we’re ready to make a call to TFS’s REST API. Again, to make things simple, I create a query in TFS to return the story cards I wish to look at. There are two slices I’m interested in, the past three and the past eight sprints worth of data. In the next block, I call the three sprint query.

# Anything in angle brackets "<>" is a placeholder for actual values.
# I keep the values in this block in a configuration file and load
# them when the script runs.

if __name__ == "__main__":

    project = TFSAPI("{}".format("<server_url>"), project="<Collection/Project>", user="<user>", password="<password>", auth_type=HttpNtlmAuth)

    query = project.run_query('My Queries/Last3Sprints')

With the result set in hand, the script then cycles through each of the returned work items (I’m interested in stories and bugs only) and analyzes the revision events. In my case, I’m interested when items first go into “In Progress,” when they move to “In Testing,” when they move to “Product Owner Approval,” and finally when they move to “Done.” Your status values may differ. The script is capable of displaying cycle time charts for each phase as well as the overall cycle time from when items first enter “In Progress” to when they reach “Done.” An example of overall cycle time is included at the end of this post.

When collected, I send that data to a function for creating the chart using matplotlib. I also save aside the chart data in a CSV file to help validate the chart’s accuracy based on the available data.

It’s a combination scatter plot (plt.scatter), rolling average (plt.plot), average (plt.plot), and standard deviation (plt.fill_between) of the data points. An example output (click for larger image):

The size variation in data points reflects occurrences of multiple items moving into a status of “Done” on the same date, the shaded area is the standard deviation (sample), the blue line is the rolling average, and the orange line is the overall average.

If you are interested in learning more about how to implement this script in your organization, please contact me directly.

OnAgile 2017

Attended the Agile Alliance‘s OnAgile 2017 Conference yesterday. This is always an excellent conference and you can’t beat the price!

I created a mind map throughout the course of the conference as a way to organize my thoughts and key points. This doesn’t capture all the points by any means. Just those that stood out as important or new for me. I missed most of the first session due to connectivity issues.

Agile Interns

I had the privilege of presenting to a group of potential interns from the Colorado School of Mines interested in agile project management. Action shot…

The slide shows what we can offer them as interns: Failure, chaos, and confusion. I unpacked that as follows…

Failure

It’s important interns have the opportunity to learn how to fail in small, deliberate and safe increments along with the opportunity to learn how to extract every possible lesson from failures and how those failures lead to eventual success. Much of our business is driven by experimentation and hypothesis testing. Most of those experiments will fail, at least initially.

Chaos

We strive to be anti-fragile. One way to accomplish this is to be good at working under chaotic and ambiguous conditions. When involved with highly evolutionary design sessions, shifting sands can seem like the most solid ground around.

Confusion

One of the values for bringing interns into the organization is the fresh perspective they offer.  Why waste that on having them fetch coffee? However, interns can often be intimidated by working with people who have decades of experience under their belt. So it’s important they know they have the opportunity to work in an environment that expects questions and recognizes no one knows it all. They are in an environment that  seeks alternative points of view. In this organization, everyone gets their own coffee.