That time I facilitated brainstorming in a 3-minute presentation

Yes, I really attempted to do brainstorming during a 3-minute presentation.
Technically, I failed. It was one of my better failures. If your criterion was that I was respectful of the timebox, either it was a spectacular failure or permission of the Product Owner makes it all ok. It actually ran for about 5 minutes.
I was using the "10-12 minute" 1-2-4-all exercise with the silent writing phase (1) being 30 seconds long. The thought was that each phase would be just 30 seconds long, truncating the typical idea collaboration steps to simply choosing our favorite idea.

The concept

1 - silent written individual brainstorming (30 seconds)
2 - pair up with another person and pick your favorite idea (not necessarily written before) (30 seconds)
4 - pair up those pairs into foursomes and pick your favorite idea (30 seconds)
all - as a group, pick our favorite idea (I didn't expect we'd have time to do much with this.)

The play-by-play

  • I trimmed all of the side-comments out of my introduction including the one about the process being like March Madness for suggestions.
  • The introduction lasted more than a minute. I was already behind schedule!
  • Dispensing of supplies went smoother than I expected - since I was doing the introduction at the same time. I neither tripped nor threw pencils or paper.
  • We held to the 30 seconds of brainstorming silently on paper. I only needed to repeat the topic once; which was amazing given the lack of redundancy in the introduction.
  • Switching to pairs is much slower than I dreamed. I think I cut most teams short in the transition to foursomes.
  • Around this time, I checked with the host (effective Product Owner), he was fine with running over. He really wanted to hear the results.
  • The results from the teams were great! We had great suggestions from people who were new to the event that will help orient everyone. We had great suggestions on how to diversify the content of the event. Some people had even extrapolated beyond the silent brainstorming ideas.
  • The moment I heard the first suggestion, I completely forgot that I was going to have the group vote on our most favorite if we had time. It no longer seemed important.
  • We gave the host all of our brainstorming sheets. I know he will pour over our less favorite ideas for weeks to come.

The results

All-in-all, it was a nice experiment to run, and a nice failure to have under my belt. Next time I have just 3 minutes to present, I will actually need to talk about my company; or maybe, I can work with the Product Owner before the presentation to change the rules of the game...
What do you talk about in a 3-minutes presentation anyway?

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 ( 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,
  • A free codewars account and codewars code challenges (katas, - 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!

That time I kicked the Product Owner out of the Retrospectives

Mistakes were made

Long ago, and not so far away, I was a Scrum Master for a team of developers. We were all new to the codebase. Our Product Owner had years of experience with our domain and our codebase. We deferred to his opinion in all things, unnaturally so in the Retrospective meetings. I asked him to stop attending.
Not having the Product Owner at the retrospective for a meeting or two while we found our groove might not have been too bad, but I never thought to reinvite him. Imagine all of the valuable input we could have had!

What I've since learned

  • This Product Owner was extremely coachable. Had I identified the problem to him, we could have worked together on strengthening the developers and the team.
  • There are many techniques to help gather input from the whole team to avoid the "loudest talker" problem, or in this case, the most influential voice. Two of my favorites are and
  • mob programming exists

What I hope to do in the future

  • Try to keep the team whole. Coach the Product Owner and the developers about how deferring to the product owner in the Retrospective reduces our chances of having great new out-of-the-box ideas for improvement.
  • Intentionally use retrospective techniques that are designed to balance the individual input.
  • Be intentional with team building. Help the Product Owner see the developers' strengths and the developers see the Product Owner's humanity.
  • Coach the Product Owner to vocalize the value of each developer in order to help them know that their voices are valued.
  • Mob program with the Product Owner, particularly as we were ramping up on the code base and domain.
  • Follow-up with the Product owner if I kicked them out despite my hindsight.
  • Target (at least some of the) retrospectives on specific issues that the whole group can contribute to.
  • Train the group on the domain more.
  • Train the group on the codebase more.
How can you improve based on my mistakes?

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 is this Agile Water Cooler anyway?

Where would you go if you had just one niggling Agile question? A local meet up? Reddit? Your Scrum instructor? Take it to the team? (hint: The answer is always "take it to the team".)
you could go hang out at the agile water cooler to get a fresh perspective.

What it is

The agile water cooler is a discord group of Agile minded individuals: Some are studying for their first agile certifications, some have been doing agile for years, some get together for a lean-coffee web-based call weekly to talk about the problems of the day, and I am one of them.
Details and invitation to the Discord group are available at 
Please join us.

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?

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?