Archive for the ‘Pair Programming’ Category

• Best Links of the Week – August 13th 2010

  Date: 2010.08.13 | Category: Agile, Coaching, Extreme Programming, Lean, Links of the Week, Pair Programming, PMI, Scrum, Transitions | Response: 0

  Beat the summer heat with these engaging posts.

  1. Lean Software Experience Report – detailed discussion of how XP and Lean were combined for GlaxoSmithKlein IT projects to support new drug development.
  2. Making People Before Making Products – great article highlighting the import role management plays in developing & mentoring knowledgable workers; watch out for the funky scrollbar.
  3. How to Succeed With Scrum When Your Company is Anti-Agile? - Rob Diana talks about how to recover from previous failed Agile attempts in your company with time-honored values such as lies and entrapment.
  4. How to Do Agile When We Only Have 50 Crap Developers? – a short rant on the importance of having good people on your Agile team; the comments are very interesting, too.
  5. Pair Programming Interviews – an experience report from Rob Bowley on how to use pair programming in your interview process.
  6. The Secret Sauce Recipe to Agile Coaching – Rob Myers talks about what it takes to become an excellent coach for an Agile team.
  7. A Coaching Toolkit – a collection of principles to keep in mind when coaching Agile teams.
  8. Scrum Adoption #1: Awakening – Tobias Mayer examines the concept of awakening as a prerequisite for making inroads with Scrum in your company.
  9. How to Screw Up Agile – great mind map on the factors which inhibit (and help) Agile grow in your organization.

• Best Links of the Week – July 30th 2010

  Date: 2010.07.30 | Category: Agile, Certified ScrumMaster, Extreme Programming, Lean, Links of the Week, Open Workspace, Pair Programming, PMI, Scrum, Task Board, Team | Response: 0

  More great writings gathered from far and wide.

  1. Scrum at Mind Candy – brief video of a task board in action over a three month period.
  2. Confessions of an Agile Project Manager – PMI sponsored a video contest among PMP using Agile – check out the results on YouTube!
  3. Thoughts on two months pairing - Sarah Mei reflects on her experience pair programming and the benefits it has provided her professional & personal life.
  4. Can Agile Learn Anything from PMBOK? - Dennis Stevens looks at how the PMBOK supports, compliments and impedes Agile and proposes some solutions to make the two synchronize better.
  5. Multitasking Gets You There Later - Roger Brown discusses a common paradigm in project management when dealing with too many projects and too few people.
  6. Waterfall, Lean\Kanban and Scrum – Ken Schwaber, co-creator of Scrum, discusses why Scrum relies on empirical process control theory and why they did not choose Lean or a defined process.
  7. The Role of Middle Management in Toyota or a Lean System – special post on the new focus of management in Agile organizations.
  8. Team Room – want to get increased focus, quality and retention from your Team?  Check out this team room article by Martin Fowler.
  9. Agile + UX: six strategies for more agile user experience – how Comcast is combining good user experience (UX) practices with Scrum.
  10. June 2010 CSM class – very cool visualization of a Certified ScrumMaster class taught by Tobias Mayer and Bachan Anand.

• Best Links of the Week – Feb 22nd 2010

  Date: 2010.02.22 | Category: Agile, Collaboration, Continuous Integration, Pair Programming, Refactoring, Scrum, Test-Driven Development | Response: 0

  Links to share with your friends and co-workers

  1. Is an Agile PMO possible? – Curt Finch talks about the values of both Agile practices, PMI standards and how to marry the two.
  2. Self-organization: the secret sauce for improving your Scrum team – In this 90-miute video for Google, Jeff Sutherland talks about the role of self-organization and other advanced Scrum techniques.
  3. The Agile Flywheel – a short experience report describing how one company melded Scrum with their mature ITIL processes.
  4. Just do it: a quick intro to Agile’s technical practices – a summary of the technical core of Agile software development by Abby Fichtner.
  5. I love pair programming – Discussion on the effectiveness and the challenges of pair programming after a five month trial.

