I presented Liberating Structures to the Rochester Professional Consulting Network (RPCN). They said that they loved the presentation. I think I was just the lucky one to be introducing them to the structures.

The attendees did most of the work by experiencing two of the shorter structures. They brainstormed how to improve community involvement with 1-2-4-all and they explored each other’s challenges with Impromptu Networking.

Reviews varied from the “best presentation” to too much material. Yes, I agree about the amount of material I tried to cover! Next time I will present fewer structures in more depth. I will also try to remember to speak more loudly for the entire hour.

Thank you to RPCN for the practice! I’m very glad that they are likely to use the structures in their meetings in the future.

My favorite type of meeting is a variation of Lean Coffee (leancoffee.org). It has spoiled me for other meetings.

1. When we get together, we brainstorm what we’d like to talk about. You can do this beforehand on stickies or using online tools.
2. Optionally, we present our ideas and aggregate overlapping topics. We often skip this step if the list is small and visible to the whole group.
3. We vote on the topics. Often each participant gets three votes to distribute across the topics or multiple on one topic.
4. We start discussing the most popular topic. After 5 minutes, we evaluate if the group wants to continue this discussion or move onto the next most popular topic. we use a thumbs up to vote to stay on this topic and a thumbs down to vote to move on. If we vote to continue, the timer is set to 3 minutes (or 1 minute if it feels like the topic is winding down). When that timer expires, the voting procedure is repeated.
5. We reflect on the epiphanies, the Aha! moments, from the topic just discussed.
6. We discuss the next most popular topic, setting the timer for 5 minutes and continuing like the last topic, repeating the process until the time or topics are exhausted.

Apparently, I enjoy sharing Mob Programming with kids. It’s just another game with strange rules and tests which pass when we’re successful. I learn much about how to better to explain things and how to teach them better. The students are exposed to code, cooperation, and test driven development.

Recently, my turn came around and I tried to make it reflective, a mini retrospective in the middle of the work. Whatever I said didn’t work. We didn’t know enough about what was possible to know how we might improve it.

People in the next session were kind enough to ask what we could change. We tried changing the timer from 3 minutes to 4 minutes. It worked.

Once, I used my turn to return static text from a Python function to allow us to pass one test. Our youngest member wanted to return one of the other pieces of text instead to pass a different test. It had never struck me how obvious it was to me that I wanted to pass all of the tests with the same piece of code at the same time. Next time, we will try it their way to help spread the understanding. Trying to talk us through it seemed flat.

I think this is becoming my new hobby, taking over a library room and playing with whoever will join me, 3rd graders and older. Come play with us!

Tools used:

