By Woody Zuill

{NOTE: This is a draft of a work in progress.  It is likely to change over time as I flesh out the examples given here.  It is likely there are spelling, grammar, and other errors throughout.  Please read past the mistakes.  I’ll try to get things cleaned up over time.]

Fading Problems

I’d like to introduce a concept I am calling “Fading Problems”.  After doing Mob Programming for a while we started noticing that many of the problems we previously faced were no longer affecting us.  While we didn’t directly attempt to solve these problems we noticed some problems were simply fading away.

Mob Programming encourages a very Agile way of dealing with things.  The practices and techniques we follow support the concepts outlined in the Agile Manifesto values and principles (AMVP), and we use the AMVP to evaluate the practices and techniques we are using or want to try. Even more meaningful to us is that this almost automatically happened by simply “turning up the good” of collaborating and working as a whole team. For example, face to face (and side-by-side) communication just naturally happens when we all sit together throughout the day.  Another example is by having 5 or 6 sets of eyes on our code and scrutinizing our designs leads gives us continuous focus on Technical Excellence and Simplicity, and many other good things.

Here are some of the problem areas that seemed to  just fade away as we built our Mob Programming and collaboration skills.

• Communication Problems
• Decision Making Problems
• Doing more than is barely sufficient
• Technical Debt
• Problems related to Scheduling, queuing, estimating, prioritizing
• Thrashing of team members, and the team
• Politics
• Meetings

Communication Problems

There are many communication problems in software, so I’ll just cover a few here: Latency in getting answers to questions, Communication by Email, Communication by Documentation.

Problem: Getting Answers to Questions can take a lot of time.

It is not uncommon for a developer (or anyone) working on a project to come upon a question that they can’t answer themselves and therefore need to seek out the person with the answer.  If the question blocks the developer from making further progress until they have the answer they might need to switch off to some other work. Alternatively they can make a “best guess” at the answer and confirm the correctness of the guess later.  There are other ways to approach this, but regardless, none of them are better than getting the answer immediately.

We typically have many questions throughout the development of a project and if the amount of time we spend waiting for answers is more than 2 or 3 minutes it can become a serious problem.  Being able to get questions answered in 2 hours as opposed to getting an answer in 2 minutes can potentially slow down a project by nearly an order of magnitude.  In some cases it can take 2 days or more to get an answer.  This introduces a great amount of waiting time, and destroys our ability to deliver working software “early and often.”

For example, if you have 10 questions that arise, and it takes 2 hours to get each answer, that is 20 hours, or ½ of a work week.  If those same 10 questions have a 2 minute answer time, you have only 20 minutes of wasted time and you can get the feature done by lunchtime.  Imagine if it took two days to get each answer?

With Mob Programming a great deal of this problem merely faded away. For questions that can be answered by other team members, we have completely eliminated any latency simply because whole team works on the same thing, at the same time, and in the same space.  All questions that can be resolved by another team member are always addressed immediately.

However, we’ve taken a further step. We ask the “product owners” (our Partners) to collaborate closely with us throughout the development of their project.  We think of this as an informal agreement to collaborate, and it has two parts. The first part of this agreement is our partners will join us daily for an hour or so to work with us in our team area so we can demonstrate the work we have just completed and discuss the work that we will tackle during the next 24 hours.  That in itself is a big help, and we generally find there are very few unanswered question when we are working in daily “iterations”. The second part is partners agree to be available throughout the day to answer any question, either by instant messaging, phone, or screen share. We strive for a 2-minute rule where any question can be answered within 2-minutes, if at all possible.

Problem: Communication by Email 

Asking questions by Email is a last resort for us.  In “Communication by Email”, a simple question or request can take many emails back and forth as people clear up misunderstandings and move toward a shared understanding.  People become very careful when communicating by emails, as there is a chance that anything you write will be held against you at some later point.  We become more and more cautious the more important the topic of the conversation.  We start adding other people to the email chain, such as our boss or other people who need to be part of the discussion.

With Mob Programming our style of continuous communication and rapid conversion of ideas into deployed, working code allows us to eliminate most of the need for email.

Our preferred communication hierarchy is 1) Face-To-Face, Side-By-Side, 2) phone and screen share, 3) instant message, 4) email. We never move to the next level unless it’s the only option to keep things moving.

Problem: Communication by Documentation

We write very little documentation. “Communication by Documentation” is typically a “one-way street”.  This leads to problems because detailed documents tend to be open to misinterpretation, and the more detailed the worse it gets. Documents are often written long before there is any way to validate their correctness, and often the person who wrote the document is no longer available to help when questions arise.

We eliminate most Communication by Documentation by continuous communication.  It is rare that we need a document to describe functionality we will work on since we work in small pieces and always achieve one-piece flow.  We quickly validate our understanding by demonstrating and putting into use the code we just wrote.  We encourage our partners to create and use any documents they feel they need. However, when it comes time to communicate their intent to us, we do it verbally and on the white board in face-to-face interactions.  This then quickly gets translated into code, and verified or validated the next day or as soon as possible.  Again, the “one-piece-flow” nature of our work style makes this straightforward.