• Best Links of the Week – Jan 19 2010

  Date: 2010.01.19 | Category: Agile, Pair Programming, Planning, PMI, Product Owner, Scrum, Transitions | Response: 0

  Continuing with links to the best of the blogs since last week.

  1. Three things I wish I knew before jumping – PMP and Certified ScrumMaster, Pat Guariglia, shares some lessons learned after his first Scrum pilot project in 2007.
  2. Mike Cottmeyer on the Agile PMP – InfoQ has a 78-minute video from Mike Cottmeyer’s Agile 2009 talk on how Agile’s approach to managing cost and time reduces project risk rather than the traditional approach of managing scope.
  3. Determining how Agile you are comparatively – discussion on the Comparative Agility assessment for teams looking to understand how Agile they are doing in seven areas: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation.
  4. Demystifying the Product Owner role – Roman Pichler provides some truth about the Product Owner role and clears away some myths.
  5. Self-discipline & self-organization – Cutter Consortium Fellow, Jim Highsmith, emphasizes the need for discipline and excellence on Agile teams.
  6. Eight reasons why the estimates are low – some common reasons why software estimates are often too small.
  7. How pair programming really works – the IEEE publishes an article sharing four mechanisms that can improve pair programming.

• More on Pair Programming

  Date: 2009.09.24 | Category: Extreme Programming, Pair Programming | Response: 0

  Obie Fernandez writes a blog post about how pair programming is not for the masses.  I find it interesting that his post addresses many of the items that were not discussed at the Agile 2009 session on how to debug pair programming.

  Three ideas identified by Obie are common stumbling obstacles I have observed when trying to consistently use pair programming with product teams:

  1. Most software people don’t understand pair productivity: unfortunately this is so true and it applies to both management and programmers.  From the management perspective, I cannot understand why pair programming is not embraced more fully.  You get higher quality code and the programmers are focused on doing work (as opposed to reading the Internet or working on side projects).  For the programmers, pair programming just makes the work more fun and less frustrating.  Granted, pair programming is not for everyone, but when coaching teams on this practice, I insist teams try it out for 3-4 weeks and learn what the boundaries are.
  2. Most software managers don’t want to invest in the necessary hardware: if you do not understand the value of the practice, you are not going to invest in tools that make it easier.  And yes, pair programming is an investment in the future quality of the system.  If you invest in something, you are serious about it.  Or put another way, put your money where you mouth is.  Spending a few thousand dollars on good machines gets people’s attention.
  3. Most software shops are not configured for pair programming: if you are not going to invest in tools and do not understand the value of the practice, why would you fight the office furniture police?  Why be a squeaky wheel in the corporate world if you don’t believe pair programming is valuable?  Management investments in the environment are cues workers use to know if management are serious about changing the development practices.  Nothing says change more than tearing down cubicle walls.  Being able to do that shows you have management support and goodwill.

  So, what is the solution?  I am not really certain I know the answer since solutions are context sensitive.  I believe some of the prerequisites are maturity within the developers, desire for code excellence by all parties and an open mind.IF we have these prerequisites in place, then we can begin to have a conversation.

• Pair Programming Gets Profiled by the New York Times

  Date: 2009.09.21 | Category: Extreme Programming, Pair Programming | Response: 1

  Thanks to Lisa Crispin for pointing out this article on pair programming in the Jobs section of the New York Times.  In the article, they do a profile of a company in Florida that uses pair programming.  It’s a very first person description of the practice, the benefits and some conflicts uncovered by pair programming.

  Unfortunately, since it is the New York Times, they make you login to the site in order to read the content, so use these credentials I created:

      username: lookforward9

      password: lookforward9