• A Chromebook laptop in guest mode
• A free web-based timer, https://agility.jahed.dev/
• A free codewars account and codewars code challenges (katas, https://www.codewars.com) - starting with Hello World followed by group selection of the next 8 kyu (easiest level) Python problem to solve
• A monitor large enough for us all to see - thanks to the library!
• A library study room large enough for 10 people for 2 hours
• 2 to 8 fabulous students

=======

total cost: time, tax dollars, and a low end laptop

I haven’t mastered the pronunciation of the card game known as Scrumchkin, but I have enjoyed facilitating it a few times.

I’ve played Scrumchkin with groups of various Scrum skill levels. Some had mostly no Scrum experience. Some groups were comprised of experts, they teach and coach Agile techniques. Each group had fun. Each group admitted how this game reflected real life situations.

Some games were like being handed a really bad base of legacy code, with test automation and continuous integration not available to us. Other games were riddled with developers joining and leaving the company. Some games have people out sick like it was a bad flu season.

I’ve resorted to stacking the deck part-way through a game because a team hadn’t yet uncovered an impediment. I was pleased to discover that team handled them well.

I have been delighted by some of the teamwork groups added to the game. How do you know which day it is in the sprint? How do you know how many moves you have remaining that day? How does the group know if they will meet their goal? How do they negotiate with the Product Owner to have enough work to do?

All of the games depersonalized situations we see in our jobs. They made it possible to discuss situations without the emotional component of it being “my code”, “my problem”, or “my mistake”. It’s a team issue to solve.

I have apparently contradicting philosophies.

1. Scrum isn’t good for everything. Some things are not complex enough to warrant it.
2. Scrum isn’t the “secret ingredient” of your Agile transformation. If you are working very hard to do Scrum by-the-book, you are probably not seeing the benefits that you expected. Even worse, you may be making your system brittle and prone to catastrophic failure. A common pattern here is that you are producing a local maximum. You are optimizing the team doing Scrum and sacrificing all of the teams that surround it. The Scrum team is optimized, but the company or product is not.
3. When you have chosen to use Scrum, if you’re trying to deviate from Scrum proper, you are probably trying to optimize the wrong thing. For instance, if you can’t get the stakeholders to attend the reviews, you stop inviting them to the review. This makes it easier on the Scrum team, but significantly increases the risk that the product you deliver will not be what they need.

I facilitated a retrospective on decision making with a team that I believed to be slowed down by busy schedules and consensus-driven decision making. As normal, I was not entirely correct. The discussion was valuable.

Retrospective construction

We opened with an appreciation shower. The group had been apart for a while and it felt like we needed to reunite. They did well!

We went on to brainstorming what kinds of decisions we make. I nudged to make sure that we covered all of the major topics that I had thought of earlier and pushed to break things down into logical categories for the next exercise.

We proceeded to categorize how much we wanted to be involved in each decision.

• Pink - Decider - Need to agree to the final decision
• Blue - Consulted - Want to have their opinion heard, but don’t need to be involved in the final decision.
• Yellow - Informed - Would like to know what is decided.
• no sticky - Don’t need to be involved with the decision.

The results of that process are in the image. (Yes, that is the back of wrapping paper. Reduce/reuse/recycle…)

Discussion ensued about the pink stripe of decision involvement. Some team members wanted to be involved in most decisions. Some members wanted to be informed about most decisions. I (C, bottom row in the image) want to only know about the ones that affect me as a peripheral member.

The final phase was to discuss actions, which was cut short with our time window closing. I expect suggestions will appear for weeks.

What I loved

• We calmly talked about how we decide as a group. It felt removed from points of contention seen in specific decisions.
• We talked about future decisions we will make and proposed methods for handling them.
• We found that lack of a response does not necessarily mean no; and that a deadline for a response/veto of the suggestion is acceptable.

What I’d do differently

• Schedule the discussion for a time when we have extra time for slow starts, interruptions, and lingering discussions about changes we could make.
• Stop assuming that more people being involved slows down the process. It will if it means adding yet another hand-off/signature to the process, but being a “Decider” does not reflect the level of involvement desired. The level of involvement could be anything from a researcher of possible options to a light-weight approval of the final option. It could mean that the person is willing to actively help speed up the decision.
• Introduce what we are going to do with the decision categories before generating the categories to reduce the amount of nudging and pushing to conform with the next exercise.
• Add a decision category for “Vetoer” as a step between Decider and Consulted.
• Consider adding a decision category for “Researcher” above decider for active involvement in exploring options.

I have learned that the more adamant I am that something is not my problem, the more likely that I will need to fix the problem.

The worst case of this was when I was working in embedded software. I found out that the feeder mechanism was wrong, the physical, mechanical part. I was convinced this was not my problem. The mechanical engineers clearly needed to fix the equipment. When all was said and done, I was asked to, and did, fix it in software.

I now try to remember that when you point the finger at others, three other fingers are pointing back towards yourself.

I needed to look up Heraclitus’ quote about a river only to find out that I misremember it or that the new translation I found is more specific than I remember.

This is the translation I found: “No man ever steps in the same river twice, for it’s not the same river and he’s not the same man.”

I remember it simply as “No one steps into the same river twice.”

To me, the emphasis was that the water relative to the river bottom changed with time, making it more akin to “time changes everything” than “time changes man”.

In the global view, it is still the same water, still the same rocks, but if you look closer, the temperature, mineral content, flow patterns are a little different. The rocks aren’t in exactly the same place and are a little smaller. Did you make assumptions that it would be exactly the same? Or were you just generalizing?

The new quote adds my changing filters to the mix! Did I just have caffeine? Did I just have an argument with someone? Do I have a toothache? Did I last time?

Recently, I’m recognizing old biases may no longer apply. Just because a company had a policy I objected to 20 years ago does not mean that they still have it. It doesn’t mean that something I don’t see as obvious isn’t true. If I sound like a stick in the mud, I’m probably doing it again. Feel free to gently confront me. Ask me why.

I’m getting better at catching those moments and better yet at doing something about them.

I called up an old coworker and had lunch. They do not have that same policy. Soon I will confront a bias about other related industries.

I could have just misremembered the quote. ;)

What old biases are you working to overcome?

My friend is going through an Agile transition. His backlog (to do list) is mostly converted to small pieces of functionality that the customer will use. There are a few old items from before the transition that are listed as pieces of work for behind-the-scenes. They describe work on individual components that need to interact to create something bigger the customer will see. I was unable to see if his dismay at the problem was warranted or not. I asked him four questions.

What is the risk?

Normally, having component based activities causes the team(s) to work in more of a waterfall way. We need to do X, Y, and Z before we get customer feedback instead of smaller, and therefore faster, pieces. What is the risk? What if the components don’t interface? What if it delays other work? How does a delay in any of these components impact other things? What number can you put on it?

What is the waste?

Now that we’re implementing something that will take a while to get feedback about, what happens if the customer doesn’t like it? What is the waste? What is the probability that you are doing the wrong thing? How can you tell? What is the failure rate of similar features? What number can you put on this?

Note: I have stopped at this stage before. The numbers were too small to fuss about.

How can you get others to see this?

Assuming the previous questions show you that you have a big problem, how can you share it? How can you get others to see this? It will be a good check on your numbers. How do you avoid being talked out of your figures and still show a truth?

What experiment can you try?

Now that you have numbers, you have probably made many assumptions. How can you evaluate the assumptions. What experiment can you try? What if you could get part of the solution in front of the customer early? Can you validate the interfaces? Can you create dummy components to allow early testing?

