Saturday, September 5, 2015

Mob Programming and Trivial problems

Whenever I hear about Mob Programming people always talk about how great it is for the hard problems.

But let’s explore a fictional example of some trivial work because I believe this is where things really start to shine.

At the Institute for Boring  & Monotonous work (IBMw) there was a team of 6 developers that whose large code base had all become destroyed due to a large disk crash. Fortunately, all of the code had been printed out before the destruction, but it had to be re-typed in. The estimated work was going to take the 6 programmers 8 months. It doesn’t get more trivial than this, IBMw was really living up to its name.

Nonetheless, Mob Programming was the new buzzword so this team said, “why not try it out?”. Here’s what happened.

Day 1 (Many eyes):

The team started typing in the pages. They quickly started to arrange focus so that a couple would be manning the physical paper and couple eying the projector to keep everything in tack. They were definitely slower with only one person typing, but they also realized that they weren’t making any typos. This is very important as the code had to be perfect or the whole system wouldn’t fit together again.

At the end of the day they retrospected as it is recommended for mobs. They came up with 2 big findings.
1)   quality is up
2)   some people can’t type
Idea for improvement: “Let’s spend 20 minutes tomorrow working on typing”

Day 2 (Countable Improvements)

The mob downloaded a typing tutor and started the day working on keyboarding. It didn’t make a huge difference, but  it was nice to know the slower members were working on it. Made it easier to be patient with them during the day.

But one part of the day went a bit off, something went wrong with the typing and they had to debug a bit. As they did someone counted the number of words. Paper: 304 Computer:303. Damn. Eventually they found the missing part.

At the daily retrospective, a couple of post-its showed up in the positive side with ‘word count helped debugging’

Day 3 (Checks)

They continued with the typing practice in the morning. A little progress but not much, some members had moved from 15 words a minute to 16.

The word count was really helpful so they started doing that with each part. It usually wasn’t wrong but there was something reassuring in knowing that the computer matched the paper so they kept doing it. It was extra helpful when it didn’t match. However programmers can be extra lazy and  someone complained that it sucked that they had to count the words on the computer as well. Everyone agreed, and then they suggested they write a small programmer to count the words for them. Easy enough; No more manual counting of the words.

The retrospective had a lot of sticky notes with “auto counter” written on them in the what went well section.

Day 4 ( Auto-enhancement)

It was great having the ability to know the word count when they matched up, but still a bit hard figuring out where the missing part was when it didn’t. So they would add improvements to the AutoCounter to allow for easier debugging. It was interesting to note that some of the best ideas came from the most frustrated people. Team members that never would have been able to implement those ideas on their own.

At one point, they just couldn’t get past one section.
“I know something is wrong”
“But the word count is the same, even the character count is the same”
“but look at it, it doesn’t feel the same”
“yes, but, oh the printed font is different. That’s why it feels different”

The retrospective had a bunch of “font caused frustration” in the negative side.

End of Week 1 (double check)

After typing practice the first thing suggested was to change the font to match the paper. This made the day a lot easier. They would hold the paper up and do a quick sight match. Still programmers are nothing it not lazy. The retrospective included “arm tired from holding up paper”

Week 2 (Seeing words)

The second week seem much easier than the 1st. They brought in a second projector to overlay the paper so it was even easier to see the differences, but this also got them thinking why do we need to count the photo? It was too hard to program up something to read the printouts, but it wasn't to hard to detect the words. They could figure out the boxes around words. It wasn't great but it helped.  Now WordCounter could also help a bit with the physical world.

They were still doing typing, but it wasn't helping much the slowest was up to 22 words per minute on Friday from 21 words per minute Thursday.

Oh, someone was sick and out for 2 days, didn’t really matter.

Week 3 (Word counter sees letters and bugs)

The team was able to get the boxes from words to letters. This really improved the speed of the checking and we are almost completely sure there are no bugs going in from typing now. Of course there were some bugs in the original code. We got in one argument over a weird compiler setting that has different effects on how a struct would end up in assembly code. It was rather goofy, but we added setting to Word Counter to notify us if this shows up again.

Typing still isn’t helping much, our slowest is barely making 26 words per minute.

Week 4 (Splitting Word Counter)

The team split up the Word Counter into a separate program that detects the patterns of common bugs. We only have 3 patterns so far but its pretty neat and we are removing some bad code because of it. We were also able to run this over the previous code so fixed some stuff from the first 3 weeks.

