Knowledge transfer is characterized by transfer of understanding, about a context, from one unit (individual, team, department, organization) to another. In a series of interesting experiments, Steve Bockman tried to figure out the best way to transfer knowledge in an Agile project.
"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.
Buddha Buck recently asked the Extreme Programming list if there were a velocity range that could be considered 'good' for a team of about seven people doing two-week iterations. He felt that a velocity of eight or below indicated that the team's stories might be too big. The resulting discussion provided some answers to the question, and the questions behind the question.
In this video recorded during QCon London 2008, Pete Goodliffe presents two Linux-based audio products with a complete different outcome, software design making the difference.
In this presentation recorded during QCon SF 2008, Neal Ford, an architect at ThoughtWorks, shows 10 ways to write better code. This is practical advice for developers, but application architects can benefit from it too.
A recent discussion on the Extreme Programming Yahoo Group explored the apparent conflict between making software reusable and the XP practice of not writing code until it is needed. Ron Jeffries and others shared insights about the costs and benefits of code reuse, as well as how and when to do it in an agile environment.
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.
Jay Fields presents several concrete strategies to go from "I think pair programming is a good idea" to "our team is successfully practicing pair programming and loving it!" He covers everything from pairing stations (the physical layout of your office space), to coaching tips, to common mistakes that those new to pair programming make.
Recently InfoQ reported on Jim Shore's 'The Decline and Fall of Agile', which highlighted a trend for organizations to adopt "Agile" (in name) but fail to adopt what it means to be Agile (in practice). Community leaders such as Joshua Kerievsky, Martin Fowler, and Ron Jeffries have taken Shore's post a few steps further recently, posting their own thoughts on what's going on with this situation.
In this interview taken during Agile 2008, Alan Cooper, the father of Visual Basic and supporter of interaction design, talks about his contact with the Agile movement and the similarities discovered between Agile programmers and interaction designers.
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.
In this presentation, Kent Beck, the father of eXtreme Programming, shows the synergies between business and Agile development. The reason Agile is becoming more popular every day is because it responds to the business needs as they evolve.
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.