Just four questions to check your gut reaction, no answers.

It’s short and sweet. The purpose of Friday Path LLC is to make people awesome.

We collaborate with our clients to make better products, to grow better environments, to accelerate delivery - with awesome people.

Here are some things that our purpose is not:

• We do not “make” anyone do anything. This is not a forceful mission. At best, we can help try to convince people that they want to be awesome. Better yet, we can help show them a path to awesomeness.
• We do not remove all obstacles on the path to awesomeness. Some of those obstacles are needed for growth, learning, and inspiration. Removing all obstacles moves awesomeness farther away.

I’m trying to imagine a world where I knew about mob-programming before I picked a college; before I picked a major. It’s a world where I would have known that not all software developers hibernate in a cubicle writing their own code all day; where some Software Engineers actively collaborate on interfaces, knowledge sharing, and training. Software Engineering (or Computer Science as it was called then) would have sounded much more interesting.

Would I have switched from Chemical Engineering if my college Pascal class had group programming assignments? Would I have skipped my first career entirely?

I look forward to giving young people the chance to choose for themselves.

Introduction to Mob Programming in Python for Parent and Child

Bring your child and help them show you how to solve problems on the computer. Take turns leading, typing, and helping others using the rules of mob programming and the Python programming language. Python is one of the more easily readable programming languages and is freely available for multiple types of computers. All experience levels welcome.

Come play with us!

Open Space technology is a lot like multi-threaded Lean Coffee over a longer period of time. If you’re still reading, this will make more sense very soon!

A Lean Coffee meeting is self-organizing. The people who attend the meeting suggest what should be discussed. Everyone expresses their preferences, often by dot-voting for their three highest priorities. The topic with the most votes is discussed first, after a few minutes the group votes if they should continue to discuss the topic or move on to the next topic. The highest priority topics are addressed, the lower priority items may not fit into the meeting at all.

In Open Space meeting, a space-and-time grid is proposed - perhaps three rooms for one hour intervals for 5 hours. Participants suggest discussions/meetings and schedule them into a room at a time. People negotiate commonalities and overlaps. They try to schedule their discussion when it doesn’t preclude attendance of other discussions they are interested in. When the first time slot starts, people vote with their feet. They attend the session that most interests them, often by walking there. Some discussions will be large, some will not happen. Some will run long and need to find a new space to continue.

Both Lean Coffee and Open Space maximize the alignment of the discussions with the participants’ priorities and interests. Both need much leadership from the group. Both need much collaboration and respect within the group. Both result in very interesting discussions. One needs more space and time.

What’s your problem’s domain?

I introduced 20 New York state-licensed engineers to Agile concepts at the 2019 Engineering Symposium Rochester.

The most concise review I heard was “mind blown”. Another person was a non-believer. Most of the audience members were established Electrical Engineers.

One of my core premises was that Software Engineering typically resides in a different Cynefin framework quadrant, a different problem domain space.

Although Electrical Engineering problems take considerable expertise, the solutions are generally governed by known physics and manufacturing limitations. There is an expected endpoint deliverable that may not be physically possible. I categorize it as being in the Complicated problem domain.

Software Engineering, because of its inherent flexibility rarely has a static endpoint for development. This is exacerbated with products that interface with people. Customer style choices change with time. Market research can change the desired direction of development.

The software application space is nearly as volatile as the fashion industry. Optimally, the software engineer works to make the things that are likely to change easy to change. It is easy to understand that the look and feel of the graphical user interface will need to change. Other items that will need to change are not as obvious.

Due to this moving target, I categorize most Software Engineering in the Cynefin framework Complex problem domain.

Non-Software Engineering problems that work with the natural environment, biology, or unpredictable inputs (e.g. waste streams) blur the line between the Complicated and Complex problem domains.

Here is the presentation that I used.

What is your problem’s domain?

• January 5th RocAgile meetup on Theory of Constraints – Current Reality Trees https://www.meetup.com/Roc-Agile-Meetup-Group/events/275069246/
• The RocAgile Meetup group http://RocAgile.org - first Tuesday evening of the month U.S. Eastern Time
• The Agile Water Cooler https://agilewatercooler.com/ - Discord group and online Zoom call 11 AM ET Mondays

Your coding stinks

That’s not what I said, but I’m sure that is what they heard.

Mistakes were made

When I was asked point blank what I thought was wrong, I told them. I probably said something about eXtreme Programming or the craftsman movement, but that wasn’t what was heard. Worse yet, I interpreted the look on their faces to mean that they didn’t hear me, instead of that they didn’t understand why I would say it. I heard about the discussion for weeks.

What I want to do today

When this happens again, since I’m sure that it will, my gut reaction is to hold up a figurative mirror and encourage them to come to their own conclusion. Something like “I think code that is difficult to work on, constant interruptions for bug fixes, and dependence on the Quality Control group all have the same cause. What do you think? What do you think that cause could be?”

I know they are wonderful engineers with bright futures, and I hope they do too.

How do you approach a request for the bottom line?