We also had an idea of how to detect the letters from the printouts, but it didn’t work.
On the failure side, typing is still not really improving. Slowly McTypesABit is only doing 30 words a minutes.

Month 2  (OCR & Linting)

This month we were able to add a lot to the bug finder. Up to 13 patterns. We’ve even shared the program with other teams to help them check their code. We also got a way to do a bit of automated reading of the characters from the printouts. It’s not very good (about 50%) but it gives us a starting point which is nice and we are doing good overall. Might even be a month or two early to finish this project.

On a side note: because of a 2 week vacation we have a new slowest typer! It’s very close though (40 wpm vs 39 wpm)

Month 3 (Done Done?)

The WordReader is still having problems (only 80% accurate) but it’s been helping us move really much faster. With the combination of BugFinder we are going to be done with the rewriting by the end of next month. The teams still has budget though and it looks like both WordReader and BugFinder might be useful outside of just helping us finish our original Task. We are looking into making them more robust…

Wednesday, April 15, 2015

Making Things Smaller

Often, when people talk about minimum viable product or story splitting we hear the question

"but how can I make this smaller?"

I'm going to show a very simple, powerful and yet often overlooked strategy for doing this.

Use smaller numbers

If your scenario has numbers in it make them smaller. You can do this in 2 ways depending on what you are trying to accomplish.

Minimum Viable Product

When you are trying to get to the smallest thing start your numbers near 0 or 1.

Here are some examples:
 "This report should do 5 things" -> "This report should do 1 thing"
 "Get data from 3 sources" -> "Get data from 1 source"
 "The UI changes these 8 things" -> "First we will change this 1 UI feature"
"We check in code every 8 hours" -> "We check in code at least once an hour"

Sometimes people 'hide' the numbers
 "Handle English, Spanish & French" = "Handle 3 languages" -> "Handle 1 Language"

Also, remember that programmers tend to think in terms of only 3 numbers: 0, 1 & many
 "Save directories" -> "Save many directories" -> "Save 1 Directory"

This also creates a very nice step from 1 to many of 1. In programmer that is:

"int postalCode = 90210"  -> "int[] postalCodes = {90210}"

Minimum Viable Change

When coaching you usually want to go the opposite direction so that the change is less noticeable and easier to absorb without conflict.

 "Our sprints are 4 weeks" -> "Our sprints are 3 weeks" -> "Our sprints are 2 weeks" -> "Our sprints our 1 week" ->  "We release weekly" -> "We release daily"

 "Our Build has 9 manual steps" -> "Our build has 8 manual steps"
Sometimes this shows up as negative numbers:
"No teams are writing tests" = "8 teams aren't writing tests" -> "7 Teams aren't writing tests" = "1 team started writing tests"

The Point is... if you start making a habit of looking for numbers in your stories and processes you will see them everywhere and then they are easier to reduce.

Monday, January 5, 2015

Women in Tech & Men in Zumba

I have been a long time supporter of women in tech but today I realized how little I truly understand their situation.

Today my girlfriend brought me along to a Zumba Gold class. This is a easier version of zumba and often is frequented by older (60+) women. We were the youngest there by far.

I was the only man.

I'm a good dancer. Proficient in swing, salsa, cumbia & merengue which is basically what Zumba is. Youth is also an advantage in most physical activity. This should be very easy for me. Also, everyone was both very nice, complementary and welcoming. 

I was the only man.

I felt very uncomfortable. I would not have been there if not with my girlfriend and can't imagine going there by myself. I wouldn't say that I enjoyed it. I wouldn't say that it was "my thing". I wish I could have turned invisible many times. But that was not the worst thing.

The worst thing was I had absolutely no idea what to do to make the situation more comfortable. Here I was, with all the self interest in the world to want to make things easier and no idea at all how to do it. 

I did gain some clear insight into what I did NOT want:
  • please, oh god please, do not single me out or call more attention to me
  • I felt very uncomfortable when people would come over to give me compliments
  • I did not enjoy the particularly extra girly dance moves
This makes me question some of the things I would do in regards to women in tech. Such as 
  • Make sure the women are recognized
  • Compliment women when they do good 
  • Anything remotely 'brogrammer' related (the mere thought of this now makes me cringe)

As uncomfortable as it was being the only man in zumba today, it was one day. It's not like it's my career... 