Decision Making Problems

I have noticed two problems in decision making that commonly occur in software development: Reluctance to make decisions, and the need to defend decisions once they are made.

People are often reluctant to make decisions for fear of blame and retribution for bad or less than ideal decisions”, and perhaps for other reasons.  We do a lot of work to make sure we make “good decisions”. We analyze, create documentation, hold meetings, get confirming opinions, have people “sign off” their approvals, and hedge our bets the best we can.  Once the decisions are made and work has started based on them, we often must defend them and find ways to protect ourselves when things aren’t working out as well as we hoped.  We become biased in favor of the decisions we have made, and rationalize them.

With the Mob Programming approach, nearly all decisions are made together by the entire team.  We recognize that there is no one to blame, and that we can easily reverse many of our decisions with no adverse consequences. We put less emphasis on making sure our decisions are “right” beforehand because we know will quickly have feedback and whatever we learn (good or bad) will allow us to steer.  Since much of what we do is done by a team, the qualities of our decisions are better than we would have had working alone.  We need no meetings, signoffs, or documentation because we are always open to changing direction and improving things.  Since our focus is on experimenting and getting rapid feedback, we no longer think of decisions as being “one way or the other”, but rather as an opportunity to learn something which will allow us to steer to a better solution as we gain understanding.  This extends to our product owners and customers as they can try things in small chunks and also steer to better results.

Doing more than what is Barely Sufficient

It’s useful to learn to discover “just enough”. Any work we do that doesn’t need to be done is waste. A project should have only the barely sufficient set of features to provide the desired functionality, and each feature we create should have a barely sufficient implementation.  Anything more than barely sufficient uses time and effort with no return, unnecessarily complicates the project, increases the chance for bugs and problems, and makes maintenance and enhancements more difficult.

We attempt to get something coded and delivered into actual use every day.  By having a daily deadline and working on only one thing at a time it is easy for us to stay focused on keeping things simple so we can quickly get something working and into use.  This naturally keeps everyone from adding things that are unneeded.

We consider our Partners (internal customers and product owners) to be part of the team, and they work closely with us to do only what is “barely sufficient” so they can get the functionality they seek as quickly as possible.  When we occasionally slip up, someone on the team will notice and get us back on track. “What can we do to get this idea into use today?” is our constant guiding light.

Technical Debt

Technical debt is a progressive, debilitating disease in code, and quickly destroys our ability to sustainably deliver value.  Conceptually, technical debt is anything in the code that makes it harder to work on than it could otherwise be, and when we allow it to exist it progressively becomes easier to accumulate more.  Technical debt can take many forms.  We’ll look at one example here, and how Mob Programming allows us to deal with it.

The “Oddball Solution” code smell:  Duplicate code is one type of technical debt. Unfortunately, duplicate code is not always obvious. One kind of duplicate code is called “Oddball Solution”.  One example of this is when we have two different solutions for the same or a very similar problem.  This often happens when several programmers have individually coded the solutions in isolation from each other.  There is a pattern to be found, but developers working individually on different but similar stories typically do not have an opportunity to notice patterns either in the problems they are working on, or in the solutions they devise.

While a code review might reveal these things, code reviews are done “after the fact”, and unless the code review for both solutions are done by the same person the pattern will likely remain hidden.  Additionally, dissimilar solutions to similar problems are often sufficiently dissimilar that they are not easily noticed even when the same reviewer is reviewing both solutions.

In working as a Mob all work is taken on in a sequential “one piece flow” manner. The whole team is aware of each problem, and each person helps devise every solution.  The chance of noticing that something we are working on today is similar to something we worked on recently is much more likely than when working in silos.  We have had many instances, even months later, where someone on the team recognized that something “seems familiar” about something we previously worked on, and the group memory of the team allows us to quickly locate the previous situation. We can then investigate solutions that will allow us to abstract out the commonality and create simpler solutions with less duplication.

With more eyes on all work, and more discussion about keeping things simple we notice problems like duplication, hidden patterns, and other code smells and technical debt pitfalls.  We have a collective interest in Clean Code and encourage each other to keep our code in great shape.  Less is “put off for later” as someone will generally notice we are doing something stupid to ourselves and point it out (with kindness, consideration, and respect, of course.)  Additionally, whenever someone senses something is harder to do than we might think it should be they’ll mention it and we’ll take time to see if there is some hidden technical debt slowing us down.

Problems related to Scheduling, queuing, estimating, prioritizing

Estimating, prioritizing, queuing, and scheduling work is a common part of managing software development in most organizations.  While this adds no value to the work being created, it is often thought that these things are necessary to manage the work.  If we could get our work done just as well without these things, we could eliminate the waste.

With Mob Programming, we take on work one piece at a time so the whole team can focus on the current work item.  The whole team, including business people and customers, discuss the work we are currently taking on and work together to identify the details. We identify some discrete and yet cohesive part to work on, and decouple it from the remaining work of the project. Little or no work is done on any “story” until we are ready to work on it. Once we’ve settled on the nature of the story, we code it, put it into production, and validate its usefulness.  Only then do we begin work on the next idea.  This approach allows us to eliminate most “up front” scheduling, queuing, estimating, and prioritizing.