• Agile 2009: Debugging Pair Programming & Impact of Gender

  Date: 2009.08.25 | Category: Agile, Collaboration, Conferences, Extreme Programming, Pair Programming | Response: 0

  Mat Wayne ran an interesting session about overcoming resistance to pair programming organized around personas.  On each table there was a description of a different persona and some ideas on why that persona might resist pair programming.  Our job was to discuss in groups why the persona was resisting pair programming and some ideas on how to overcome the resistance.

  I tried to make the case that gender differences was an important consideration in resistance to pair programming.  In a room full of (mostly) men, it was hard to be taken seriously, especially after the few women in the room were pretty vocal opposing my viewpoint.  However, I think the people in that room\conference self-selected to be interesting in pair programming.  The sample was biased toward ignoring the impact of gender on pair programming.  Remember, the purpose of the session was to help people who do not want to do pair programming to become more interested in it.

  After talking with some friends, I think there are more gender dynamics at play when men and women work together programming and some of these might explain why women are not interested in (pair) programming.

  • Pair programming requires two people to work in close proximity.  Some women might not feel comfortable sitting less than two feet from a male co-worker for most of the day or not be interested in the unwanted attention from men.
  • Male programmers have a really strong geek hierarchy thing going on.  The more uber-geek you are, the more status you have and the bigger your voice on the Team.
  • Get more than three men together and you begin to create a “locker room culture” that is a normal part of male bonding.  This is often characterized by seemingly harsh, personal put downs of your ideas by your peers.

  I don’t think any one of these things is a definitive cause, but I do believe they add up and discourage women from participating on programming teams.  As coaches, we need to be mindful of gender and provide a safe environment.  It is not that women need extra help, just men need to be reminded to act like adults.

• Ways Pair Programming Can Suck

  Date: 2009.03.02 | Category: Pair Programming, Practices | Response: 0

  William Pietri has come up with a list of ways to do pair programming badly.  My favorites – #4 and #8.  Seriously though, these are anti-patterns to avoid, not to emulate.  Pair programming is a very powerful tool, we just need to get eliminate some of the misconceptions out there.

• Excellent Blog Entry on Pair Programming

  Date: 2009.02.23 | Category: Pair Programming, Practices | Response: 0

  Jim Shore has linked to an excellent discussion on pair programming from the perspective of an experienced programmer being asked to pair full time.  Short summary – everything you thought pair programming was, it is not.  This blog entry is definitely worth a read!

• Pair Programming Might Not Work For You,

  Date: 2009.01.30 | Category: Extreme Programming, Pair Programming, Quality | Response: 0

  … but don’t prohibit other people from giving it a try.

  I heard the MOST ignorant statement the other day while facilitating a workshop.

  “Pair programming is useful when you’re 23.  When you turn 24, there is no need for pair programming.”

  From the tone of the speaker’s voice, I knew this individual was not interested in dialogue.  I also could not let their comment go unanswered and be accepted as a true, so I responded:

  “I have had a different experience and I disagree with you.”

  

  Pair programming – probably the most controversial practice to come out of Kent Beck’s Extreme Programming Explained and continues to remain controversial almost 10 years later.  The practice has evolved over the years, but it is still essentially two people working together at one keyboard solving a code and design problem.  Since I have had such a different experience pair programming, I am not sure why some people have such a knee-jerk hatred for it.  Some of the most productive code and the best designs have come out of my pair programming sessions.  In my experience pair programming is a practice that allows the sum of two programming minds to exceed the individual parts.  

  So where does this resistance come from?  I think much of it comes down to fear – fear that we are not as good as we think and the other person we are coding with will find that out.  As I have heard Ron Jefferies say, “You are not as bad as you think.”  Since I am not a zealot, I will be the first to admit pair programming is not for everyone.  It is an extremely intense shared design experience.  If you are not good at expressing yourself and having your ideas challenged, you will not like pair programming.  If you simply work best by thinking in silence and hammering away at the keyboard until the app is done, then pair programming probably will not be for you.

  However, just because pair programming might not fit your personal style of writing code, that does not mean no one should be allowed to use it.  Let other people try and figure out how to succeed where you might have faltered.  There are a lot of ways to write high quality code and for some people, pair programming is their way of doing that.  Let us have some variation and see what produces the best code before limiting our options.