I can only imagine how many girls we lose the first few days of a programming class when they just feel like they don't fit in.

Sunday, October 12, 2014

The Interview - Putting together a new mob

Hello. I’m Llewellyn Falco and recently I embarked on forming a 5-person mob to be hired for full time employment. This series is about our journey where I will share the good and bad so others can benefit from our experiences.

This week:


Once I finally figured out who the potential mob was I was faced with a difficult question. “How in the world are we going to determine if all 5 of us are the right fit for this company”
In other words:

“How do you interview a new mob?”

Speed Dating

I have always found interviewing for full time employment a bit of a crapshoot. It’s like going on a single date with someone and then asking
“How about getting married?”

I am not saying it can't work. It’s just a bit risky and the cost of a failure of judgment is large. This risk becomes extra large when the new job includes a move of either your current job or your current hometown or both.

Now multiply that by 5 for the mob.

Add to it the fact that both sides are looking for the entire mob to be hired, only 1 or 2 of us isn’t what is desired.

Finally, the ‘entity’ that is looking to be hired hasn’t even formed yet. The 5 of us had not worked together and the dynamics of how we will work together are still unknown. And the only way to detirme this is to take the time to allow us to figure it out.

Here is the solution we came up with and it worked well in solving out of the above problems. I’m sure its not the only way to tackle this problem but I was happy with it’s effectiveness.

Minimum Viable Hire

Most of agile looks at breaking big risky things into smaller more concrete tasks and then assessing the next step with the help of actual data & experience. So we took the same approach with the interview.

Rather than going from a few hours of talking, to everyone quitting their current jobs and signing on full time, we introduced some middle steps.
In particular, we decided to start with two separate consulting trails of two weeks each.

Advantages of the trial consult

This offered many advantages.

Each member of the mob simply took their vacation time which meant that no one had to quit their current jobs until they were sure this was the right move.

 Likewise, no HR and no unemployment from the hiring company if they decided we were not the right fit for them later on.

This allowed for time for the mob to form so all party were acting on first hand true information about what we would be like as a functioning mob. No guess work needed

There can be a large difference between stated values and demonstrated values. This was long enough to get past the ‘honeymoon phase’ and have a clear understanding on all sides

As a matter of practicality we decided to average all our rates so that all of us started out on equal footing. While I’m an advocate for open salaries I do not believe everyone should be paid equally. However, this was a temporary measure to allowed a much cleaner start and I believe it also leads to a fairer final pay scale.

Note: I was the highest paid of everyone which means I had the most to lose (my rate was about ½ of my normal rate when averaged out with the 5) and I still believe this was for the best long term results.

So we simply added 2 smaller steps between first introductions and full time employment and it was better for everyone.

Next week: Discovering the right Physical Environment for the mob.

About the author:

Llewellyn Falco is the creator of ApprovalTests & cofounder of TeachingKidsProgramming. He is currently a consultant and Technical Instructor. He introduced Woody to the randori style of programming and has been a fan of Mob Programming since the beginning. 
You can follow him on twitter at @LlewellynFalco or email him at isidore at

Tuesday, October 7, 2014

Putting together a new Mob

Hello. I’m Llewellyn Falco and recently I embarked on forming a 5-person mob to be hired for full time employment. This series is about our journey where I will share the good and bad so others can benefit from our experiences.

This week:

Putting together the Mob

The final 5 of us all meeting for the first time for a get to know you dinner

A very common question is
“What’s the right number for a mob?”

Of course, there is no right answer for this and we tend to use the heuristic of

A mob is the right size as long as:
Everyone is learning or contributing

However, if you are assembling a mob for full time hire then that heuristic is not very valuable.  So here is what I used with the best understanding I have as to why I choose these strategies.

Size: 4-6 people

This really came from the idea of the Amazon 2-pizza box team. I wanted a team that was small enough to really operate as a team. I did not want to try to start more than one mob at a time and I didn’t want the “scrum of scrums” approach. We were looking for the “matrix of indepenant services”


Finding the right people is always a tricky thing. I wanted an all-star team of some of the best programmers I know. As such I quickly made a list of the top 20 programmers I was aware of in southern California. This gave me a playing field, but there was still a lot to do.

