We are our own best resource. By pairing and mobbing, we can disseminate skills and knowledge across a team rapidly.
Measure Progress
Many teams seem to set lofty goals for improvement only to fall short of achieving them. The problem is often not with the goals but the lack of measurement and accountability. Without a way to measure progress, goals remain just an idea in the conceptual realm, and teams are less likely to strive for them. …
Continue reading “Measure Progress”
Read MoreEmpower People
I’ve seen my fair share of successes and failures in Agile implementations. From my experience, the most common reason for failure is the lack of empowerment for people. Many organizations implement Agile without truly empowering their people, leading to a culture of fear, resistance, and lack of ownership. Empowerment is not just a buzzword. It’s …
Continue reading “Empower People”
Read MoreListen to Everyone
Retrospectives are an essential part of Agile Software Development. They allow teams to reflect on their performance, identify areas for improvement, and make changes that will help them work better together. However, a retrospective is only as good as the input it receives. Listening to everyone on the team, not just the most vocal members, …
Continue reading “Listen to Everyone”
Read MoreAddress Root Causes
When problems arise in agile software development, getting to the root cause is essential. Once the real issue is understood, it’s important to address it directly. Addressing the root cause is often easier than addressing the symptoms and can prevent the problem from reappearing in a different form. To address the root cause of a …
Continue reading “Address Root Causes”
Read MorePractice the Five Whys
When something goes wrong in agile software development, getting to the root of the problem is essential. But the presenting problem is often just a symptom of a deeper issue. One technique to uncover the actual cause is to practice the “five whys.” The five whys technique is simple but effective. When faced with a …
Continue reading “Practice the Five Whys”
Read MoreBlame Process, not People
When things go wrong, it’s natural to want to assign blame. But in agile software development, assigning blame doesn’t get us very far. And it can often make things worse. That’s why adopting a different mindset during retrospectives is crucial — one that focuses on the process, not the people. Let’s face it – it’s …
Continue reading “Blame Process, not People”
Read MoreLook for Small Improvements
Seven Strategies for Effective Retrospectives It’s important to reflect with the team and gain insights on what can be improved. Regular retrospectives are an excellent way to get the team in the habit of looking at what they did and how they can improve. The following seven blog posts contain seven strategies for effective retrospectives. …
Continue reading “Look for Small Improvements”
Read MoreRadiators and Silos
In the old days of corporate America, the way you got ahead was through hard work and perseverance. You strove to become an expert in some area that was valuable so the people would come to you for your expertise. This is how you got ahead. This is how you got into management. You got …
Continue reading “Radiators and Silos”
Read MorePair Programing Paradoxes
Of all the software developer practices I teach, the one I get the most resistance from managers is pair programming. They tell me they have too much work for their team to do and if they paired then their developers’ throughput would be cut in half. There is a naïve assumption in that statement. The …
Continue reading “Pair Programing Paradoxes”
Read MoreSummary of Seven Strategies Series
I finished my “Seven Strategies” series of 72 blog posts with seven strategies for implementing each of the nine practices from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. These posts are filled with practical advice for implementing the nine core practices from Scrum, Extreme Programming, and …
Continue reading “Summary of Seven Strategies Series”
Read MoreTrack Progress
As the proverb says, “Data speaks louder than words.” Well, if it’s not a proverb then it should be. The only way to know for sure if pair programming is right for your team is to track progress and see if the metrics that are important to you improve as your team starts to become …
Continue reading “Track Progress”
Read MoreLet Teams Decide on the Details
As hard as it can be sometimes to convince managers to let their teams try pair programming and see if it improves their overall productivity and quality, sometimes I have the exact opposite problem and I have managers who want to force teams to do pair programming, even when the teams don’t feel it’s right …
Continue reading “Let Teams Decide on the Details”
Read MoreTry All Configurations
Another key to discovering what works best for you when doing pair programming is to try all configurations. By that I mean mix it up as much as possible. On each project, you should try pairing with at least everyone once. Also try pairing for different periods of time before you switch pair partners, like …
Continue reading “Try All Configurations”
Read MorePut in an Honest Day
While I am a big believer in pair programming I don’t believe that we should do it all the time. Pairing is exhausting! After a pair programming session, I am usually wiped out because I am working hard the whole time. I have someone looking over my shoulder analyzing everything that I do. That’s great …
Continue reading “Put in an Honest Day”
Read MoreSwap Roles Frequently
Another important technique for engaging developers in pair programming is to swap roles frequently. For new pairs who are just starting to work together, I recommend swapping roles every 2 to 20 minutes. For more established pairs who’ve worked together well, I recommend swapping roles every 20 to 60 minutes, although that could become much …
Continue reading “Swap Roles Frequently”
Read MoreEngage Driver and Navigator
Pair programming is really a very simple concept. It’s about writing code in groups of two or more people. The person currently at the keyboard is called the driver. The person or people who are not at the keyboard are called the navigator or navigators. The driver’s job is to deal with the minutia of …
Continue reading “Engage Driver and Navigator”
Read MoreTry It, You’ll Like It
When I was a kid growing up in the 1970s there was a television commercial for Alka-Seltzer where one guy is giving some other guy some scary-looking food and says, “Try it, you’ll like it.” That became the catchphrase for an entire generation and it meant not to pass judgment on something until you have …
Continue reading “Try It, You’ll Like It”
Read MoreWhy Practice Four: Collaborate
Practice four from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of your software, is Collaborate. You may wonder why a technical book on agile software development practices would include a practice called Collaborate but it turns out that even though we often don’t get formal training in school on …
Continue reading “Why Practice Four: Collaborate”
Read MorePair Programming Pointers
Pair programming is the one Extreme Programming practice that I get the most pushback from both developers and managers. Most of us have experience programming as a solitary art form and we’ve done it alone. We figured out a bunch of things for ourselves and we don’t necessarily feel comfortable doing our work in the …
Continue reading “Pair Programming Pointers”
Read MorePairing and Collective Code Ownership
I’ve been writing a lot recently on pair programming and mob programming and I’ve been syndicating my posts at Dzone.com, which is a web portal for software developers. I’ve received some scathing comments about pairing and mobbing from people who’ve obviously never tried it. If something doesn’t work for you then by all means abandon …
Continue reading “Pairing and Collective Code Ownership”
Read MorePropagate Knowledge
There is a huge amount of professional wisdom in software development. These are things that we have never bothered to write down but are standards nonetheless. This general knowledge is communicated through individual interactions as well as the code we write, so it’s really important that we have high quality interactions within the team and …
Continue reading “Propagate Knowledge”
Read MoreSwarm on Showstoppers
Swarming is a practice where the entire team works together temporarily to solve a problem. Swarming is most useful for certain kinds of problems, problems that impact the entire team. If no one can do anything until the problem is resolved then it may make sense, and improve morale, if everyone on the team has …
Continue reading “Swarm on Showstoppers”
Read More