Tracking change and innovation in the enterprise software development community
Jay Fields takes a look at pair programming from an adoption perspective. This article is for you if you already know what pair programming is and guidance on how to get to the point of successfully practicing pair programming. Jay goes over everything from an optimal seating arrangement, to effective coaching techniques, to calling out common mistakes to avoid.
Agile adoption often proves challenging. Participants at a recent OpenSpace event focused on the dynamics of adoption rather than the structure that results from adoption. The resulting patterns are part of an effort to compile Agile adoption patterns answering: "What specific practices should I adopt?", "How can I adopt incrementally?" and "Where can I expect pitfalls?"
"Why in the world would we use two people to do the job of one?" This is often the initial reaction to people when first introduced to the idea of pair programming. In essence, they perceive pair programming as doubling the cost of writing any segment of code. Dave Nicollete offers some quantitive ideas to help show how pair programming can save money, not waste it.
"Test-driven Development" and "Pair Programming" are two of the most widely known of agile practices, yet are still largely not being practiced by many agile teams. Often, people will cite being "too busy" to adopt such practices as TDD and pairing; in essence, implying that striving for high code quality will reduce productivity. Mike Hill explains how this logic is seriously flawed.
Uncle Bob Martin recently wrote about his experience with apprentices and what he considers key to progressing from apprentice to journeyman. He describes two hypothetical apprentices: Sam, a developer who has apprenticed with the same master and had the same year fifteen years in a row. Jasmine has changed jobs (and therefore masters) a number of times - growing her skills along the way.
Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the agile vs. lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review. Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs.
Developers commonly break user stories into tasks to facilitate distributing the implementation work across the team, and allow tracking of progress at a finer level of granularity. Unfortunately, a story can explode into a list of non-trivial tasks so large that the story is not deliverable by the end of the iteration. Ron Jeffries suggests: "Do stories as a unit, not broken into tasks."
Recently there has been an active discussion in the Scrum Development Yahoo Group about handling an "under-performing" team member. In the 130+ response thread, "Rotten apple in Scrum team", talk ranged from advice for the primary question, to talk of team morale and who manages it, to the classic debate of measuring individuals, to distinguishing whether a team is really a "team", and more.
Corey Haines has embarked on a unique personal "Pair Programming Tour". Now three weeks into this innovative journey, Haines has posted video interviews revealing many of the unique insights he's gained about pairing, automated testing, and the evolution of a software craftsman while sharing the keyboard at the home-bases of Dave Chelimsky, Brian Marick, Uncle Bob Martin, and others.