Gathering Talent: There are the practicalities that none of the best people were unemployed, which makes it harder to hire them. However, this is a real plus for mob programming. Being able to work with the best people is a real incentive for the top people and many people on the list were willing to explore this opportunity despite already having great jobs.

Skill Sets: I also needed a good mix of skill sets and personalities. When I say skill sets I don’t mean the trivial things like json or c#; anyone can pick those up quickly in a mob. 
I mean harder to learn things like: 
artistic ability, 
algorithmic thinking, 
sense of style, 
emotional intelligence, 
creative problem solving, 
I wanted a good mix of these harder to learn prophecies to create a more diverse mob.

I ended up with a 5 person mob ( 2 people turned me down ). I had worked a little bit with each of them on some open source projects and some of them knew/worked with each other beforehand but we had never worked as a mob before.

But now we had chosen the mob. We met for dinner (pictured above) and set out on our next adventure.

Next week:  How a company interviews for a 5 person full time hire.

About the author:

Llewellyn Falco is the creator of ApprovalTests & cofounder of TeachingKidsProgramming. He is currently a consultant and Technical Instructor. He introduced Woody to the randori style of programming and has been a fan of Mob Programming since the beginning. 
You can follow him on twitter at @LlewellynFalco or email him at isidore at

Thursday, July 17, 2014

#NoEstimates and Travel

Today I tweeted:

1970's: Trips require $$ estimate & traveler checks
2014: Bring a credit debit card & only convert what I use
#NoEstimates #ContinuousDelivery

The idea I was looking at is pretty simple, when you have continuous flow you don't need to predict. It changes your behavior and allows you to to hit your mark exactly instead of having a lots of leftover money later you need to re-exchange.

Batch vs Continuous Flow

To me this echoed trends I've experienced in software development. As I've been able to approach a more continuous flow I have spent less energy, effort & time predicting what I'll do. I simply exchange work for features as I need them.

Unfortunately, there is still a lot of room for misinterpretation on twitter. So I wanted to clear up some misunderstandings.

An example would be useful right about now:

Let us look at 3 sample situation (number adjusted for inflation)