Thrashing of the Team Members, and the Team

I am using the term “thrashing” here as a placeholder for a number of typical activities that detract from a person’s ability to effectively do their work.  As an example, a developer can be taken off of their assigned workload and asked to work on an emergency or urgent task.  There are at least three harmful conditions that are the often the result of this type of thrashing:

1) The developer must take their attention from the work they are doing, thereby losing the thinking and time they have invested towards understanding the problem and solution.  They might not be able to easily get back on track when they finish the emergency task.  In some cases they might not be able to get back to the original work for weeks or months, but even being distracted for just a day or two, or even an hour, is enough to cause problems.

2) If other team members are counting on the work the thrashed developer was supposed to be working on, their work can also be held up or blocked.

3) It is common that the “thrashed” developer is the “go-to” person on the team.  They are proven problem solvers, and that is why they are sought out to help with the emergency tasks.  If this developer is taken away from the rest of the team to attend meetings or to work in another department, the team loses their most valued member and can flounder without their trusted and capable guide.

That is just one example of thrashing.  Other typical examples will are unneeded meetings, casual distractions, busy work, disruptive noises, postponing of work already started, and task switching to accommodate phone calls and other intermittent requests.

There are at least two ways to deal with thrashing problems. One is to prevent it from happening, and the other is to make it irrelevant when it happens.  We apply both of these approaches with Mob Programming.

1) Prevent it: By working in a one-piece flow manner, we work through things quickly and there is much less chance of us starting on something and then getting interrupted. When emergency work is brought to us, we simply work on it as a team. No one is taken off the “current work” because we take each piece of work as a discrete task.

2) Make it irrelevant: In the case where someone is called away to work on an emergency, the work does not stop since there is a team level understanding of all the work we do.  When that person returns, they easily get back up to speed.  Also, the “team memory” helps in the rare occasion where we must set aside our current work in the middle of working on something as we can quickly remind each other of the our train of thought when we resume the interrupted work.

Politics

There are a number of issues related to politics in any business. Often there are cross purposes between teams, departments, roles, individuals, and so on. Even worse, there are well known issues like power plays, territorialism, parochialism, empire building, and many others.  While Mob Programming does not help much with all of these possible issues there are some “Developer Level Politics” that we feel are reduced by Mob Programming.

One example of “Developer Level Politics” is how willing people are to help each other.  In some organizations with the typical performance appraisals to determine bonuses, raises, and promotions and you will be judged on how well you get your work done.  In some situations you do not get credit for helping others and must focus on your own work.  There is little or no incentive for helping others. Helping someone else uses up the time available for working on your own work.  There work gets done quicker; your work is not getting done.

When we all work together, all day, every day, the work of the team is what is important to everyone. There is no “me vs. you”.  The basic idea of a “self-organizing” team is that each individual can decide where, when, and how they can best contribute.  We engage and contribute in any way we feel is helpful.  Helping others happens naturally because the end result of the team depends on us working well together.

Meetings

In the common pattern for meetings we gather, share information or are shown information, make some decisions, make some assignments, and everyone goes away – some to do work, others to manage work.  I see this as often resulting in a harmful separation of “work” and knowledge creation from decision making.

After the meeting the folks that need to ask questions are separated from those who can provide answers and information.  Those who can validate things are separated from those creating things to be validated.  In other words, while we might be working together for a short time, and we are aligned to some degree at the end of the meeting, it is a very fragile alignment. We start diverging quickly, or even immediately.

This “gather, share, decide, assign, disperse” meeting style is not a very collaborative way to work, and often leads to the need to manage the meetings and the work agreed on during the meeting.  We need extra tasks and artifacts like agendas, meeting minutes, follow-ups, email communications, check lists, spreadsheets, and so on to deal with this. After the meeting any questions, clarifications, validations, and so on require that we track down the right person to help us. Communication is put into queues, and done via emails, phone calls, and follow-on meetings.

With Mob Programming our entire day is a working meeting, and more like a workshop than a meeting. We are working together, not merely “meeting”. We share information, decide what to do, do it together, verify our understanding, adjust our understanding about the next reasonable thing to work on, work on it, and so on, over and over. We collaborate and remain in alignment all day long.  Any questions are answered immediately.   Work is validated as we go, and it is put into use as quickly as we can, often on the same day it is coded, which allows for users to verify its value.  We find very little need for planning meetings, stand-ups, review meetings, and most of the common meetings that plague the typical development organization.

Conclusion

I’ve covered a few of the problem types that are common in many organizations.  These are things that can be addressed by Agile and Lean thinking, and that I feel our “Mob Programming” approach has helped to lessen or eliminate many of these problems by simply “turning up the good” on a few key things:

• Continuous collaboration and communication throughout the team, and with our work partners
• The almost automatic application of a “limited WIP” and one-piece work flow
• Frequent delivery of software into use and the rapid feedback this provides
• Holding frequent and meaningful retrospectives.
• Other things I’ll probably think of later.

So there you go.  This is just a “first draft”.  Perhaps I’ll get back and work on this now and then.

Cheers!