Robert (1970's)

Let's say that in 1970's Robert goes to Europe. Let's look at the numbers
Bank Account: $20,000
Traveler checks: $2,000
Expenses in Europe: $2,500

Marsha (2014)

Let's compare this to 2014 when Marsha decides to travel.
Bank Account: $4,000
Payment method: Debit Card
Expenses in Europe: $3,000

Abundance vs Flow

One misconception is that this means only works if you are rich and will never run out of money. However this clearly isn't the case with Robert & Marsha. Robert has much more money than Marsha, however he's in trouble, stuck in Europe with no access to money. He will tell you how he should have planned better. Maybe he didn't take resturants into account properly or taxis or souvenirs. All of this could have been avoided if only he spent more time planning and had better estimates.

But Marsha didn't have these issues. She had less money and she didn't plan her expenses at all. This doesn't mean she didn't have expenses or a limit of how much she could spend it simply means she didn't have to go to bank ahead of time and say "I would like $3,000 worth of travelers checks for my trip" 

This is a pretty well understood idea in the financial world. It is the difference between Liquidity &  solvency. Both matter.

If you are insolvent it doesn't matter how good you are at estimating, you are broke.
If you have high liquidity it also doesn't matter how good you are at estimating, you have access to you money.

Estimations vs Awareness

Estimation is the ability to predicted what I do. Robert needs this to travel in the 1970's, Marsha doesn't need it in 2014. 
However, this does not mean Marsha can just go all around Europe spending money like crazy. She needs to be aware of how much she is spending. She need to understand the conversion rates and know when she is spending too much. 
Her decisions matter
She needs to be aware but that doesn't mean she needs to be able to predict.

Making Smart Decisions

Marsha spent more than Robert. 
Does that mean she spent her money better or worse?
It's impossible to tell from the budget alone. Making smart choices is important. 
Sometimes people believe that - 
 estimates are the only way you can make smart choices

This is crazy. 
People make great decisions everyday without estimates.
Of course there are also people who know exactly what is going to happen and do it anyways :-|


When people are trying to lose weight they spend a lot of time planning meals and counting calories. They will tell you about how important that is, but people who are thin and have been thin there whole lives don't tend to do this. They just eat sensible, they know when they are full and stop eating. 

I must admit I have a bit of resentment today these people as I have never been one of them myself. This jealousy helps me to remember and sympathize with people who are struggling with estimates and refuse to believe they are not needed or a poor use of time and energy.

Travel Tips

If you are traveling in the 1970's here are some travel tips. When you enter a country the immigration officer will check that you have enough money for the trip, one way to do this is take out $1,000 in traveler checks and say that you lost them. Then you will get issued an other $1,000 in checks. Be careful to mark the original checks because if you spend them you will get charged with fraud but ...
wait, where are you going?
 ... these are helpful tips 
... oh you don't live in the 1970's?

Well, maybe you'd like to hear some better ways of estimating?

Monday, June 30, 2014

Llewellyn’s strong-style pairing

Arlo Belshee once labeled my particular style of Pair Programming "Llewellyn's strong-style pairing"

The golden rule for this style of pairing is:

"For an idea to go from your head into the computer 
it MUST go through someone else's hands"

The Process

This style is actually very close to an actual navigator / driver situation in a car or on a boat. With all the high level commands coming from the navigator and the lower level implementation happening from the driver.

This style of programming is all about increasing communication and collaboration. Verbally communicating code and editor commands is a skill like anything else but it is one that many people have not developed yet. Don't worry, it's pretty easy to gain and most people pick it up the basics in a few hours.

The Driver

As a driver (at the keyboard) this is a fairly simple and peaceful place to be. I have been the driver in languages and editors I was completely unfamiliar with without problem or indecent. However, there are two important things that are required for a happy driver experience.

"Trust your navigator"
When you are the driver trust that your navigator knows what they are telling you. If you don't understand what they are telling you ask questions, but if you don't understand why they are telling you something don't worry about it until you've finished the method or section of code. The right time to discuss and challenge design decisions is after the solution is out of the navigators head or when the navigator is confused and unable to navigate.

"Become comfortable working with incomplete understanding"
Even if you trust the navigator, the navigator might not be comfortable navigating you in this strong style. To combat this they might try to explain everything to you before you can actually start to code. This slows things down a lot and depending on your level of knowledge can taking hours or even days before you can even start. Don't worry about knowing everything, you will learn as you go. Don't worry about not knowing stuff. You might not know the language, os, editor, code, or even the problem space you are working in. It's ok, you will soon.

"What if I have an idea I want to implement?"
Great! Switch places and become the navigator.

The Navigator

As the navigator you have two main jobs.

  1. Give the next instruction to the driver the instant they are ready to implement it
  2. Talk in the highest level of abstraction the driver can understand
The navigator is essentially managing a ToDo list in their heads. As you go through the code you keep adding things to the list and as the driver is typing you keep removed the completed items from the list. The key is while you are handeling and tracking 2-20 things at a time, the driver is only ever responsible for 1 thing. This is the key to letting the driver stay in a state of flow. This is the number one main job for the navigator; Manage the big picture details so the driver can stay focused on the code they are typing. 

The second job of the navigator is to speak at the highest level of abstraction that the driver is able to digest at the moment. This will change by driver, of course, but it will also change during the day for the same driver. 
For example, a navigator might tell the the driver "extract that method" to which they might get a blank stare. The navigator should then restate that intention at a low level of abstraction. Such as "ctrl+alt+m" or even "highlight lines 14-20 and then press ctrl+alt+m". After doing that a few times the navigator should be able to revert back to the higher level of "extract that method" but always realize that later the driver might be tired or just plain forgetful, adjust accordingly. 

It is the navigators responsibility to communicate in a meaningful way. This means you shouldn't be speaking above the drivers understanding. However, it is also the navigators responsibility to be ever increasing the the level of communication and understanding. Stay mindful of the driver and be constantly adjusting to them.

"Just do it"
Although you are the navigator, you are going to make mistakes and bad decisions. Correct them when you do but don't sit around and plan to try to avoid.  When someone has an idea have them take the navigator role and go. once it's out look back with the benefit of  hindsight and refactor or redo it so it's better.

The Mouse

When there are just two people, I find that often the navigator will end up with their hand on the mouse. This tend to work well when the activity is much more keyboard focused (like programing). It is horrible if you are doing something more mouse focused such as graphics or installs. 

Common problems with pairing 

The main reason I use this method of pairing is it solves many of the common problems I see occurring with pair programming. Here are a few of the problems and how this style of pairing addresses them.

1 person working and 1 watching

If your navigator isn't engaged then you really are not even pairing. Traditional pairing makes it unfortunately easy for the person not at the keyboard to zone out and disengage. This is literally impossible with the strong pairing style as the only way for that to happen is for both people to be doing nothing.

Fighting over the keyboard

Different people might have different ideas on how to implement something. While this still happens with strong pairing style it changes from wanting to grab the keyboard and shut out the other person to wanting to let go of the keyboard and communicate your idea to the other person. 

Expert/Novice Pairing

One part of pairing that is often highlighted as a problem is the Expert/Novice combination.  You can imagine that watching someone fly through pages of code when you are unfamiliar with the language, editor or even the business domain would be hard enough to follow let alone contribute. With the strong style of pairing, however, this because an very valuable combination to both the expert and the novice. In this style, the expert almost always is in the navigator position having everything go through the novice. This is a very intense way of immersion learning. I am often surprised to find how quickly I can achieve basic fluency in a language or business domain, usually within a few hours or days of being the driver.  
But what about the Expert? The expert also benefits. First they are not slowed down by the presence of the novice. This is a big deal as it can be the main issue that prevents the two working together and also prevents them eventually becoming equals. The expert also benefits from being able to think at a higher level in the role of the navigator. Just as it is harder to look at a map and keep your eyes on the road as you drive a car, it is equally hard to look at the big picture problem you are solving and type the individual letters needed make compiling code. Finally, the expert benefits greatly from interacting with the 'beginner mindset'. You might have heard the saying "to really learn something teach it" and some of my most profound insights have come when a novice has simply asked me "why?"

What are you thinking?

If the thinking is happening in the same person that is typing then they usually are not talking.  This means that you are suppose to guess what they are thinking through some sort of reverse engineering of the code that is appearing on the screen. By making the navigator speak out loud you help to ensure that everyone is on the same page. However, this is only the start of the benefit to talking out loud. A different part of the brain is used to talk than type. When you say something out loud a small amount of improvement occurs between your brain and your mouth (I often wish it was greater :-) There is an other level of autocorrect that occurs when it is received by the other person (I frequently find myself thanking my driver for understanding what I meant instead of what I said) but there is also a sort of 'stupid trap' where the very bad or unformed ideas are not able to bridge the gap between the navigator and driver and get flushed out because of it. Finally there is a checksum when the navigator sees the code end up on the screen. Because the navigator now has an expectation of what 'should' be appearing they are in a position to actually review that that it is what was wanted.

Just in time thinking

When the navigator gives a direction they might not know the full path of where to go. In fact, the vast majority of the time I navigate I do not know the path or even the final destination only the next step. While the driver is implementing the current step I have time to figure out the next step. In this manner the navigator can stay one step ahead of the driver the whole time. 

Side Note: While this is very practical for production coding, it can sometimes lead to the misconception that the navigator knew what they were doing all the time but just didn't want to share it with the driver ahead of time.

Final thoughts

This method of pairing has been very powerful for me and is the main way I have been pair programming for the last 11 years. It is very effective, fast and efficient.However, it can be very 'strong' as the name implies. Here are a few helpful tips I have picked up over the years to help soften it.

'ask for trust'

Sometimes the navigator and the driver will butt heads. I have often made the mistake of trying to argue the merits of my ideas when the actual problem is that the driver does not trust me. If you don't trust someone all the logic in the world isn't going to help. A simple solution to this is simply to ask for a temporary window of trust. For example: 
"I know this seems wrong, but could you please trust me for 4 minutes 
and then we will talk about the solution and remove it if you aren't happy"
After you get the code out there, you both will be in a place where you can now talk about the merits of it. Of course this doesn't mean you are right, you might find yourself deleting the code you just wrote but it is faster to ask for trust, program for 4 minutes and then delete it than to argue for 30 minutes to avoid ever having to write it the wrong way.

Take breaks to reflect and explain

Pomodoro's  (25 minutes of code then 5 minutes walking around the block talking) can be a great way to lower the intensity of this style of pairing while increasing the shared insights and learning. 
More importantly, always keep an eye out for the driver to make sure they get proper time to understand the high level picture as well. After you finish a section it can be good to stop and retrospect what just happened and ask questions.
If you are in a situation where the driver/navigator roles don't seem to change very often, it can also be good to force the roles to switch. In the short term this will slow production but it will make for a more well rounded team and have profound long term advantages.